Hello,
Thanks to the Engine Comp - I’ve reworked one of my programs (pulling TOP data to a bunch of mapped pixel chops) using it and seems to save some FPS. I added a perform CHOP into each .tox that I used to see how well each engine was performing - and was curious about a few things.
The program I exported to a .tox was set to a FPS of 30.0, and the program running the Engine is also set to 30.0 fps. However, the perform data exported from the Engine shows a cookrate of 60. Does anyone know where that value might be coming from? Ultimately I’m trying to balance workload across a number of engines (10) and am looking for that as a way to see how each one is doing. The FPS seems to do just fine while watching it, but some engines don’t need to cook at the same rate because data sets don’t update as quickly. Is it even possible to run engines at different rates?
Also, while playing with the Clock Synchronization setting, it seems to struggle with data when the clock is ‘Independent’. This doesn’t make or break anything but couldn’t find much detail on how a clock sync is set up in the Engine and was curious where the independent clock was running from?
The engine comp literally launches a new TouchEngine.exe, which seems to have defaults equivalent to a new TouchDesigner.exe launch.
I’ve used project.cookRate in a python script within an Engine comp to successfully change the target cook rate. The engine would have to be set to independent. I highly recommend using spout for textures and sharedmem for chops instead of the default in/out connectors, I have significantly better performance (so your data might be 0-2 frames off, but the processes have no dependencies on each other and can actually maximize their own performance).
I’ve noticed this issue as well. I can confirm what @pointshader said, project.cookRate inside of an Engine COMP seems to work. But as you can tell in the screenshot below, the ‘0 chan1’ and ‘30 fps’ Touch out from the Engine flickers heavily. Strange.
@dylanroscover The ‘flickering’ in the TouchDesigner UI is most likely the CHOP rapidly oscillating in between outputing 1,2, or 3 samples, and the UI changes from the blue bars on grey background to the red multi-sample on black readout. Using a TimeSlice chop, or my personal favorite, an extend chop set to Cycle into a trim set to absolute and frame -1 to grab the last single sample from however many samples are sent. I’ve done projects with data processing at 240 or 480 fps flowing to other instances running at 60 or 120, and CHOPs get really weird because they’ll jump between their single sample and multisample modes, which in some chops significantly alters behavior (like a filter chop). Errors that are extremely hard to debug even with the TouchDesigner UI, let alone buried inside of an EngineComp.
Thanks for the insight. I keep making adjustments and having to re-export the .tox anyway right now so in this case I might go back and just run another full instance of touch until I can find the best container candidate for an Engine and keep a close eye on how the sync affects the overall image.
@jslack You can always consider running the tox in a seperate TouchDesigner instance, which is how this sort of idea was typically done before the Engine Comp. Much easier to debug! The only big issue is sometimes having issues with GPU priority (if you have two gpu process based windows open, Windows seems to automatically give the one with mouse focus the priority for GPU - not an issue for workflows that are CPU heavy!)
Finally taking some time to dig a bit deeper into the Engine COMP.
I observed, maybe related slightly to your points, that when setting the engine comp to Synchronized clock my main process is dropping frames (slightly, but still).
Strangely running the content of the engine COMP in the same process doesn’t cause frames to drop.
Not sure I understand why… would all the back end logic related to syncing clock take much resources ? It’s odd.
Coming in the next release as a parameter on the Engine COMP.
The independent clock comes from the TouchEngine process. It is timed as if it were an independent TouchDesigner instance (in current builds fixed at 60 FPS, in future releases according to the FPS parameter on the Engine COMP). One peculiarity is that some outputs may cook at a lower rate if the process with the Engine COMP is running at a lower rate (we might change that behaviour, but want to avoid redundant cooks where we can). Can you elaborate on “it seems to struggle with data”? It would be useful to have a simple demo to chase down the problem.
