I am using the Rhino Block instance component to parametrically place blocks in my model space. after placing these blocks, I deconstruct them, perform an solid intersection with some other geometry, and reconstitute them into a new block with a new name. The solid intersection is slow, but it is what it is.
I’m finding that when I toggle the visibility of a layer used in my referenced blocks, this triggers a recompute. I assume that the script sees a layer change as some kind of update for the block. Is this intended behavior? What is the logic for a layer visibility changing being a trigger for block reference?
Are you using the Grasshopper Rhino components? If so I think there is some hope for a new component or option which will allow not listening to layer visibility changes.
Using the Grasshopper Rhino components in large definitions I find it very annoying that layer visibility changes trigger a recompute.
As a workaround I sometimes turn off curves in the display mode options.
Yes it the rhino components. I remember talking about this several months ago, but assumed that was just for referencing in geometry, not for blocks themselves. I had also thought the update/change was alreday made.
That’s a clever work around. Did you set a command macro up for it too?
So, part of the issue here is that we’re now talking about Model Objects which contain the raw geometry, but also all of it’s attributes. So, prior to these new Grasshopper components being available in the Rhino tab, your GH definition would update whenever you changed something in the model (ie. move an object around, etc.). But, now the objects contain more information about them (ie. attributes) so if you change something about a Model Object, such as modifying one of it’s attributes, then that will trigger an update event, just as it would have if you were moving that object around in the viewport. Does this make sense? We are looking into how we might be able to expose various events so that you could manually subscribe to some events and not others… but in general, this is not how Grasshopper has ever behaved before (ie. updates always happen if a referenced object is modified).
If you reference ‘Geometry’ only geometry changes expire your solution.
If you reference a ‘Model Object’ any relevant change on the model will expire your solution.
Here I changed the layer Color and visibility.
Only the blue group is expired reflecting the changes, the other one stays until a geometry change occurs.
Interesting. Are you working on that other component I think you mentioned a while ago where the user could choose which level of changes causes a recompute?
In the same vane as Martin, unless I am modifying layers using grasshopper, I think layer state changes should be completely ignored as the option. That should apply to everything accept the name of the layer. At a minimum, I should be able to ignore layer visibility changes.
What makes how you are running the component different than Andrew Heumann did in Human? When I was using his version of these components changing layer visibility didn’t expire my results.
A thought good or bad you decide, but perhaps the selectable attributes could be added to the data dam component, might be less surgery for all the rest of it.
