form•Z v9 Python Scripting

[Tech]

A new page has been added to the form•Z site with more information on form•Z v9 Python Scripting (Click Here to visit)

In case you missed today's webinar on form•Z v9 Python Scripting you can check it it out here:

 

 

[Bo Atkinson]

Thanks to this webinar, for the first time I wondering what applicability this tool set might have and how much learning is required of me, since I never used any sort of computer scripting, but rather always used graphical work flows. Does combining these two work flows help one jump hardware-hurdles?

Is it possible to convert an arrangement of tetrahedrons, inside an fmz file, into a pyc model? Once in a pyc script, can a larger quantity of these script copies be 'pasted' together?  My objective is tentatively based on an assumption that it might be easier to copy-paste script compositions, in some cases, rather than handling large quantities of objects or groups of objects, in a modeling window, where the there are 4 axes instead of xyz axes,  and at the same time get accurate joinery, alignments, snaps, etc... Here is an example of large quantities of tetrahedron-matrices, which are difficult to 'snap' into non- xyz arrays, given the sheer quantity of objects, along with the equilateral relationships of cube and tetrahedron:

Edited March 6, 2020 by Bo Atkinson

[Bo Atkinson]

A further thought is that my 4 axes are orthogonal to an initial 4 tetrahedra faces, from which this larger model grew outwards into the initial vector-equilibrium near the center of this axonometric view. The peripheral 'cubes' are actually "composite-face snapped vector equilibria", grown out from central, initial VE...

My additional question is: might pcy scripts simplify the avoidance of the 3 cartesian axes which dominate architecture today?

[Bo Atkinson]

Here is an initial mold to explain the VEs (vector equilibria). The composite fmz projects like  above are too cumbersome with a 1 GB video card, (years ago I had 6 GB video card working for a few months, but I lost the best driver and it's tech support has vanished over the years). (Vapor Ware).

The smaller sets were used to explore assembly possibilities of larger arrays. The green objects are two tetrahedrons forming a star tetrahedron, for face attaching smaller bluish ones to form VE arrangements. The red is a frame-tool VE object to verify VE status. 

[¢hris £und]

I think you could build geometry that way, however, regarding the rest... not sure

i do t think (limited vision, quite possibly), that you can generate python code from existing geometry...  at least not easily.  The fZ file format itself is not in python. 
someday it may be possible to have macros that build python code, but I don’t think it is there yet, honestly, haven’t looked though.   But if you want that, that would be a logical first place to look.

in order to “surpass” fz’s snapping, I suspect you will need to build that geometry. As I doubt fZ has a Coordinate that isn’t Cartesian or polar.  Haven’t even seen a cylindrical coordinate system.  
one possibility to fake it would be to have a script running in the background. (Don’t think that is doable yet, but I have already requested it) that is creating a small set of you geometry on a ghosted but snappable layer on the fly.  So that not all the geometry is in the project, rather just in the area you need it to be in.

how to specifically accomplish that...  not positive.   But you would need to track the cursor in xyz and have fZ generate Or copy existing geometry from the buffer to the project window where it is needed based on that cursor info.  
 

a specific algorithm does not come to mind now.   
 

I do have something I don’t understand about your request though.   Mathematically, you can have higher order dimensions that are orthoginal, but can you in 3D. Real or generated?   Or would it be skewed space that you conceptually adjust and pretend orthoganlity (sic)?

i.e.  an angle in 3D space isn’t measured as a right angle, but you could skew you measuring tools so that they measure as it were...

or am I way off base?

 

€£

Edited March 6, 2020 by Chris lund

[¢hris £und]

Regarding, visual scripting, I think it has its place, but if it were really that good, pro coders would have adopted it for their own work years ago.

conceptually, however they are essentially equal, or analogous to a high degree.  If anything the visual being a subset of the textual.  So most concepts that you have learned for visual would translate...  just with syntax instead of visual blocks.  Input and Outputs as parameters and return data...  links as calls to functions and in some cases, variable in between that act as those links or aid in linking.

i am hoping that when a visual scripting becomes available, that it will generate python....  but hard to guess.  Grasshopper generates JavaScript and c/c++ if I recall correctly, and not Rhino’s built in scripting language. Which is curious.

cutting and pasting...  to some degree,yes.... but not wholly. As then you would have multiple fzMain() functions...  they would collide.  You could refactor it first then c/p it,  the. Make the necessary call to it when appropriate.  (Think of this as glueing the pieces together).

hopes this helps and doesn’t confuse further.   IMHO, it is worth learning at least a little... once you get a little bit in, the possibilities start to emerge, which will hopefully garner further interest and so on...   you simply follow your interests to take you as deep as you need to go...  

as I have mentioned before, one great aspect about python, is it can be used outside of fZ.  Both simplifying what you have to learn and making it more powerful at the same time.

Pick your low hanging fruit first,  small and easy tasks.  This will build your skills and knowledge as well as expand your imagination horizon too.

This will exactly be my approach too, even with some experience coding.

it s probably good that we are limited to utility scripts at this time, as they are really suited for the small easy tasks, (not that they are restricted to this).  As the other types will add a layer of complexity that as learning doesn’t need right away.  

€£

[Bo Atkinson]

I can appreciate the likelihood that my curiosity is outside of the python realm.... Yes two curiosities:

1] Basically use scripts to simplify precision-copy-paste of complex arrays of simple polygons.
 
