force recook after input change
5203 6 1- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
- jsmack
- Member
- 7803 posts
- Joined: Sept. 2011
- Offline
Changing inputs should always trigger a cook. Only rare circumstances, usually involving solvers/stash would it need to be forced to trigger. You have probably found a bug if a basic sop network fails to recook on input change.
In testing your files, I noticed you using a copy stamp for creating variations. This workflow has been deprecated in favor of compiled blocks with embedded for loops. The problem you are seeing with an apparent lack of recooking, is actually due to the behavior of the stamp expression itself. When you switch cooking to the stamped side of the network (upstream of the node doing the stamping) the value returned by the stamp expression is not the fallback value, but rather the last value to be evaluated by stamping. To fix your problem, you will need to duplicate your network and remove all stamp expressions, or make all stamp expressions conditional on the switch's state at the bottom of the network.
Ideally, you would avoid stamping altogether because it will always be prone to caching issues.
http://www.sidefx.com/docs/houdini/model/compile.html [www.sidefx.com]
http://www.sidefx.com/docs/houdini/model/looping.html [www.sidefx.com]
https://www.sidefx.com/tutorials/houdini-16-masterclass-compiled-sops/ [www.sidefx.com]
In testing your files, I noticed you using a copy stamp for creating variations. This workflow has been deprecated in favor of compiled blocks with embedded for loops. The problem you are seeing with an apparent lack of recooking, is actually due to the behavior of the stamp expression itself. When you switch cooking to the stamped side of the network (upstream of the node doing the stamping) the value returned by the stamp expression is not the fallback value, but rather the last value to be evaluated by stamping. To fix your problem, you will need to duplicate your network and remove all stamp expressions, or make all stamp expressions conditional on the switch's state at the bottom of the network.
Ideally, you would avoid stamping altogether because it will always be prone to caching issues.
http://www.sidefx.com/docs/houdini/model/compile.html [www.sidefx.com]
http://www.sidefx.com/docs/houdini/model/looping.html [www.sidefx.com]
https://www.sidefx.com/tutorials/houdini-16-masterclass-compiled-sops/ [www.sidefx.com]
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
- jsmack
- Member
- 7803 posts
- Joined: Sept. 2011
- Offline
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
If somebody is interested, direkt compare…
Performance Monitor says: UV_Layout is the “Spassbremse”
I'll try to fiddle the UVs in a compiled block, should be possible if I'm right :-)
Then refine, then maybe orbolt.
Performance Monitor says: UV_Layout is the “Spassbremse”
I'll try to fiddle the UVs in a compiled block, should be possible if I'm right :-)
Then refine, then maybe orbolt.
Edited by matthias_k - Feb. 5, 2018 16:19:19
English is not my native language, sorry in advance for any misunderstanding :-)
-
- Quick Links