algorithmic modeling for Rhino

This post is a continuation from an older post about finding the name of a Grasshopper document.

I'm attaching some Python that pulls some basic data from the document (author, date created, file path, etc.) It includes the code posted in the forum link above which lists add-on libraries currently in use, as well as their versions.

Here are my remaining questions:

  1. Why is the addOns output listing the Grasshopper library and how can I avoid this?
  2. Why is the addOns output not listing the Gh Python interpreter currently in use?
  3. I would like to be able to toggle the run inputs to False and have it leave the recorded data in the output panels (instead of reverting to <null>). This way old data could remain until someone wants to intentionally overwrite it. How might I approach this?



Views: 1937


Replies to This Discussion

Hi again Brian

thanks for staring a new thread! 

1. Because you re-wrote the libraries() function wrongly :) Just go back to the previous version, return both results and then only use the addonLibraries variable!

2. Because the code is written so that it avoids looking at itself. You can consider it with the result by commenting out line 10 in my script, that mentions: "#Ignore this component." Just move the # to the beginning of the line.

3. This is possible in Python only, but you could also use a "Data Dam" component. I would do that.

Does it help?


Giulio Piacentino
for Robert McNeel & Associates

Oh man, the data dam component is rocking my socks.

This is hugely helpful, everything is functioning correctly now. That'll teach me to modify high-quality Piacentino-code...

Thanks Giulio!


Hey Giulio,

What if I also wanted to detect user object collections in addition to core libraries and addon libraries? Would this follow a similar logic?



An alternative to the data dam component could be to store the data to the document sticky thread. Accessed via scriptcontext.doc.sticky

I believe that data is saved with the document such that even if the python component or data dam component are 'accidentally' deleted the data itself is still stored in a document dictionary.

Just a thought.

Yeah good thought. Ultimately I went with the value export as txt route since the ultimate purpose would be to archive the metadata of the documents current state

the data itself is still stored in a document dictionary.

Please remember that the sticky dictionary is just a Python dictionary in a module. It does not offer persistence. See here.

Giulio Piacentino
for Robert McNeel & Associates

Oh yes, you're correct Giulio. I did try to see if the data would remain if I was to save the file, unload grasshopper, and reopen the file and it was still there. However as you've pointed out once Rhino is closed the sticky dict is gone.

So, in conclusion, write to an external database if you want stuff to be truly persistent

Speaking of which, Dave Stasiuk just added a couple of components for "packing/unpacking" data to his TreeSloth plugin. You could probably do something similar in Python by pickling the data to a file I imagine..

Ah cool thanks for pointing that out. In my case a simple Python *.txt export is good for now - I only need to export, no need to re-import and "unpack." I'd eventually like to write json directly to a web database for this type of thing.

import os

def writeToFile():

# create and open file

ghP = ghdoc.Path
myPath = os.path.dirname(os.path.realpath(ghP))

outputName = ghP + '_docProp.txt'

myFile = open(outputName,'w')

# pass values to file
myFile.write(str(value1) + '\n')
myFile.write(str(value2) + '\n')
myFile.write(str(value3) + '\n')

# close file

# confirm file write
if os.stat(outputName).st_size > 0:
print 'File successfully written as ' + outputName
print 'output file is empty - check your values'

That's one way. Another would be to use userdata on geometry, on attributes or in a custom document-wide table.

rs.SetUserText(object_id, key, value=None, attach_to_geometry=True)
rs.SetUserText(object_id, key, value=None, attach_to_geometry=False)
rs.SetDocumentData(section, entry, value)

or their RhinoCommon implementations for details.

Giulio Piacentino
for Robert McNeel & Associates

Hey all I've updated my Pull Document Properties user object.

I fixed a few errors and added the ability to write the values to a text file.

See attached if you're interested - and let me know if you have anything to add to it or spot some n00b Python that could be more efficient.

I'd still be interested in writing a function to detect all user object names (string list), so if anyone has some tips on this please let me know.









  • Add Photos
  • View All

© 2021   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service