Content Cache not Purging

[nxakt]

I am using OSC messages to cache the main Grasshopper geometry into various named sequentially named entities.
I use the GHowl UDP to receive the messages in OSC bundles
I use messages of 0, 1, or 2 to trigger the actions in Content Cache. Null, Push and Purge.

In short, with the OSC messages, the geometry is not being purged

Initial state is 0, filtered as Null into the Content Cache.

I change the value of “Subtractor_Cache_1” to 1, the default Content Cache action is performed and the geometry is created, good.

I can toggle “Subtractor_Cache_1” to 0 and the geometry is maintain but no longer updated. Also good.

However when I change “Subtractor_Cache_1” to 2, showing “Purge” in the right places, the geometry still exists. Bad.

When I input the integer 2 manually by just connecting the integer 2, the geometry is purged. I cannot see a difference in the two inputs, but the result is different, OSC message shows as having some effect, but not purging the geometry.

Is there a way to force the Model Objects lookup? It seems as though the UDP/OSC message is not triggering a recalculation.

I have included to gh files. In one I have attempted to build a static bundled message to simulate an OSC message. Changing the “Subtractor_Cache_1” value in the panel to 2 does correctly purge the geometry.

Thanks for any assistance.

UDP Toggles.gh (22.9 KB)
Static Toggles.gh (21.8 KB)

[scottd (Scott Davidson)]

Without a file that shows the Subtractor elements and the temporary driven Purge, it is hard to debug.

You could record what is happening in the purge using the Data Recorder: Content Cache Updated Guide - #36 by scottd

It also matters what is being purged.

Some of this behavior has been refined over the last few service releases. What Rhino service release is running? Use Rhino Systeminfo to find out.

[nxakt]

Yes, I assumed it is tough without the OSC input system to debug. However, the chain of events up to the Content Cache is functioning and in order in every way I can determine. The geometry used to build the Subtractor Element is in previous gh file and attached images as a sphere, just to simplify things. The same issue happened regardless on geometry type.

The Query Model Objects is not being “triggered” to update. If I click on the node inputs, or toggle the check for Hidden, it then updates correctly.

I did a workaround to toggle between a point and a brep as my inputs into Content Cache, getting around the purge issue, using only pushes, this was working.

In today’s related case, I am pushing geometry successfully into the Content Cache, it shows in the output result correctly, but over at the Query Model Object, it remains an empty result. Yet if I put in a debug Geometry node, the element is there and the geometry previews. “New Cache Result” panel is empty. (The Python node “Scoop Send OSC” sends a 1.0 message to a dashboard if the brep geometry is created and not a point or null.) Restarts do not solve this, there are 15 Query Model Object nodes in the sketch.

Here is the system info requested:

system info

Rhino 9 SR0 2025-7-1 (Rhino WIP, 9.0.25182.12305, Git hash:master @ 155a98b900cf48b90ae8255b9420c4f28e1b7ac7)
License type: Commercial, build 2025-07-01
License details: Cloud Zoo
Expires on: 2025-08-15

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 128GB)
.NET 9.0.1

Computer platform: DESKTOP

Standard graphics configuration using OpenGL
Primary display: NVIDIA GeForce RTX 3090 (NVidia) Memory: 24GB, Driver date: 6-12-2025 (M-D-Y). OpenGL(4.6.0 NVIDIA 576.80)
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: Off
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 3.3

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: 6-12-2025
Driver Version: 32.0.15.7680
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 24 GB

Rhino plugins that do not ship with Rhino
D:\Program Files\Rhino 9 WIP\Plug-ins\ConstraintsUI.rhp “Constraints UI” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\X-NurbsDemo\XNurbsRhino8.rhp “XNurbs”
D:\Program Files\Rhino 9 WIP\Plug-ins\UpdatesAndStatistics\UpdatesAndStatistics.rhp “UpdatesAndStatistics” 9.0.25182.12305
C:\Program Files\Bongo 2.0 (64-bit)\Rhino6\Bongo.20.rhp “Bongo 2.0”

Rhino plugins that ship with Rhino
D:\Program Files\Rhino 9 WIP\Plug-ins\Commands.rhp “Commands” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\rdk.rhp “Renderer Development Kit”
D:\Program Files\Rhino 9 WIP\Plug-ins\AnimationTools.rhp “AnimationTools”
D:\Program Files\Rhino 9 WIP\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\NamedSnapshots.rhp “Snapshots”
D:\Program Files\Rhino 9 WIP\Plug-ins\ShrinkWrap.rhp “ShrinkWrap” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\MeshCommands.rhp “MeshCommands” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\RhinoCode\RhinoCodePlugin.rhp “RhinoCodePlugin” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 9.0.25182.12305
D:\Program Files\Rhino 9 WIP\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
D:\Program Files\Rhino 9 WIP\Plug-ins\Displacement.rhp “Displacement”
D:\Program Files\Rhino 9 WIP\Plug-ins\SectionTools.rhp “SectionTools”

[nxakt]

The before and after effect of simply expanding the Query Model Objects node. Nothing else changed. Previously undiscovered geometry, item 3, is displayed.

Which revealed the issue.

I had assumed when inputs such as Lo: Locked Objects or Ho: Hidden Objects where the Boolean was set to true (default) and then the input hidden, that the set state would remain in play. That the ZUI input would just be removed from view.

It seems that the hiding disables this input factor and hidden objects such as those created in my sketch are not retrieved by the Query Model Object Node.

Does minusing an input from a ZUI node disable it or set it to false?
Is this standard across all ZUI components?

---

This is the answer to the above two questions from Anthropic Claude:
You’re correct in your observation. When you use the minus symbol to remove/hide an input in Grasshopper’s ZUI, *it doesn’t just hide the input visually - it actually disables that functionality entirely.

When having a large scene in Rhino, and one adds the node ‘Query Model Objects’ into GH, by default it loads all rhino objects / hidden and locked. This confirms that when the Ho (Hidden Objects) and Lo (Locked Objects) inputs are present and set to true, they actively include hidden and locked objects.

However, when you remove these inputs via ZUI:

• The component reverts to its *base default behavior

• For Query Model Objects, this means it will NOT include hidden or locked objects
• The input isn’t just hidden with its value retained - it’s functionally removed from the component’s operation

This behavior is standard across ZUI components in Grasshopper. Removing an input via the minus symbol:

1. Disables that input’s functionality entirely
2. Reverts the component to its default behavior for that parameter
3. Does NOT preserve the previously set value in a hidden state

So your assumption was logical but incorrect - ZUI input removal is more like “turning off” that feature rather than just hiding the interface element while keeping the functionality active.

If you want to keep the functionality but clean up your canvas, you could instead:

• Connect a Boolean toggle set to True to those inputs
• Use a group or cluster to organize the interface
• Keep the inputs visible but minimize their visual impact

This is an important distinction that catches many Grasshopper users who expect the “hiding” behavior to be purely visual.

Is this correct?

[scottd (Scott Davidson)]

I think it depends on the component. Most of the time when hidden the input and output is disabled and skipped. This can improve performance of a component.

@kike knows about the specific query components used here.

[kike (Kike Garcia)]

Hi @nxakt,

As you pointed out, the inputs do not preserve their internalized values when are removed.
I guess the misunderstanding comes from the wording we use in the context menu that says ‘Hide unused inputs’ it should read as ‘Remove unused inputs’.

But yes this is common across all ZUI components when the input is missing the internalized value is lost.

[nxakt]

Confirmation is appreciated, yes the “hide” tripped me up.