Unexpected Query Model Objects Behavior

I’m using the Query Model Objects component in grasshopper to grab a bunch of BREPS from my model. As I manipulate them in grasshopper, I will sometimes need to hide objects to see preview geometry better. I noticed that when I hide or show objects, this triggers a recalc in grasshopper. Depending what I’m doing this can be imperceptible, to sometimes requiring a several second recalc, freezing rhino and grasshopper in the process.

Eventually using a data damn, I was able to determine that the hide and show triggers an update to the Query Model Objects component. I had noticed similar behavior from Elefront with their Reference components. Interestingly, I never noticed this behavior with “Dynamic Geometry Pipeline” from Human.

Is this update on hide/show expected behavior? If it is, is that due to limitations or chosen behavior? Is this something that could be disabled/given a toggle in an update?

This is the expected behaviour. I asked the developers to turn this off but they think it’s a new feature which also allows new workflows. Like do something if this layer is turned off.

For me, the lag caused by recomputing large definitions is unbearable. I don’t like the new feature.

One possible workaround to avoid the recompute is to change the display mode of an object instead of hiding the layer.

I logged a similar issue with hide/show with the older Pipeline component: " Stop GH Geometry-Pipeline from updating on ‘hide’ command?" and at the time it was logged as issue 72326. Not sure of the current status or if the behavior would be the same with the new Query components?

I agree though - personally: I do not like this behavior at all. I am currently wasting time here on the site since I am sitting and waiting for another 5 minutes or so because I accidentally hid an object without locking GH, and now the entire GH scene is recalculating for no reason.

I have noticed that this happens with show/hide, layer on/off, and sometimes even the movement of a clipping plane (though not always).

@ed.p.may

I can see having the shown/hidden information being useful, but why not make it a toggle, or give us a component that doesn’t include that? My lag is unbearable too. I have switched entire script libraries away from Elefront and to Human for the exact same poor lagging behavior. I was hoping to could stick with more first party components now with Rhino 8, but that doesn’t seem viable now.

I have found some success so far with datadams at least to prevent the reclac for a simply preview check. This is only a hack job though as I have no doubt I’ll end up with dozens of dams in future scripts, making the process of getting a desiredrecalc tedious.

Yes I’d like to be able to disable this too.

The devs say we can deactivate synchronization but that’s too much of a compromise.

Why is deactivating the synchronization and having manual control over when it updates too much of a compromise?

Because without synchronization the component doesn’t update automatically when the object changes….

I think object changes, display changes and attribute changes should be separate from each other.

Hi @martinsiegrist,

I see how this may be a problem.
We may try to avoid expiring when locked or hidden on the object itself or on the Layer.

You enumerated three cases object, display and attributes could elaborate a bit more what is included on each?

Often times I need to hide things to be able to see the preview geometry clearly. I might even want to toggle between showing and hidden. If I’m referencing dozens of different layers, that potentially dozens of different components I need to disable synchronization on each time I need to get a better look at preview geometry then reenable once I find a geometry change. The process become cumbersome and doesn’t take into account current work flows.

Here is an example narrative. I am editing a series of loft though the selected iso curves of various surfaces. These surfaces are on multiple layers. Due to the surfaces being visible, I can’t see how these lofts align with other geometry in my project. In order to see what is going on, I hide some number of my original surfaces. This triggers a recalc, and because it is a loft, the computation take 15-30 seconds even on my high end workstation. After hiding those surfaces, I still can’t see alignment. hide more surfaces and trigger more recalcs. I finally do see what I want but can’t tell how to adjust my original surfaces. I would like to quickly toggle between showing and hiding (using undo/redo) some surfaces. This isn’t possible because of the 15-30 reclac that happens not because there has been any geometry change, but because of some silly little property that has no effect on my work. I’m getting frustrated. I go turn of synchronization on several geometry reference components, taking several minutes to find them all. I can now finally hide/show my geometry to tell how to edit it. Enabled with the information on how to edit my geometry and do so, but not to see if it works, I have to once again take several minutes to re-enable synchronization. I wait for the recalc, look at the new geometry, but still can’t tell if it works. I once again have to take several minutes to turn of synchronization (getting more frustrated at the cumbersome process that didn’t used to need this) and try my toggle show/hide. I see that I need to edit again. I repeat all this multiple times, getting increasingly frustrated at this choice by the developer. Sure it enables new things, but it destroyed old workflows. Why can’t this be a toggle on the component or why can’t this be a separate component?

Two additional inputs would be helpful in large projects, allowing for more targeted Query Model Objects.

Filter would allow for rule based pre-filtering

Update settings could configure the resync options, which could possibly toggle some of the exclusions mentioned above.

The filter is an existing feature request, i’ll add in one for Update Settings as well (no sync on layer state change yes/no for example)

2 Likes

Thanks guys. I think an option with ‘Update Settings’ could solve the problem.

The three cases mentioned above are not clear. It was a quick first idea.

Synchronization can happen in three different levels:

  1. layer - whenever a layer is modified, sync is triggered. Changes to layer name, current layer, layer on/off, layer locked/unlocked, layer color, material and so on trigger the synchronization.

  2. geometry might be a better name for this main object sync option. Sync is triggered whenever the position or shape of an object is altered.

  3. attributes - adding user attributes currently recomputes a solution. This is not always necessary. Hence we need this as a secondary object sync option.

I think something like this could really improve the user experience and reduce the lag / dead time which I currently see, caused by unnecessary synchronization.

This should probably also include object specific color, material, lock/unlock, hide/show status as well.

1 Like

@kike any news on the implementation of update settings?

Any news on the update filter?

Still marked as 8.x, i’ll bump it in next week meeting and see where it stands. RH-79095

2 Likes