I cannot believe this and I’m far beyond over the moon to see this new feature. It’s just somewhat funny that months go by… we’re testing version after version in WIP and BETA, rebuilding my GH definitions to somehow bake into branches one after another, then the commercial version of Rhino 8 is released and voilà we have a ‘Cache Name’.
I hope this is going to stay.
I realized I had set a checkmark at the Branch Names option. I don’t know what to use this for yet but without this option checked, the cache name option works just fine.
I also just discovered the Geometry Cache component. Will need some time to understand the full capabilities.
Haha. I was wondering if someone would take notice. It was a very late addition but is all to the hard work of @kike. He’s the one that brought it all together…and yes this component should work seamlessly with the existing geometry cache component… so it’s also worth investigating.
The default checked “Branch by cache name” setting will create new layers per cache to help keep things organized. But the baking operation also appends a user text key with the cache name as well so you could choose to organize things that way if you’d prefer.
The idea behind ‘Branch Names’ is you can use it to isolate the full set of objects and its blocks, materials, linetypes, hatch patterns. Everything is nested under a Prefixed name. A cache becomes a “nested” sub-model inside your main model.
This way there are no conflicts with the names, in this example I push a block called ‘Column’ but on different options, if you don’t Branch Names the block is redefined and both options share the same block.
An other way to use it may be by team name, by user name, or by discipline, this way there will be no conflicting names between teams, users or disciplines working on the same file.
It’s up to the user what the cache name means on its workflow but the feature is there to help avoid name conflicts.
I think that, to make this more flexible, the user should be able to pick which types he wants to branch, and be able to disable the name branching on objects, or maybe on anything but blocks and layers, or whatever he decides or need on its workflow.
Right now is all or nothing.
Really cool addition @kike , I need to digest this and see how it plays out in my workflows but seems promising and interesting out the gate, thank you!
Possibly related, I noticed occasionally I would still come across locked (dashed orange line) reference chains between the query components and the previous bake content component and would sometimes have to replace the query component with a geometry pipeline component or create a new model object as a work around.
I’ll experiment but I have a feeling if that hasn’t been solved yet, that this new naming convention opportunity will help to solve those kinds of conflicts, thanks!
I think we need a tuturial on this, just to understand the thinking behind this feature. I’ll have to play with it but right now I’m not understanding what the Branch Names check box does that is different from having two different named caches. Can you share this definition and maybe some examples or a video tuturial?
I’ve been running into an error where after pushing geometry into the model many times, the cache will stop loading model objects.
A boolean toggle does not help, changing the cache name helps for a short time but eventually the same issue occurs.
I make definitions for some of my colleagues, and the simplest solution I’ve come up with for them is to just delete the node and create a new one. This fixes the issue, but its there any way the node could just have a “clear” or “empty” option on the node?
OK, I’m late to this game, but the general impression is that devs are carelessly pushing new stuff in GH without the slightest concern about explanation and documentation.
This has been the case in GH forever, but with this new Rhino tab, it becomes completely ridiculous.
This is a delicate and complex matter.
From the searches I made on the forum, only a pair of folks seem to understand what’s really going on, and even them are struggling to tame the beast.
A single Brep is getting passed into the CC. But there are two CacheNames being passed in. So the result in Rhino is two Breps. Essentially it was Cached twice, once for each cachename.
Based on the default CC behavior a Rhino layer is create called Grasshopper that is locked. And a sublayer is created for each Object Type. In this case a Brep.
The CC then places the two Cached BREPs onto that layer. Cached Objects can be identified in the rightmost panel with the ObjectType and now a tracking ID.
Now if we turn on Branch Name, the behavior changes a bit:
Two Breps are still cached. But now each Brep carries the Name of the branch it was cached with. This is visible in the rightmost panel and also can be found on the Object name in Rhino Properties.
In addition a parent layer was made for each cachename. And a sublayer for the object type (Brep) was made under each layer.
Each of the Cached Breps are places on each of those sublayers. So now they are separated by layer, unlike the default behavior above.
I am sure there are bunch of questions. One we hear a bunch is can the automatic layer name be controlled or turned off? Can the naming be controlled? And the answer is yes. If a name or layer is attached to the incoming object, that layer and or name overrides any of the CC default behavior.
One thing I’m still missing with the current cache component is that the cache name doesn’t seem to be visible in the Rhino document. I’m often working with different grasshopper definitions and I want to be able to overwrite cached objects from one one definition with an object from another definition. EleFront kept the bake name as user text with the object so this was relatively easy.
By adding the cache name as user text, model objects can be filtered and the user attribute value can be used as cache name to replace individual objects…
It’s even more twisted than I though…
Ever heard of KISS ?
Well in my tests, it creates a new layer under the “Grasshopper” main layer, which is absolutely not what I want.
You guys really went overboard with this, forgetting the basic, normal stuff.
Say I have created a “Beams” layer, and I just want to bake a beam in that layer with no “cache” nonsense ; how can I do that ?
