Jump to content
AutoDesSys Forums

Recommended Posts

Thanks Tech, I was already aware how to find system requirements for version 8 but I am pleased that it sounds like you will do your best to support Windows 7 in the next version of FZ.

Share this post

Link to post
Share on other sites

Thinking about my previous inquiry? -- I'm going to expand somewhat although I expect the answer will be "wait and see".


1. What implementation of Python will be used? -- CPython, JPython etc. or some special compiled hybrid?

2. Will the standard library be included?

3. Will Formz use the standard TK graphical interface or will we be limited to a few internal GUI's??

4. Will Formz allow the user to add additional libraries? Are any 'add-on' libraries included such CSV etc. outside the standard? OR will the interpreter be completely closed to the user?


Excited about the coming new features of V9 and I think a 'heads-up' would be nice. I seen some script attempts by other Vendors that were developed completely in the dark and when released were so limited because of no practical input, that they were virtually useless and beyond repair? Just Asking since I think now is the time to plan for and anticipate future expansion(s)?

Share this post

Link to post
Share on other sites

Here are some answers to the questions about python scripting in form•Z 9.


form•Z 9 uses standard python 2.7.  In essence we have developed a Python interface for form•Z that allows python scripts to access information in form•Z and use form•Z features while using the standard python language and features.


The Python standard libraries can be used (by including the proper import statement in the script).


You technically could use third party libraries like TK/QT, however as form•Z is not built on these interfaces, your interfaces will be disconnected from the form•Z interface and may even cause some conflicts (window ordering issues etc). You should use the form•Z provided UI functions to leverage the existing interface and capabilities (rendering, interaction, picking, snapping, palettes, undo etc). Since we are using standard python, you should be able to use any conforming python library that you have installed on your machine and that is available to any python implementation.


We look forward to hearing more about the types of scripts you wish to develop and we expect this to be a dynamic dialog as we expand what can be done with scripting in form•Z 9 going forward. We hope to make a technology preview of the new script features available sometime March.


Next we will post a few WIP  examples.

Share this post

Link to post
Share on other sites

WIP python script to create a Hidden Line rendering (saved in a tiff file) of each view, in each formZ project file, in a user selected folder:


import formzPythonInterface as fz


import os


def fzMain():

# ask user for folder to render
source_path = fz.uiSelectFolder("Select Source Folder")

list_dir = []
list_dir = os.listdir(source_path)

for file in list_dir:   # for each file in folder
  if file.endswith(".fmz"):   # check is its a fmz file
   project = fz.loadProject(name=file)  # load the file, save reference to close
    viewList = fz.getViewList()    # get the list of saved views

    for view in viewList:     # for each saved view
     fz.setActiveView(view)     # select the view
     fz.setRenderer("Hidden Line");   # select the renderer
     fz.render();       # render
     s = os.path.splitext(file)[0] + "-" + view.getName()  # make name file-view
     fz.export("tif",name=s,keepExisting=0)      # export tiff file
    fz.closeProject(project,save=0)        # close project



Share this post

Link to post
Share on other sites

WIP python script to make steps. This script creates a live interface with sliders and a check box. When the user changes a UI element, makeSteps is called to create the new steps (watch movie below  to see it in action)



import formzPythonInterface as fz


num_stairs = 24
bot_width = 48.0
top_width = 248.0
do_reverse = 0


# create the new steps

def makeSteps(panel):
global olist


# remove objects from last iteration
while (len(olist)):
  obj = olist.pop()
  del obj


# get values from UI
num_stairs = panel.getValue(1)
bot_width = panel.getValue(2)
top_width = panel.getValue(3)
do_reverse = panel.getValue(4)
direction = panel.getValue(5)

wdh = fz.xyz(12.0, 12.0, 1.0)
org = fz.xyz(0.0, 0.0, 0.0)


# make steps
for n in range(0, num_stairs):
  wdh.x = bot_width + (((top_width-bot_width)/float(num_stairs)) * float(n))
  obj = fz.cube(org, wdh, [0,0,0])
  s =   "Step %d" % (n)
  #  obj.rotate()
  org.y += 12.0
  if do_reverse:
   org.z -= 10.0
   org.z += 10.0




def fzMain():

panel = fz.uiPanel("myStepOptions")    
# creates the uiPanel

panel.slider(1, "Number of Steps", num_stairs, 3, 43)
panel.sliderEdit(2, "Bottom width", bot_width, 12.0, 48.0)
panel.slider(3, "Top width", top_width, 48.0, 248.0)
panel.check(4, "Reverse", do_reverse)

