Yup, I’m not a fan either
Can you elaborate what you expected to happen? To me, this is the intended behavior. In you’re example, you’ve got two Query Model Object components, each with a specific layer filter. The Query Model Object component’s job is to return all of the objects in the model, while trying to be smart about the filtering. When you toggle the layer visibility state, different objects are shown in the model, thus triggering an event in the Query Model objects. You can see in the video that toggling on/off the “Default” layer only triggers that particular Query component (the lower one is not fired). The opposite can be said when toggling on/off for “Layer 01”. So, to me this is exactly how it’s supposed to behave.
I see it’s more than just the ID of the object…
However, let’s imagine a large definition and the source object layer is turned on and off.
The current situation means the entire definition is recomputed.
I think it would make sense to have a stripped Reference Model Objects component which gets just the ID’s. Something like this python component with an option to have it auto update when the id’s change.
reference_ids_by_layer.gh (28.1 KB)
geometry_in_two_layers_and_a_block.3dm (51.8 KB)
I’ll try to look into your suggestion… but I did want to clarify something. When the query model component triggers a new solve instance, Grasshopper tries to only update the components whose data has been affected by that change, not the entire definition. So, let’s say you toggle “Layer 01” on and off… the query model component with the Layer 01 filter will be triggered, but only the components downstream from that component will be recomputed. All of the components connected to the other query model component (linked to Layer 02) will not be recomputed… so it’s not the entire definition that gets recalculated… Grasshopper is trying to be smart about which components need to be recomputed and when. I just wanted to clarify that point.
I think I got that
But what’s the point of recomputing whatever comes downstream just because an attribute has changed? The geometry output should only update when the ID changes.
I guess I would disagree here. With the new dynamic baker, the guids of the objects aren’t changing very often… which means that the query component wouldn’t really be of much use. The way the query component is setup now, it ensures that all of the data (including all of the attributes on all of the rhino objects) will be up to date all of the time. Of course, if you want more manual control over when the objects get updated, you can always turn off “Update Automatically” and you can trigger the update whenever you want. This seems to me the best of both worlds.
So you’re basically saying either accept the lag or update manually… ?
What’s the benefit of recomputing when a layer is turned off and on?
Well, for me, it’s about keeping the Grasshopper data in sync with the Rhino model. Let’s say you had a Grasshopper definition which was using the object’s visibility state as a value to determine when to perform an operation or not. For example, you could feed the visibility state into the Dispatch to component and only perform certain operations based on those values. If you toggle the layer on/off, but nothing happens in the Grasshopper definition, then there is now a disconnect between the model and the Grasshopper data. If we keep all of the objects up to date even when the object’s attributes change, then we can ensure data integrity.
Overall that makes sense.
However I would isolate objects and their attributes.
Since the ID or guid does not change when the layer is turned off or on, I don’t quite understand why the geometry output needs to update?
In a large definition the lag can be really annoying and just because a layer is turned off?
It makes sense to have the option to use all attributes and have everything up to date is important but the attributes shouldn’t cause unnecessary updates on components.
Hi @AndyPayne,
I’m coming across the issue where the Bake Content component expires the Query Model Objects component and causes lag and/or fires frequently enough that it almost freezes the script.
Real-time referencing of data AND real-time baking is critical for the workflows I use and I’m hoping it’s a misuse/user error on my end of things.
Could you please elaborate on possible causes for this error so I can troubleshoot on my end more?
Should I be looking for mismatched data trees, null items, something else?
As best I can tell all of my content is “aligned” data structure wise and grasshopper default geometry types. I’m also nativizing my script to only use Vanilla GH components so I don’t think it’s a plugin conflict.
I need both the Bake Content component and the Query Model Objects component to be set to automatic simultaneously.
As an example, baking simple Leaders, the Bake component (BC) connects to all 3 Query Model Objects (QMO) components in the document and expires all of them despite them being unrelated.
Is the issue that these QMOs have no filter set, so they are referencing all objects in the doc, creating a conflict with the BC?
Simple Bake Logic:
Expiring These Nodes:
A.
B.
C.
After further testing, it appears that if I further filter the Query Model Object components being expired by the bake, to get them “out of the same boxing ring” so to speak, the script works.
By adding a layer filter input, it’s not longer conflicting:
Any chance the warning “Query Model Objects Expired By Bake Content” can maybe name the conflict so it’s easier to troubleshoot?
I would expect this error to happen if I was trying to bake to the same layer that I was referencing, but in all these cases I’m generally referencing the document at large and then baking to a completely new layer. It seems to me this should bypass the conflict but that’s only my two cents and perspective.
Thanks for reading!
With a bit of help from Bing AI and whatever I could find about event handlers here on this forum I put together a c# script that should only recompute after the content of a specified layer has been manipulated.
I’m not someone who does everything in Grasshopper. The use of simple input geometries which are easy to manipulate is in many situations quicker and more intuitive compared to a fully parametrized approach.
I’ve been using EleFront for a few years and most of my definitions use EleFront to reference and bake geometry. Over the years I’ve gone from I forgot how many plugins to just a handful of plugins - trying to do as much as possible with native components.
Honestly, it was a relieve when the new Grasshopper Rhino components were released and I’m super happy with the possibilities overall. But. The recompute strategy is a real pain.
I want to be able to quickly turn on / off a layer and I have absolutely no patience to wait for the rest of my definition to update when it isn’t really necessary.
In real Rhino fashion, instead of forcing the user to adapt to a certain procedure, the query model objects component could allow the user to choose from a few different levels of attention…
A listener component would be another approach. The component would let the user choose from different events such as:
- Geometry has changed
- Attributes have changed
- Key or key combination has been pressed
I’m not a programmer but here’s a definition with everything in it and a Rhino file which can be imported.
on_select_mrtn.gh (27.4 KB)
import_content_layer_filter.3dm (753.7 KB)
Anyone know why I don’t have the Query Model Objects component in my GH?
Are you using Rhino 8 Beta?
Understood. I am not.
Give it a go! That’s where the Query Model Objects component lives under the Rhino Tab in Grasshopper and there’s lot of other awesome new components in there as well.
Query Model Objects component is great but there are some issues with how it affects performance and how it passes the data.
System Info
Rhino 8 SR7 2024-3-28 (Rhino 8, 8.7.24088.06001, Git hash:master @ f39d2478d0e77eb325f46d0c6d8cfc8754fe44b2)
License type: Commercial, build 2024-03-28
License details: Cloud Zoo
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 64GB)
.NET 7.0.11
Computer platform: LAPTOP - Plugged in [95% battery remaining]
Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA RTX A3000 12GB Laptop GPU (NVidia) Memory: 11GB, Driver date: 2-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.61
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA RTX A3000 12GB Laptop GPU (NVidia) Memory: 11GB, Driver date: 2-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.61
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Secondary graphics devices.
Intel(R) UHD Graphics (Intel) Memory: 1GB, Driver date: 6-15-2023 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port
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: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 2-15-2024
Driver Version: 31.0.15.5161
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 11520 MB
Rhino plugins that do not ship with Rhino
C:\Users\Czaja\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\Bella (813de3fb-18eb-405f-bfcd-b0b4d3da91fb)\24.2.0.0\bella_rhino.rhp “Bella” 24.2.0.0
C:\Users\Czaja\Desktop\Rhino_7_Win_2023.0417\HDRLightStudioTexture.rhp “HDRLightStudioTexture”
C:\Program Files\Common Files\McNeel\Rhinoceros\8.0\Plug-ins\Crayon (39629248-4fa6-47b8-83c7-745a7efea259)\1.2.0.0\Crayon\Crayon.rhp “Crayon” 1.0.0.0
C:\Users\Czaja\AppData\Roaming\McNeel\Rhinoceros\BlockEditNew\BlockEditNew.rhp “BlockEdit” 1.0.0.0
C:\ProgramData\McNeel\Rhinoceros\7.0\Plug-ins\Datasmith Rhino Exporter (d1fdc795-b334-4933-b680-088119cdc6bb)\DatasmithRhino7.rhp “Datasmith Exporter” 5.4.0.0
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 8\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.7.24088.6001
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”
1. It takes a very long time to update Query Model Objects by simply toggling on/off one of the layers. There is nothing else in this GH document that would add complexity and make it work that long
2. This one I consider as a BUG. Locking one Layer makes the Query Model Objects component work for a while and as you can see in the Param Viewer component, the Layer obtained from the Model Object does not show changes made to the Layer (Lock/Unlock). Expected behavior and performed instantly is shown by the Query Model Layers as it passes the info about Lock/Unlock just fine.
3. This is probably by design but maybe some users will find this observation helpful.
Even if Grasshopper Solver is disabled Query Model Layer component passes some data and it’s slowing everything down. So right now, if you want truly disable the Solver, you should also switch to the blank Grasshopper document or Disable Query Model Objects component and disable the GH Solver.
This bothers me too! The problem is the layer visibility attribute which updates everything. Super annoying on heavy definitions.
One thing that helped me is to be more particular with layer filtering.
@Czaja did you see the other topic:
@Japhy mentioned other possibilities for filters.
Thanks for the link, interesting read. I agree there is a usability problem.