From that screenshot, you seem to feed content into that component only, and the component will bake and cache (push and pull) the content. You are however not providing a name for that cache, so that’s why it reads ‘null’. As far as I currently understand, the cache (by name) is only available during the session it was created, @kike or @AndyPayne pls correct me if I am wrong.
Any names you want to add as attributes need to be at object level. Since a cache can be one or many objects of different type, it’s more a collection of objects, a selection set that you can later address by its cache name.
In this simple example I am adding points with a user key that is the same as the cache name in the first group, then reading that cache back in and retrieving the key/values in the second group:
Currently, right-clicking on the Object Model component and selecting Bake will do it to the correct layer. There is no need to select a layer in the Bake dialog that pops up.
Yes, if the layer needs to be specified, it needs to be added by the object Model component Or, and this is a big Or,
Note that these objects can carry a layer with them. Object models are geometry plus these other attributes. So there is a potential the object model already has a layer embedded in the object and therefore already knows its layer… I guess this is where these new objects get interesting.
Yes there needs to be a way to discover the bake name on existing objects. We are working on a way to do that.
The solution the Gijs shows wirks if it needs to be a key value.
But the Cache information is not simply a name anymore. It is actually a dictionary of information. [Unique IDs, Original Index information, Component identifiers, Cache name, etc…]. These are all things that are required to have Live Grasshopper objects in Rhino.
So yes, we need a way to extract the stored Cache Name on the objects. We are working on that. But there are some ways to store the data.
Another cool thing. If you know the name of the Cache, then running that thru the Content Cache component, the objects with that Cache are pulled into the Grasshopper definition. That would work for any Grasshopper definition, not just the one that created the Cache. But of course because the cached objects are stored in the Rhino, the Rhino file that contains those objects needs to be open.
Components with pushy buttons are not the way to go. This has been repeated so many times on this forum.
How can devs still come up with stupid components that have a trigger button instead of a trigger INPUT at this point ?
This is beyond me…
You can zoom in and enable the Pattern input and this will remove the push button and allow you to control the baking with a Boolean input. The way it’s configured now lets you have a manual push button OR an automatic way with the Boolean input. The best of both worlds.
There are already Live Grasshopper objects in Rhino.
They are called “Grasshopper objects”.
When you want to turn them into Rhino objects, you BAKE them.
All I was asking for is ;
-More official object types in Grasshopper
-An official BAKE component that would be able to bake all of these object types.
With Human and Elefront, you would bake only the added object types from each plugin, and it was just a mess because you had to use both plugins to cover all your baking needs.
But it must also be noted that the way the content cache works makes interaction between the two a lot better and easier, imo. Once baked, objects were not live anymore in previous versions of grasshopper. I find the overwriting of content super helpful, as it avoids duplicates and keeps data up to date. I wish I had had that option when I was building the definition for the big bench in Amsterdam. Often I had to update already baked content that was sent out for review, which quickly became tedious.
That being said, I agree that there also needs to be a simple way to bake without that relation.
On the contrary, I think it’s a very good way to mess-up everything if you make a wrong step.
Anyways, I’m sure some people will find it useful, and who knows, maybe even me at some point, but I find it extremely clumsy to introduce a native bake tool the way you guys did.
By the way, I find the auto-creation of one layer per named cached objects completely ludicrous.
That’s really something out of the mind of someone who never had to manage a large project.
Perhaps I’m misunderstanding what you mean by this but:
You can use multiple layers and also nested layers like so:
My Main Layer::My Child Layer::My Grandchild Layer, so on and so forth…
It only puts the objects on a single “Grasshopper” Layer per cache if the objects have not been given a directive of what layer to put it on. It has to go somewhere… so it goes into the catch all bucket of the Grasshopper layer until you define in the Model Object what layer(s) the objects should end up on.
You define a lot of these attributes such as layers, any user text and meta data, etc. on the Model Object itself, the cache is only as smart as what it is given.
I use a consistent naming scheme across different caches/object types and find it works very well.
Furthermore, with data trees, you can establish multiple object/layer/meta data relationships within a single cache component for efficiency sake.
You can still branch out layers for all objects within a single cache. The cache is just the main ‘container’ that holds all objects. If you add layer names to objects that is exactly what will happen using the branch names option.
…says the online reference on the egg-crate über-baker thing ?
I’ll try this thing again when it is properly documented.
Tired of being a blind guinea pig on that one, thank you very much.
By the way Michael, have you tried having the “Query model Objects” component that reads Rhino objects in real time and machine-gun-baking / updating objects in Rhino with the Egg-crate ?
Throw in some nested blocks in there, and I’d be surprised if it ends well.
I don’t know in what world a pushy button on a GH component makes sense, sorry.
If I have an input, I can connect a pushy button already, and much, much more.
Until I can simply bake without a funny cache system doing weird stuff behind my back, I prefer staying in the Elefront or Human world.
This whole thing reminds me of the attempt to create “history” in Rhino and why it failed miserably : because it creates a bunch of invisible links that are impossible to keep track of.
The first name of Grasshopper was “explicit history”.
This is anything but.
