I am procedurally generating drawings with Grasshopper via the R8 components.
Creating linetypes, hatches, etc. within GH then baking/caching to Rhino Model for the end result of automated Construction Documents (Full Set with many sheets, Floor plans, elevations, details, electrical plans, etc. most of it is going smoothly)
Unfortunately, every time GH recomputes, it ignores the Per Detail visibility attributes set in Rhino Layers.
In example, If I generate a series of curves on layer “Diagram::Test Curves” it will show up in a Detail View on a layout page despite the layer “Diagram::Test Curves” being set to “New Detail On = Off” and “Layout On = No”
I have a feeling this is happening because the example layer “Diagram::Test Curves” is being created dynamically at bake time in GH and therefore it either is not updating the Rhino layer table, or reading form the Rhino layer table to understand the Detail specific visibility settings that exist on that specific layer in between bake “cycles”.
This endeavor is great! I can see your point. likely this issue is due to the intention of the feature. it is always easier to assume <Create a Layers , Override Existing> than <Checking Layers, If existing then keep, else create new layers>
I’d love to see a solution for this one is implemented.
Thank you for the hard work testing these features for usability.
I’m definitely thinking that’s the default behavior, that it checks against the Grasshopper exposed options on the components but ignores the others for now.
But man, it’s a bear to check the visibility across a full document set
Hopefully it can be updated to accommodate existing layer visiblity or set it from within GH.
This definition is baking two new circles on two new layers.
Since are new, Grasshopper is fully replacing them, this way when colors are disconnected and all is pushed again is pushed with the default values and honors only to what you have on the canvas, everything from the previous iteration is lost.
All this content is still volatile even is already on the model because didn’t start from a reference on the model, so is not updating but replacing, else after assign the orange to the object and deassing it back the color would stay orange no matter the color you assign to the layers.
Right now to enable the behavior you are looking for you need to reference the layers you want to push with all its attributes defined, included the per-viewport visibility you edited from the UI.
If missing ‘List Item’ will return nulls and ‘Replace Nulls’ will pass the names, else the existing Layers are passed.
With this setup all the Layer attributes are present in Grasshopper since the start of the solution and preserves them when pushed.
I know is a workaround but I hope it helps until we have something to control layer attributes per detail.
Unfortunately there is a bug in 8.1 that does not allow you to create a Cluster with all this group of components.
In 8.1 ‘Query’ components do not expire when there is a change on the model if they are on a Cluster.
This is fixed in 8.2.
Thanks for noting that! When the bake component was first introduced it had some erratic behavior when clustered so since then, anything that I am using to reference, or bake to the model I have been keeping those components in regular graph space and clustering in between as needed.
That being said, I’m looking forward to the opportunity of it working inside clusters as that will of course be really beneficial on repeated use cases and graph organization.
