The Query Model Objects component seems to recalculate whenever geometry in Rhino is modified.
In the video below the lag is demonstrated when hiding / showing one simple Rhino box geometry in wireframe mode which is unrelated to anything happening in Grasshopper.
Adding or deleting geometry also results in the same lag.
The Rhino file below is saved small and contains 600 spheres on one layer and a box on another layer.
query_model_objects_lag.3dm (1.9 MB)
query_model_objects_lag.gh (14.5 KB)
Hi Martin -
That does seem quite slow. On the list for a closer look: RH-74547 Grasshopper: Query Model Objects leads to slow viewport response
-wim
Thanks @wim I think it is not just slow.
I don’t see why the component is triggered by something unrelated happening in the Rhino viewport…
Hi Martin -
That sounds like a misunderstanding of the component:
Only panning and zooming that happens in the Rhino viewports is unrelated to what this component needs to track.
-wim
So this component is constantly evaluating if there is new geometry which matches with the filter input?
I thought the new Rhino components could replace Elefront.
Here’s a video of how this looks with Elefront:
I often get this white border on the Grasshopper canvas when I undo something in Rhino. To continue, I need to click the canvas.
In this video you can see how dragging an unrelated object in the Rhino viewport causes the Query Model Objects to update despite the filter. The data dam also updates. No preview is on.
This is what I’m doing in the video:
In the next WIP, I’ve added a new functionality to all Query components to disable the “update automatically” feature of these components. By default, all of the query components hook into a bunch of event handlers so that if an object is added, modified, deleted, etc. to a document then the Query component will automatically update. There was a slight time delay added to this update (250 ms) so that other events in the queue have time to complete. Now, there is a menu items on the Query components that you can turn off “update automatically”. When you do this, an “update” button is added to the bottom of the component, and the query should only be updated if you click on the button. Essentially it removes all of the Rhino document event handlers. I’ve also modified the delay to only 100ms so it occurs a little faster. Hopefully all of these changes will make your document be more responsive or only update whenever you want it to.
Thanks for the info, I’m looking forward to try it.
Andy, I’ve just tried the updated component. While the option I don’t think it solves the problem.
I’m observing the following things:
Rhino 7 Elefront 4.2.2 Reference by Layer does not update when an object on another layer is manipulated
Rhino 7 Geometry Pipeline does not update when an object on another layer is manipulated
Rhino 8 WIP Geometry Pipeline does not update when an object on another layer is manipulated
Rhino 8 WIP Query Model Objects updates whenever something is manipulated in or added to the viewport.
Rhino 8 WIP Elefront 5.1.2 Reference by Layer updates whenever something is manipulated in or added to the viewport
Rhino 8 WIP 4.2.2 Reference by Layer does not update when an object on another layer is manipulated
I don’t see the benefit of having a component that detects changes even though a filter is connected to it. As mentioned in a previous post above, dragging an object on a layer other than the one used as a filter updates the component. That is the same thing as referencing everything and then filtering for content of a specified layer.
I’m not a programmer but I’d guess it must be slower than filteringlayers first and then get the geometry of a specified layer.
The Geometry Pipeline works as expected in both Rhino 7 and 8 WIP. I’m not using it much since it does not allow inputs with concatenated text and or numbers. But it still works as expected so in theory also the other components should be possible to work like this.
I have not reported this misbehaving of the new Elefront component yet.
Thanks for all your work on this Andy!
I have to second what Martin is saying about the filtering operations.
While there certainly is benefit in having that component be able to reference the entire document it should be overridable to search the filter input exclusively while retaining the “Update Automatically” functionality yet only listening for changes within the applied filter criteria first.
There are cases where having a manual refresh button are great but the most prominent use case on my end is not having to ever push a button to refresh something. I provide users with a global logic gate that enables or disables real-time baking/referencing but this is almost always left on and the the script logic runs everything real-time as you modify the rhino doc.
The input info says a wildcard (*) input will return all available geometry.
The component behaves differently. I think it should not import anything by default.
The inputs are empty, yet it references everything.
The EleFront Reference by Layer component by default has an empty input and is orange. As soon as an input is connected, it goes gray and references from the layer specified.
This is how I’m using the EleFront bake component for baking content per tree branch.
My workflow to place panels on planes of a climbing wall isn’t fully automated and requires slightly different inputs on every plane. It also allows adjusting some of the details per branch on the fly.
A single bake component bakes to three different layers in one go with different attributes, keys and values.
The bake name is specified per plane. On the screenshot it’s boulder design number 14, plane 01 which consists of 16 panels. The bake name for this baking procedure is tied to the panel 01…
I’m using keyboard shortcuts to trigger the bake component so I don’t need to navigate the mouse to a button for baking. I really like how the new Bake Content component bakes geometry in real time.
All I need is a user attribute bake name please 
Performing as expected, much better thank you!
Thank you Dan and everyone else who’s been working on it. The component almost works as expected.
When I create / drag / paste a Query Model Objects component onto the canvas, the new component has the preview on. If the Rhino file is large, it takes a moment to load.
If the preview was set to off by default, this lag would not exist.
I almost always use a custom preview component to display objects. Hence I usually have to turn off preview on both Model Object and Query Model Object components.
What is the decision maker whether a component has the preview on or off by default and could this be changed / customized by a user?
Hi Martin. To clarify a bit about the recent update. First, we added default values to all the inputs of the query components. Mostly these are “*” by default so that they return everything. However, we did make the change so that if you clear that value (ie. the name or layer filter is empty) then the component returns nothing (per your request).
In addition, we added more “smarts” to the event handling. Now the query components should only update the definition if the item that was modified matches the query filter. Hopefully this will lead to less sluggish behavior as it wont be updating the Grasshopper document for changes in the model that you’re not concerned about.
Lastly, the default behavior for all components is to show their “preview” visibility if any of the output parameters contain geometry that can be previewed. This can be overridden, but it would be counter to the primary way all components currently work and I think we’d need a convincing argument for why the preview should be turned off by default. For most people who are prototyping things, I think they prefer the preview turned on so they can see the “stuff” appear when the component is added to the canvas.
Thanks for the reply, Andy. I’m happy with most of the recent changes.
I’d prefer if the inputs were either empty and the component doesn’t import anything by default or the preview is off.
When I’m working with 3D scans, a file can easily be 1 GB or larger. When the preview of the Query Model Objects component is on by default, I need to disable the solver before placing the component on the canvas or I get to wait a few seconds until I can proceed. Delay is about 5 or 6 seconds with a 1.2 GB file and the viewport set to wireframe.
I guess I’ll create a user object for now.
Rhino 8 SR0 2023-5-16 (Rhino WIP, 8.0.23136.12095, Git hash:master @ 169a2fb7efa6d6e17271d883a1aee11766bbdab4)
License type: Kommerziell, build 2023-05-16
License details: Cloud Zoo
Expires on: 2023-06-30
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 1.3e+02Gb)
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA RTX A5000 (NVidia) Memory: 22GB, Driver date: 4-18-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 528.95
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1
Secondary graphics devices.
NVIDIA Quadro K2200 (NVidia) Memory: 4GB, Driver date: 4-18-2023 (M-D-Y).
> Accelerated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 4-18-2023
Driver Version: 31.0.15.2895
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 23028 MB
Rhino plugins that do not ship with Rhino
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\KeyShot9RhinoPlugin (ecfe8d1f-876a-460f-aa5e-3dd816936811)\1.4.0.0\KeyShot9RhinoPlugin\Rhino 7\KeyShot9RhinoPlugin.rhp “KeyShot9RhinoPlugin” 1.4.0.0
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8 WIP\Plug-ins\Commands.rhp “Commands” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8 WIP\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 8 WIP\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8 WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\RhinoCode\RhinoRoslyn.rhp “RhinoRoslyn” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\SectionTools.rhp “SectionTools”
C:\Program Files\Rhino 8 WIP\Plug-ins\RhinoCode\RhinoCodePlugin.rhp “RhinoCodePlugin” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\RhinoCode\RhinoCPython.rhp “RhinoCPython” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.0.23136.12095
C:\Program Files\Rhino 8 WIP\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8 WIP\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8 WIP\Plug-ins\ConstraintsUI.rhp “Constraints UI” 8.0.23136.12095
Guys, the Grasshopper Rhino Query Model Object fires when layers are switched on and off.
I don’t think this is helpful since everything downstream is recalculated. Am I missing something?
test.3dm (49.3 KB)
test.gh (7.6 KB)
I just discovered this as well. In a large definition it creates a very long pause when managing layers such as turning a layer on/off.
Yes. It’s a bit annoying…
