I’ve come across what I believe to be a bug with the new ‘Bake Content’ component in Rhino 8 GH.
Baking content generated from grasshopper seems to work just fine, however if I leverage a component such as “Query Model Objects” at the beginning of the script to reference some geometry in rhino and then “do some logic here” and finally attempt to bake the result, it creates a yellow dashed line where it connects back to the “Query Model Objects” component and that component also turns yellow returning a warning that it has been expired by another solution and it gets very slow and glitchy.
This occurs when the baker is turned on with a boolean set to true and the “Query Model Objects” component is also set to update automatically.
If I create a rudimentary logic gate between the “Query Model Objects” component and the “Bake Content” component and feed the boolean result into the bake content, it will only bake if a change is detected (such as a change in GUID, curve length, or whatever defines the logic gate).
Given that the yellow dashed line shows up with the caution of the object being expired by the baker, I’m wanting to think maybe I am using this wrong? But for now I’m reporting it as a bug as it seems like unintended behavior.
It appears that the two Baker nodes in the second screen snip are battling for the attention of the “Query Model Objects” node, as the content that is being baked is generated downstream of the “Query Model Objects” node.
Interestingly there is a 3rd Bake node baking logic based on that QMO node and that one is completely unaffected and bakes relatively fine.
Please see attached for a simplified definition that illustrates the issue:
I am referencing from one layer and baking to a different layer so I don’t think it is a layer conflict? Unless they are both trying to pull data from the Layer Table at the same time?
I have attached the simple GH definition and you can toggle between Rhino 8 & Elefront baking method to illustrate the difference; both solutions seem to result in freezing or severe performance degredation.
I was using legacy Elefront Reference By Layer & Bake Objects, both running in real-time/automatic update mode without any issues previously even in a very large and complex GH definition.
The workflow I used to use and what I expect the result to be is that I can reference geometry from the Rhino doc, perform GH operations based off of those geometry (treating the geometry as a sort of control guide reference), and then bake the resulting GH operations to the Rhino doc.
So as an example this script simply takes the boundaries of “floors” and tags them as such, when you move a sub curve or the overall floor curve, it should update those tag positions in real-time and then be done and not firing anymore logic unless a change is again detected in the reference geometry.
Downstream there would be additional logic based off of these input curves such as Floor slabs being created and baked, exterior walls being created and baked, etc. So multiple end results/bake results streaming from one single reference node.
In transparency I have also posted a parallel topic here focused on the Elefront side of things:
