Hello. I’ve been often having the issue of the logic that I make in TD that doesn’t update to higher levels. Scheme is like this: In a custom base I have a specific logic made with chops to affect the events in the image, but when I go up a level, this logic is distorted.
I have a recorded example of it: TouchDesigner problem - Google Drive
In the first video a png of a hand approaches to the a spot and then comes back. When we go level higher, it doesn’t come back; it disappears.
In the second video, I show chops. I used timer instead of trigger because I can break it in any moment before finishing, and then I simply switch with animation of going back. It looks like this switch operator isn’t updating.
I classified this topic as a bug, because I don’t think it should work like that, but I believe I am not the first one to witness this kind of behaviour and there must be some tips of working around it to force this switch to update all the time.
It’s quite hard to see from these videos what your network is actually doing.
Are you able to create a small network which demonstrates the issue and upload that toe file?
Also it’s always a good idea to read this paragraph in the docs:the order of cooking
which explains that TD is pull based instead of push based. This means that nodes only cook if their output is requested. (And you looking at the panel of a node, also means requesting output!)
What you describe in your case, going up a level, also means you are not looking at the nodes in that COMP anymore, which could mean nothing is requesting them to cook anymore, and maybe you need to wire things differently. But hard to say for sure without opening an actual toe file.
Hello, thank your response and that you try to help. I recreated the issue in a less complex project. Instead of hand there is a circle.
I read today this document; i tried to request those chop values from the higher levels, but that didn’t work
the issue is that the whole chain going into the second input of the Switch CHOP does not cook unless the index of the Switch has become 1.
Several ways to solve this, here are a few:
add a Null CHOP after your math1 CHOP (just before the Switch CHOP) and set its cook type parameter to selective
or you can use a Cross CHOP instead of a Switch CHOP (this keeps both inputs cooking all the time)
So this is not a bug, but by design. The pull-based principle of TD is a core optimization to enable networks to run in real-time (it skips everything which does not contribute to current output).
Thank you, it worked out. So my apologies to derivative for calling it a bug
Would you be willing to help with one more similar issue. I would be very grateful
My team runs a permanent installation that uses data from lidars for interactive floor projection. And we have a problem that data from OSC IN dat stop cooking after sometime (sometimes a few hours, sometimes a couple minutes). We need to have the window with osc in open all the time. On the right of the screen shot you see some panel with some colors; these are the data that directly changed to top and displayed on the main screen, so the cooking it is always needed, but it doesn’t work It runs in touchdesigner instead of touchplayer, because we were unable to figure this out.
Could you have a look in your free time if there is a mistake in our workflow that causes it. I attach tox of the lidar part. Hope you can find something without lidar connected.
it’s hard to see what’s going on with only static data and only a small part of your full network.
But your sentence “We need to have the window with osc in open all the time” points to a similar cooking issue as what you posted above. So as a quick&dirty test - you can try setting null1 CHOP cooktype to always.
I often find myself reaching for a base comp to encapsulate/group some functionality, but I find the cooking optimisations (which is required in large networks) means it executes unreliably.
I use base comps for input→output without side effects, IE pure functionality. Because if the output isn’t requesting a cook, then changes to the input won’t trigger any side effects as the base is unlikely to cook.
Maybe the Base Comp should have an “Always Cook” option? So it doesn’t get optimised if touchdesigner thinks it shouldn’t be active
just to mention, encapsulating in a Component does not change cooking behavior for the network. If nothing requests the data that is being processed in a branch (meaning you are also not looking at it by having the network editor open and/or viewers active) the branch will not cook.
There are outliers to this rule, for example operators dealing with cache will always cook unless their Active parameter is toggled off.
While not recommended, you can force branches to always cook by adding in an operator that does essentially nothing but is forced to cook via an expression. A Transform TOP for example could have an expression like 0*me.time.frame in the Rotate parameter. With CHOPs you can make use of the Null CHOP’s Cooktype parameter setting it to “Always”.
I would see this as a last resort when all other attempts have failed to make my project behave the way I want it to.
It runs in touchdesigner instead of touchplayer, because we were unable to figure this out.