2]  Bypass limitations of  cartesian space, (heh, heh). My untrained opinion is that cartesian negative axes must cause computational havoc, ie the old trigonometry problems such as square roots of  negative numbers... Whereas four axes with always positive values might provide enough axial resolution with all positive axial values? Cartesian axes are actually six directions from zero, but wouldn't the negative values introduce problems, such as navigating views aligned too close to an axis? (Sometimes a new project free of objects allows this, but not with perspective views after a minute of navigating).

[¢hris £und]

I am interested in what you come up with.

[BernieB]

Python scripting looks very complicated. But it might be the answer to creating the roofing tiles approach I've seen In LWCAD. But we can also create our own shingles and then apply a script to lay them out evenly on a surface then that would be awesome.

http://www.formz.com/forum/old/messages/16/65407.html

 

[¢hris £und]

BernieB, ADS has taken care of the complicated parts, and as they said, more will be added as time goes.  If you fine anything is missing, put in a request for it.

To learn, I suggest that you consider the low hanging fruit first.  Get some of the small but annoying tasks out of the way.  This way you can learn both python and the API fZ provides.  From there, you will naturally start moving to more and more complicated tasks.   From that, you can also consider your logic in how you would approach the task in the modeling environment.  That logic would be the map to building your code.  that may not be the most efficient code, but is a start.

I see three possibilities.  

• if formZ's roofs are of a special object type, that "knows" which segments are the ridge lines, then you could use that to apply the ridgecaps, assuming the API will give you that info.  I don't think at the moment it does.
• you could break the script up, so that the user chooses which segments get the ridge cap tiles, and another which faces get the roof tiles.
• Walk through each segment and analyze the adjacent faces to see what their normals are, if both normals are pointing up (or at least one is not pointing down, then consider that segment a ridge line.  Collect all determined ridge lines into a list, Sort the list so that the highest ridge line is last, and the lowest is first.

in any case, you would measure the distance between the segments of the face to be tiled, and distribute the tiles by a quantity that fits the length with an overlap. give it a minimum and a maximum overlap.    To do it best, add a rotation to the tiles depending on the amount of overlap.  blah blah blah.

 

regardless, the API should have most if not all of what you would need.   Again, though, learn scripting by doing the easy stuff first, then attack this.  if you don't feel that you have other tasks that you would benefit from, then don't think of this as a singular goal, and break each element into separate tasks (which is what you really would do any way.)