Hi all, I’m attempting to keep count of the number of geometries in Rhino via grasshopper (let’s say update every 60s)? I wouldn’t mind if it only tracks the objects on one layer if it is easier to achieve.
*I assume the user is ONLY modelling in Rhino. Grasshopper is only responsible for tracking the numbers of geometries.
Other than that, I have been googling for a while and no luck on which directions to attempt yet…
Below is just the background of my current research (just FYI and fun and open to discussion ):
It’s a human-computer interaction project and trying to combine EEG signal and design behaviours (by tracking changes of nos. of geometries and types of commands used) to produce design suggestions to the user.
If you don’t mind loading the objects in Grasshopper, there is the Geometry Pipeline that works.
Elefront plugin also has several reference components that allow to filter by name, layer, object type, and are automatically update.
Playing around with the RhinoDoc events also seems to work.
Yes these are three different solutions.
The Pipeline and the Reference By Layer load the geometry in Grasshopper, which implies spending some time to display the meshes.
The is a very subtle difference I observed with the Pipeline, if you copy some objects in Rhino, the list won’t update until you exit the Copy command, while it updates on every click for the other ones.
The C# component only loads the object table, so there is no time lost for the display
Geometry Pipeline is a native component so I’d say that is the best solution if you don’t have thousands of objects in your files.
Hi @Cheung_Henrik and @magicteddy there is a feature in the new version of eleFront called “Ghost Geometry” that references objects but doesn’t load any geometry. This allows you to access all of the properties of the objects but without the overhead of the geometry itself. Right click on the component to enable. You can “manifest” all or a subset of the objects if you need to operate on the geometry of the objects.
Thanks Evan, I just realised I didn’t update to the latest version and now I got the Ghost geometry option.
May I ask is it a must to link the component with a Trigger component in order to let it update automatically? (If I don’t link, sometimes it will / won’t update when geometries are created/deleted)
Hi @Cheung_Henrik you if you right click on the component, you can enable auto-update of the referencing. Note this feature doesn’t work in the v5 Beta at the moment. We decided to completely re-write eleFront to take advantage of features in R7, R8 and beyond and haven’t ported this feature over yet, though it is on the list.
Any input will trigger the component in this example (e.g. a button press). For an event based trigger one could implement this code, and for a time based trigger one might implement something like this.
See the second component here, which takes a layer filter input (i.e. L):
@AndersDeleuran That’s what I used in the first solution above, the problem being that I can’t seem to override the AddedToDocument() method of the IGH_Component class from inside the C# component. So, when the component is copied/pasted, it does not register the events and doesn’t update, until expired manually once.
Hi @Cheung_Henrik v4 with the auto-update should be fine for now unless you are tracking 10s or 100s of thousands of objects. If you have someway to trigger the v5 component, then that works as well. We will sort out adding the update feature back in the not too distant future.
Is it? Looks like the script gets and outputs all the Rhino document objects, which might become quite expensive with many objects (i.e. unlike calling ObjectCount, one would assume, though I haven’t tested it) :
I was more specifically talking about the event handling, so the object count would update automatically.
I tested with RhinoDoc.ActiveDoc.Objects.Count but this retrieves the length of the table that is, I assume due to history, generally not equal to the current object number. I ended up retrieving the entire list but calling ObjectCount is indeed much faster.
Ah yes, apologies. I just tried implementing the GHPython code i wrote for this. And it does appear to not break under the circumstances I quickly tested (e.g. copy-paste within same definition, copy-paste to new definition, open/close definition):