I think this is really important.
Personally I think it’s very powerful that a Model Object can be a model object even without geometry. The fact that you can generate and or carry data along in a container and at any time in the execution flow append or remove portions of that data or inject or replace geometry etc is great and very flexible.
And of course I love to be able to use it both on reference GH geometry AND rhino.objects that are already in the doc.
I’ve been experimenting heavily with these differences since MO components came into R8 WIP and at one point in time I was convinced I never needed to bake/cache anything to Rhino ever again since I could now have ALL the possible data I could need living in data space via the Model Object.
The only reason I switched back to primarily caching most of the created geometry was for the UX of being able to “snap” to the cached geometry in the Rhino model while creating new geometry directly in Rhino or referencing said snaps/vertices with osnaps settings to easily place points and things that would get referenced into GH to “do complex things”.
More recently I’m very much interested in seeing how I can get the behavior of custom grips, snaps, etc. while still working primarily with GH model objects only and then ONLY caching geometry for reasons of exporting solids/meshes for interop with other softwares that can’t read a GH geometry preview of course.
I recently discovered the kangaroo Mouse component that lets you drag GH preview geometry around and it got me thinking of entire workflows of manipulating the GH preview geometry from within Rhino without the need to bloat the Rhino file size with Caching all that geometry.
In summary, the fact that Model Objects can support meta data, render materials, geometry, etc. it’s essentially everything I could want/need to manipulate a 3D environment. Now I’m focused on what kind of UX/UI and scripts enable us to work inside a GPU/data oriented workflow.
I guess all that GH preview geometry needs to be stored somewhere, GH file size? Memory? GPU memory? I don’t quite understand where it all lives but it seems like it has great potential to offload a lot of work from the CPU and to drastically reduce Rhino file sizes and such if everything is just “data” that is being dynamically called when it is time for it to “appear” or be referenced.
Likely I’m over simplifying but model objects are the best thing to happen to GH since GH
in my opinion… So very curious what that could mean for Rhino itself… I don’t have the answer but am eager to find out