Grasshopper

algorithmic modeling for Rhino

I have this python script:https://gist.github.com/1019295

 

It is an attempt to rewrite the Local Code/ finches Import component as a Python script. Basically, it takes filepaths, layer names and some on/off switches as inputs and uses that to import files and then bring in references to the geometry based on layer names.

 

here's a picture:

 

 

When I run this component with more than one file path, it seems to 'stick' during import, and rather than just importing and stopping (being solved once), it seems to continually import. Why would this script or component be continually triggered when there are no UI actions taking place? Is there a way to enforce that it is solved once and then only reevaluated if the inputs change?

 

Thanks for any guidance/ideas!

Views: 711

Replies to This Discussion

To get the whole picture, could you please post the definition?

(right now, I think that this might be due to Grasshopper listening to OS file changes)

- Giulio

_________________
giulio@mcneel.com
McNeel Europe

sure thing. Attached is the definition and sample data.
Attachments:

If there's anything I can do to better explain the issue, break it down, or help troubleshoot, let me know. Solving this would be really valuable to me.

 

Thanks.

Hi Ben,

I'll look at this tomorrow morning.  When a file is read using doc.ReadFile a whole bunch of event watchers are fired and it may very well be that Grasshopper is paying attention to these events.  I think we need to give you a way to read a 3dm file into a class that is not really part of the rhino document.

 

If you want to stop the script from reading a file a second time you can try using the stick dictionary.

 

if scriptcontext.sticky.has_key[filename]:  pass

else: #read the file and save filename as a key in sticky

 

Thanks,

-Steve

Thank you Steve! I really appreciate it!

 

I'll check out sticky and let you know early tomorrow.

This was fun! I think I've got something that works pretty slick now. You are going to have to wait until the next V5 WIP to test this since it required some additions to RhinoCommon.

 

I modified the script to read files into a RhinoCommon File3dm class and extract the geometry that is on specific layers. This is all done without doing anything to the Rhino document (so it plays nice with grasshopper)

 

Here's the new script

https://gist.github.com/1025541

 

and here's the updated definition

 

Attachments:

That is really fantastic Steve! I can't wait to use it!

I often do a ton of batch processing using both Grasshopper and Python (I'm typically working on sets of models in the hundreds or thousands, 767 at the moment), and this change looks like it will help tremendously, both in Grasshopper and in Python scripts.

Thank you!!!

 

I just installed the update and it works extremely well! This is a huge improvement for our work! I can't thank you enough.

 

I've made some edits so that it outputs a separate branch for each layer.

Here's the updated script:

https://gist.github.com/1019295

 

Attachments:
Thought you might like that. Having projects like that really helps me figure out good ways to structure RhinoCommon.

Hi Jonah,

Could you please start a new discussion? If it's hard to find 'import', it will be impossible if the thread title is SolveInstance. Also, back in 2011, there was no Rhino 5, RhinoCommon was in early stages, etc. So it might be just a good idea to start fresh! Thanks!

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service