# show on screen


Share this post

Link to post
Share on other sites

For Starters,   Hope this gives a good idea of the things I want to do.

Additionally, access to a ALL of the Toggles within the fZ interface  (i.e.  in the rendering modes, there are a lot of options that can be toggled, but have no Key Shortcut option)


•Additional Align/Distribute options.

•Face2Face  (like the place tool, but only one object to one face.  (unless I am missing an existing tool)

•Wind Load Calculator.

•MIMI with more capabilities than it currently has

•Random Mapper with more capabilities than it already has.

•Make a value of one object equal that of another  (length, area, volume)   Most of this has been built in FSL, stopped when I realized I could not continue in 8.x

•Automate rendering output for multiple rendering modes (very similar to what you have above, but cycle through different rendering modes and mode options, as well as to render out

     multiple views and layers from a single activation of the script.   ( I will often have 3 or 4 renderings that I later assemble into 1 in photo shop  x 5 or 6 different views... All this automated)

•Write extensive amounts of text to disc.   would like to have XML as an built in option, but will fake it if I have to.

•Add marks (Start/Stop/Alignments) to flat patterns (grouped) at specific locations from different criteria.  These will have to Drill Down through object Groups

  °Tick Mark at Click

  °Tick Mark at Segment count from Click (nearest node, or nearest point on segment to click options)  (with Reverse direction option)

  °Tick Mark by Distance Intervals

  °Tick By Selected Segments   (of other object

•Object Naming Scripts (in part, rebuild LAB's rename so that it works correctly)

  °rename by order of objects in the pick buffer,  not by order created.

  °Modify the Mirror tool so that object name has a "Mirror"  appended to it.    and if a Copy,  no "copy"  needed

•Visible Labeling

  °Group name to text label or Note visible in modeling environment.  (Needs to tunnel through Group to add text/Label)

  °Add Placement/Alignment tables into Seam Allowance (adjustable)  Depending of different pre-picked criteria

•Attributes.   to be able to use attributes as input or stored variables for modeling decisions.

  °A way to fake the old "Marked Points"  of 6.x   and for that to translate down stream such as an unfolded object to pattern.

  °Seam Allowance Attribute.    While this can be done in modeling, it doesn't need to be, as other applications use an attribute feature, rather than a separate object to represent SA.

  ° others?

• Fix the Unfold tool so that it is useable, and out of the 1990's ( Don't know if all this can be done in a script, but I sure the hell am going to try)

  ° While it was a nice idea to label the sides of the unfolded patterns, it is unpractical to use for objects of any sophistication.  (labels for every segment??? Understand, that a machine

        that cuts out patterns, has to draw all the placement labels.   this takes a lot of time that isn't required for the assembly staff to be able to do their job  i.e. overkill So I don't use it)

  °in objects that have any kind of sophistication to them, pre-separation of the patterns is done, so as to NOT rely on the unfold algorithm.

    Labels should come from objects that share edges and only one label per shared edge, with a start and stop mark on a pattern that shares more than 2 nodes at that location

  ° Analyze object prior to unfold to see if there are any Split Ends (will unfold cleanly or not)   And if Not, Mark the locations that are problematic

•Separate by surface Style (Material)

•Curve fit Match Generator (make a curve tool, similar to the C-Curve tool that the curve ends up with the same length as the source set of segments)   

    I do this all the time manually, and it is a huge PIA!

• Group Editing  

  °Enter Mode where you can enter a group, edit it, without any other objects that are not part of current group visible

       (Simple,  Isolate objects (group), Copy Name of Group to Buffer, Ungroup, allow editing,)

  °Exit Mode where all objects including any new object added while in Mode are Grouped once again and all other objects in scene (according to last state prior to entering mode) are

       visible again.

        (Select all objects, Group,Rename New Group to Old name from Buffer, Reveal objects)

Pattern Rendering Scripts    (A series of scripts to help out rendering patterns for later large format printing)


Custom Rendering Mode (if Possible)

Share this post

Link to post
Share on other sites


Asking for “wish lists” is always dangerous – But here goes mine.


  1. As a new user of Python, I'd prefer 3.6 but I recognize that the shear volume of 2.7 code means that it's not going away anytime soon. Hopefully the SDK will anticipate a future upgrade?

  2. Multiple Labels – Ability to switch labels based on some criteria such as the view, a attribute or condition. Sooo – the ability to access all these conditions within the script for any object.

  3. Unicode Support – Pass through of Unicode text from Python to FormZ text and Labels. Not just limited to ASCII – necessary for international support.

  4. Ability to import RTF text and retain any formatting. Ability to format RTF text within Python and pass through to FormZ.

  5. Ability to access and read/write all object attributes and ability to add accessible custom attributes to any object. This would allow the user to build a custom library of objects, specific to the user which contain pertinent info.

  6. If TK/QT is not included – the ability to create and address user IO panels containing the standard widgets such as text boxes, buttons, ck boxes, dropdowns,lists, etc.

  7. Custom Spreadsheets – very important – to create and fill by script all cells/rows of user SS including control over formatting.

  8. Access, search, filter, all attributes of all objects including general plan data.

  9. Access and control of standard matrix commands to transform, rotate, move objects, etc. ability to read for each object, the end point , snap points, parallel, perpendicular, objects etc.

  10. Mimic keyboard input for all FormZ commands.


Share this post

Link to post
Share on other sites

Yes, anything that takes us closer to creating a cost-list / price-list / more user controlled bill of materials as spreadsheet, which refers to selected parts and maybe parts even unselected if on a certain layer. Info management is an extremely useful tool but the .csv output is still a little limited regarding customisation.

Share this post

Link to post
Share on other sites



Is there a technical reason we are going to use the 2.7 release of Python instead of 3.x?

Python Documentation notes that 3.x is the current and future, and 2.x will no longer be updated (which looks to be the case for quite some time)


Truth of it all, if it would delay getting it, let's stick with 2.7.



Share this post

Link to post
Share on other sites



There are a couple of reasons that we are using Python 2.7:


• There is a vast collection of Python 2.7 compatible resources (libraries, tutorials, debuggers, examples etc).

• Python 2.7 is built into MacOS X so no extra installation is required.

• A number of the features that were introduced in python 3 have been included in Python 2.7. In fact the latest version (2.7.13) was released on-12-17-2016 so its not so old.


It should be noted that most of the Python interface with form•Z is Python 3 compatible so we expect that the transition in the future will not be too difficult.

Share this post

Link to post
Share on other sites

Since it was mentioned -- I was wondering if the minor release version of Python will matter (compatible) with the new script feature. My Mac has a default version of 2.7.10. Since 2.7.13 was mentioned -- should I load it??

Share this post

Link to post
Share on other sites



We are not yet aware of any limitations that would require a specific version of 2.7, we recommend keeping what you have installed if its working fine and only upgrade if you encounter a specific dependency or issue.

Share this post

Link to post
Share on other sites

Can someone explain what this development means to an architect without coding knowledge?  I can obviously see the benefit from the sample provided, but will there be a way to create these parametric type commands without coding?  Or I suppose one could hire someone with the knowledge to produce specific coding as needed.  Is this FormZ's answer to Grasshopper?

Share this post

Link to post
Share on other sites

IMNOHO -- Your asking questions that can't be answered right now. But my experience with other programs that have a scripting feature convinced me, that for the average architect, it will still be easier and faster to create 3D features/objects/designs directly and store them in a library even for repetitive tasks. The best use of scripts is for commercial users and hobbyist who have a lot of time to extend the program in areas to costly for Formz to consider. And that is totally dependent on how detailed AutoDesSys will make the script interface. If they extend it to the extend of say, Sketchup, then I can see some benefit. But remember, it took Sketchup years to get there. I doubt, that with the initial release, they can get that detailed. Maybe in the future if they decide to continue work -- but who knows?


Where I found a huge benefit is in the ability to configure custom annotations, Spreadsheets,  B/M's, notes and defining attributes. Again that is dependent on how much access is allowed to the object data. in this area it doesn't take much knowledge to generate the details needed to provide the info to manufacture/construct your designs and can be a great time saver. in these areas, AutoDesSys simply can't anticipate all the user's needs. Best left to the user to provide.


So the answer, it's too early to tell (IMO) as this is completely depended on how deep AutoDesSys is willing to go. We'll just have to wait and see.


As to Grasshopper I have both it and Archicad and found it to be not not worth the learning curve -- More Formz practice and skill is much more productive.

Share this post

Link to post
Share on other sites

Ok it sounds more relevant to trade show and industrial design work, no?


Exactly!! -- For now, But if AutoDesSys does provide a comprehensive Script, i think you will be pleasantly  surprised as to to the innovative solutions users will be willing to share.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now