What is Houdini trying to cook when I have the brain icon set to off (big red X) and update set to manual? Hip only has one sim network, pops, and I'm resetting keyframes for forces in pops but Houdini keeps trying to cook something? Filecaches are set to no-op.

I would love to know how to shut down all processes in Houdini when doing something like this. It seems there is always something slowing it down no matter how many things are turned off.

(sorry if I sound terribly annoyed, it is but c'est la vie)

Switch to Manual update mode to stop absolutely from cooking, lower right corner menu (normally says Auto)

Yup, I did that. And turned off the brain. No luck. It still tries to cook.

You can try turning on the performance monitor to see what's cooking or processing as a next step to debug it.

I've had problems with huge packed alembic geo and manual mode; if a sop has cooked, houdini assumes it can display it at no cost, but the gpu will lock up for a minute or two as it tries to stream the geo to the viewport.

Workaround for me is to put down a null and only display that, or in worst case close/hide all my scene views. Not elegant, but handy in a pinch.

I've had a somewhat recent situation where in addition to putting cook on Manual, I turned off all display flags and it still cooked.

I also turned on performance monitor and found the geo node that showed what was cooking in the scene.

So in that node I put a null node with it set to display. And after saving/closing, I reopened the file with a new instance of Houdini…and the scene would still cook.

There were no sims or file nodes importing data.

The only thing that helped was for me to arbitrarily go through nodes one by one copying, pasting, delete original node and rename new name to original nodes name.

These things sometimes just happen in Houdini and are difficult to report as bug since they are not easily reproducable.

I think my problem is/was related to the Viewport > Composite op, which I’m guessing is OpenGL scene redraws. It was eating up my performance so I closed the scene view and could adjust parameters without Houdini trying to cook something. When I created a new scene view, the problem came back. I’m on a Mac so perhaps its related to the QT 5 troubles?
I don’t know how they are related, or if I am correct as to what Composite is doing, but it seemed to be the problem for me in that script. Awkward though.

Sorry for reviving this old thread but I recently came across this issue with the sop version of the vellum solver.

I have a vellum solver inside a subnet inside of an hda.
The subnet is bypassed and everything inside of the subnet is bypassed as well, including the vellum solver.
The display flag is not on the vellum solver and there is no output sop that would influence the cooking.
Additionally, there is no incoming geometry, simulations are deactivated and I am in manual mode.
When I create the hda, the vellum sop still gets cooked for quite a bit(1.5 seconds).

Looking further into this I realized that putting down any of the sop versions of vellum, pyro, rbd, seems to cause the dop net inside to cook, no matter what I try.
Is this behaviour expected?
(using 18.5.462)

I my experience, adding larger HDAs to a scene requires cooking just to setup the network. Embedding the HDA into the hip tend to work, altho you basically just move the 1.5 sec into the bootup time of the hipfile instead. After that tho it's usually smooth.

Yeah, I am used to HDAs cooking a bit longer due to their size, expressions, python scripts etc.
That is expected and can be optimized, but in this case, there are dops evaluating no matter what, which makes me wonder if that is preventable.