I am writing some scripts for keeping track of part attributes using the usertext functionality. There is a desire to also keep track of unique part numbers, so each new part has a new number assigned to it, automatically generated as the parts are created. Parts are “created” from raw rhino geometry, so the part doesn’t exist until we assign attributes to it.
The first thought was to keep a list of part numbers and guid in documentusertext, however it quickly becomes apparent that keeping this in sync with the part number attribute in the actual parts is a pain.
The question for the rhino scripting community is what is the best practice for achieving this? Some options are:
Number the part with usertext and keep a list of part numbers in documenttext and code all the scripts that use or modify this data to keep track of it all. (Seems fraught with danger of data going out of sync.)
Keep a documenttext list and reference it back to the parts, so the part doesn’t include part number usertext. (Probably the best way I can see.)
Keep all the object attributes in document data references by guid. (Too many string manipulations due to only keeping track of key/value pairs when 3 fields need to be kept track of, guid/key/value.)
Implement a database linked to the file. (Please no.)
With part number, do you mean identification of a “type” or an instance of a type?
For example, does blockinstances share the same part number? Or, when copying a (registered) part, should it keep the part number as long as its geoimetry is not modified?
Each individual part should have a unique number, even copies…for now.
There is another option:
5. Is there a way to search through object usertext of the entire file (hidden, off-layers, etc) and pick out the data I need? (highest existing part number in this case)
OK. (But at some point in time you probably would like to be able to keep track of how many instances of a certain geoemetry is being used?)
Absolutely. You can scan tthe RhinoDoc.Objects list and peek into whatever info you’re after in each object.
I recommend using the Find-methods with filters to avoid having to search through all objects If you have like millions…), if you for exemple know that you only want to search Breps, or Meshes, or Point, or Curves etc.
Honestly, if there are duplicates of a part, each will probably have other different attributes, like name or location, so they would essentially be separate parts anyway.
If these unique numbers are only for, tracking the parts at the script level, you could consider creating a unique id and store that as usertext.
If you need sequential naming in the output you can always collect everything at the end and assign a human_readable sequaltialy named name then.
I use pythons uuid module for just that. It creates unique ids and only upon export do I add sequential names.
import uuid
#to create a new unique number:
new_id = uuid.uuid4()
print new_id
re-reading your post I think you need some other solution, can you elaborate on the part numbers you want to assign? Are the relating to something other that there moment of creation? In other words, do they represent a branch or substage so they are more than a sequential number?
These are to be human readable numbers only. They are not intended to be anything but a place marker for creating BOMs so I can just label a part with the number rather than its properties. The numbers are meaningless without the BOM so if it all gets messed up through poor scripting they can be wiped and recreated in bulk and at will.
Later down the track I plan to create a link between a solid part and a surface representation of the part (for automated unrolling and a few other things). Would it be preferable to use uuid over guid for this scenario? I note that guid cannot be stored in usertext without converting to a sting, but have not attempted retrieving this for guid reference use.
It’s also a way to keep track of the number of defined parts in the file. Not all attributes will be added upon part creation (material, description, etc), but a number will always be created.
One advantage is that it allows for copy pasting objects between files, because you control the uuid. When pasting in Rhino the object get a new Rhino GUID assigned, you have no control over.
