algorithmic modeling for Rhino
I've read this post and a few similar ones:
http://www.grasshopper3d.com/forum/topics/bake-objects-with-ghpytho...
And checked out the GH definition the Giulio attached.
I'm fairly well versed at using python in Rhino both with rhinoscriptsyntax and RhinoCommon, but I'm hitting a wall with using it in GH.
In the example definition a line is added to the rhino doc, but when run (toggled true), the line doesn't become actual geometry in the file. Also, when i try baking the python object, nothing happens, which i assume is because there isn't actually any geometry assigned to come out of the python object's outputs. I can, however, add the line by baking from the line parameter object itself (but the GUID of this line in rhino is not the same as what the python object print says it should be). I guess im confused because the info-graphic in the above post suggests that adding real, selectable Rhino.docobjects can be done through python scripting.
So my first question is this: Is it possible to script the baking process from the python object itself or is baking completely under the control of the GH plugin? Is "baking" the only way to get real, editable geometry out of GH?
My second question relates to the application of these principles:
I have a GH definition set up to generate some geometry based on RhinoDoc geometry whose GUIDS I have stored in an excel file (i can send you the definition if you'd like, but the problem should be comprehensible enough without it). I want to step through different sets of this geometry and bake the results. Basically, i want to bake one set of driving geometry, increment an index variable to choose the next set from the excel file, and bake again, etc. I could do this by setting up a slider and a "bake" button, but I would like to be able to automate the process.
I have tried setting up a python object to do something like this:
for i in range(15):
#set output a to i and feed this to select a list item
#set output b to True to trigger a bake object
As you can probably guess the output of the python object just ends up at a=15 and b=true and bakes the last set of geometry but none of the rest. Why is this, and is it possible to gain more precise control over the state of the solution and baking from the python scripting object?
In addition, how do the rhinoscriptsyntax methods affect things in the different scriptcontexts of rhino_doc and ghdoc?
Tags:
Hi Bert,
I quickly scanned through your post. I have attached a simple baking script in a Python component that may help you. The approach I use is to:
i) Switch to the rhino actve doc as the scriptcontext
ii) Add object I want to bake to the document's object table
iii) optional - switch object to the desired layer
Ooopss I just checked out the link to after reading your post in more detail :)
My definition is similar to Giulio's, though I would say he provides a clearer example and explanation.
With reference to Giulio's definition, you should not bake the python component. Setting the toggle to true is equivalent to baking. If you replace the toggle with a button, everytime you press the button, you will be baking the line because the following code is run:
rhino_line = scriptcontext.doc.Objects.Add(geometry, attributes)
When I run Giulio's definition, I do have a line in my rhino document which i can drag around - so there is 'actual' geometry. So answer 1 - yes you can script the baking process. The key is to switch between scriptcontexts (Rhino.ActiveDoc and ghdoc)
As for question 2, why not just bake all of it at once? Is it important for example to bake one first, look at it, then select the next? I attached a modified version of Giulio's definition with just one additional: for line_id in line_ids. Hope it does what you are aiming for.
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by