Hi all,

Is there a way to avoid triggering a recook of a node when a parameter changes value (in my case, a popup menu)?

For context: I have a SOP HDA with several popup-menu parameters, and a “Rebuild scene” button that triggers a recook of a node inside the HDA to rebuild a bunch of geometry based on the combination of all the parameter values. This “Rebuild scene” button is a fairly slow process, and is performed by nodes inside the HDA that have dependencies on the HDA parameters.

Unfortunately, it seems that Houdini recooks the HDA itself whenever I change one of the parameter values, which causes the nodes inside to recook as well. This means that any change to an HDA parameter triggers the expensive rebuild, rather than waiting for the user to click the “Rebuild scene” button.

How could I disable this auto-recook behaviour for the parameters on the HDA? I know I can change the auto-recook behaviour globally in Houdini, but I only want to change the behaviour for this one HDA.

Thanks!

– Dave

I eventually found a way to do this (kinda). If you insert a Stash SOP somewhere in the geometry chain inside the SOP HDA, then the output geometry won't be recalculated whenever the HDA's parameter change, because the stashed geometry will be used instead. You do, however, have to click the stash button programmatically somewhere in the handler for your "Rebuild scene" button:


This triggers the stash node to stash the newly regenerated geometry, and to keep using the stashed version until next time you click your "Rebuild scene" button.

Hello,
the Stash Node will increase your file size as it embeds the saved geometry into your project.
So this might be not ideal in some cases.

It's not really clear what can be done without seeing the HDA, anyway here some good practices I've found:

- Use of switch node to bypass the main HDA network, and return the input geometry, while you set the parameters.
- Use of switch node to bypass any unnecessary node on certain conditions.
- When building your network, use a heavy to light hierarchy of operations: put the CPU intensive task at the beginning and leave the least expensive task at end (if that is compatible with the logic of your asset of course): for example, a Color node followed by a Boolean Node might not be very ideal. At any color change you would trigger a potentially expensive boolean operation.

cheers

Thanks, Andr! That’s super-useful advice. Much appreciated.

One extra thing I realized about the Stash node approach is that the geometry stash can’t live on the Stash node itself, because the Stash node is inside a locked HDA. To work around that, I’ve added an (invisible) geometry property on the HDA, and made the Stash node’s geometry property a reference the HDA’s geometry property. That way, my “Rebuild scene” button on the HDA can update the HDA’s geometry property, and the Stash node inside its network will use that stash instead.

Oh, and I forgot to say: you’re right about the Stash node storing the geometry in the file itself. Sometimes that’s a good thing, and sometimes it’s not, so I’m considering using a File node as an alternative to the Stash node for breaking the auto-cook cycle. (This is the approach the SideFX Labs Exoside Quadremesher HDA takes, IIRC.)

You could try also a Data Parameter, where you can stash a cache of your geometry without writing to disk.
have a look at this post for an example
https://www.sidefx.com/forum/topic/42487/?page=1#post-190845 [www.sidefx.com]