No matter how I use the Content Cache component in R8 it seems to only expire my query model objects and create an odd infinite loop where it continually appends the Cache Name into the Model Object being added to the document.
This has completely bricked all the scripts using these components on my end.
Any ideas if I am doing something wrong here as a user or is this a bug?
Here’s a video demonstrating the issue:
It also appears that the cache name creates a parent layer for the baked content.
Perhaps I need a major rework of my previous logic in that I’m not grasping this new method?
Separately, it seems that if you select the Content Cache node it highlights everything contained within Rhino and labels it which is pretty awesome I must say!
Thanks for your response!
EDIT: It appears that if I uncheck “Branch Names” it does retains my original parent::child layer structure as intended so I think that’s correct but it still is locking my query components in larger definitions for some reason.
I had similar issue with the infinite loop similar to the materials assigned to the referenced layers. I found that “Specifying” Material name instead of “Querying” May help you overcoming this expiry chain.
Though in this case I need it to query any curves that are added to the “Floors” layer so that the user can simply draw polylines or whatever and it will pick that up as “floor control lines” from that layer.
If the user has to specify an object name or something that defeats the whole ease of use. Also prior to R8 official release it worked just fine without a query object name so I’m hoping this just an oversight and not a requirement to avoid the infinite bake loop.
This will cause the Content Cache loop bug on my end, I’ve reduced it to a simple file.
Branch names has to be checked on in the Content Cache component to trigger the loop and expiration of the query component repeatedly, if this is disabled the bug does not seem to occur.
Thank you for this conversation- I’m also working to understand how this component could best help me, especially Name/Branch Names. Further comments about how people are integrating would be welcome!
The component is potentially powerful for my workflow & I like it but I can’t quite yet place it properly in the methods for iteration and part naming I built around the Elefront bake component.
When I can do enough tests I’ll ask a specific question somewhere, but the way the Name input becomes the name of the object in Rhino is tricky for me because in my old method I have relied on the Bake Name as an upper level category and the Object Name as a more granular part name. I can’t quite parse the hierarchy of the names I give layers and objects through the Object component vs the hierarchy applied by the Bake component.
Just looking at the updated version of this, it makes more sense to me now and has lots of possibilities. Will definitely help me organizing my iterations and parts. Thank you!
I’m also having issues with the newest version expiring “unrelated” query components and additionally throwing errors about indexing, please see this separate post and example file here:
You can see here this one is perpetually “expired” and the definition solve time is nearly 1 minute, prior to the most recent update this definition solved average was less than 2 seconds for 8000+ components:
A Manual toggling of the “Toggle” Boolean for the Push input will reset the expiration and remove the orange wire.
The huge time increase is directly related to the interaction of the Content Cache and Query components expiration relationship and I can’t figure out how to separate them as the Content Cache is expiring Query components that aren’t even similar.
Example would be a cache of Brep Model Objects going to layer “This Layer::This Layer Child” is expiring a Query Model Objects component outputting curves with Layer Name input as “Unrelated::Unrelated Child::Please Do Not Expire Me Grandchild”
Furthermore, it appears that some Caches are expiring ALL Query components simultaneously, regardless of whether or not they are connected by name or by wiring in the canvas. This is resulting in a 1 minute solve time while the expiration refresh completes for simple operations like moving a single point that was referenced in a Query component.
I’m trying to understand how other people use the QueryModelObjects and ContentCache -components in their workflows, because as they are I can’t really use them and its preventing me from transitioning from Rhino 7 to 8 as the issues are essentially at the beginning and end of my scripts - the Referencing and the Baking.
I suppose a more common workflow than mine is to QueryObjects and create completely new attributes for them, rather than seek to tweak copies of them and to QueryLayers for the purposes of assigning objects onto them or modifying them directly, rather than making slightly modified copies of them with new layer-paths.
I keep thinking there must be something I’m missing or don’t understand but I’ve been struggling this for months and months and checking the Service Candidate Releases as they come along.
Rhino 8 is so promising but I don’t dare switch yet!
Elefront carries attributes across it’s “Extended Geometry” data type, R8 carries attributes via the “Model Object” data type. This is basically just a container for things like geometry, user text, material, etc.
When you do geometrical operations such as move, scale, etc. you are modifying the geometry of the model object but this does not always mean the attributes go with it. If a component only outputs G then it’s only outputting the geometry itself and you need to pass the Model Object O output along with it to continue the attributes flowing along with it.
I’ll take a look at your example file in your linked post and see if I can demonstrate what I mean there.
I was using elefront for everything and at times the R8 workflow change was a bit stressful or bugged but now it’s pretty solid just slightly different than what we may be used to coming from Elefront.
The trouble for me is that passing the Model Object O output not only continues the attributes (which I want) but also the Guid of referenced RhinoObjects along with it (which I don’t want)!
So instead of getting new geometry in a new object - a copy - I’m modifying the existing RhinoObject in the Rhino Document.
Sometimes I do want to modify an existing Rhino Object’s attributes for which EleFront (and Human) have a dedicated component.
(… and sometimes I want the object, geometry, attributes and all, replaced wholesale with RhinoCommon using ObjectTable.Replace Method (ObjRef, RhinoObject) )
The newfangled ‘virtual’ ModelContent is just too slippery and opaque for me, it seems. For now!
