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.
Thanks Teddy it works beautifully, may I ask what are the differences between the three lists produced? They produced the same counting (especially the 2nd and 3rd list produced exact same names.
Or they are 3 different solutions? (seems they work independently perfectly as well!)
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.
Thanks for the explanation I will stay with the Geometry Pipeline then. I would just disable the mesh-display to make it faster(?).
It seems the C# has some update problem when I just copy-and-paste the component from a .gh to another .gh file. Other two works well. Thanks a lot again!
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.
Thanks Evan, since I’m using R7, does it mean for now, I can only choose either:
(1) Use v4 (without Ghost geometry), or
(2) Use v5 beta + trigger component?
(I’m happy to use whatever is more stable for now, since I’m still at prototype stage )
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) :
Yeah getting events to work predictably in scripting components is tricky! As I recall, the dynamic GHPython example I linked to above suffers from a similar issue.
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.
Thanks Seghier for suggesting a new method. I had a try and it seems only updating when the Toggle is restarted. I’m not sure is it my computer problem or not anymore.
For now, the most stable component for R7 which can update without timer/button is the ‘ReferenceByLayer’ of eleFront plugin.
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):
If you want/require a native solution (that also calls the Rhino document ObjectCount method) the script above might be a solution. Though I haven’t thoroughly tested its stability.
):
)
