With 2023 release, engine Comp has been revamped, but I’m still waiting to see the new behavior and params to be clarified, as the wiki has got blank entries for some of them:
What exactly is “Done”, does it relate to internal time comp? If yes, how? What is “ready when”? etc…
There are also some duplicate entries.
Thank you!
Any news on this?
What are exactly “initialize”, “done”, “pre-roll”. What is “output_did_wait” in the info?
Most of these things are named pretty intuitively, but I’ve been having issues troubleshooting some things, which I believe might be because I misunderstand certain things. Please please update the wiki.
And does “onFrameEnd()” callback even happen inside an engine? It’s not triggering in my setup. I’m probably also misunderstanding how internal “timeline” works and how it relates to the “Clock”.
Hey @aulerius
Apologies for the delay.
This is logged for a developer to add documentation.
Best,
Michel
Hi @aulerius - sorry for the delay with the documentation. We’ll update it as soon as we can. In the meantime, the Initialize Start documentation covers some of your questions.
And does “onFrameEnd()” callback even happen inside an engine? It’s not triggering in my setup.
Have you enabled that callback in the Execute DAT’s parameters? If you have then if you can provide a .tox to demonstrate the problem, that would help.
I’m probably also misunderstanding how internal “timeline” works and how it relates to the “Clock”.
That part is currently documented.
Cheers
Thank you for these links! It already helps.
I’ll get back to you if I can reliably isolate the case with onFrameEnd().
Regarding the timeline and the clock, In my project there are a lot of emphasis on specific timeline frames, range start and end. The behavior of the engine comp was rather confusing to me during my testing so far. When the loaded .tox had a “independent” timeline inside, it appeared to not work? I think I can detect the “inner” timeline ticking as usual with default parameters (range end at 600 frames), but nothing custom would reliably function besides the frame rate.
…basically, the more explicit and detailed information you can provide in the documentation, the better! Specifically, about the differences on timeline and cook dependency behavior when compared to running that .tox normally as a comp.
It will be very appreciated!
Hi @aulerius - we’ve posted a considerable overhaul of the Engine COMP documentation. Let us know how you get on with it - and do ask any questions that remain after.
Thank you!
I think I almost got the hang of Init, Start, Done, and Play.
The missing gap is still the relation to a timeline as I mentioned previously.
To ask straight up: does me.time exist inside an engine COMP? Does it respect internal component timelines? Or is that not supported? Does “Done” relate to any sort of state with the timeline inside?
When the documentation says
Time is strictly synchronized between the Engine COMP and the TouchEngine instance
Does that imply that the exact Timeline frames are synchronized, or just the cooking? So far, my experimentation shows that the internal timeline syncs up frame-by-frame, but not by frame index (it always advances forward). This is using 0 buffer frames, using Touch Out/IN over UDP to probe into the Engine, and advancing the timeline manually with the - and + buttons.
Ah yes, its advance is synchronized, but not the frame number. Additionally it looks like we might be doing something odd when the Engine COMP’s time goes backwards - let me get back to you on that detail.
You can have internal component time in the component you load - ie the .tox file. You cannot achieve the same thing by adding component time to the Engine COMP itself - do it in the .tox file. The Engine COMP will honour local component time for the component it is in itself, which in turn will affect the component it is running (when the Clock parameter is set to Synchronized).
Just by the by, I’d just use In and Out CHOPs, no need for Touch In/Out.
Thanks! I will play with the local component again. Maybe I wasn’t using Synchronized clock, and that’s why I had misleading results on my prior testing.
I am using Touch In/Out because of a particular weird way my setup is built.
I have “Wait for Render” set to off, and the parent project frame finishes before the engine serves a frame. I use the signals over Touch OUT/IN to force one more cook on the engine comp to have the actual outputs updated once they’re done on the “inside”. Maybe this is clumsy, but it’s the only way I found a way to offload heavy processing while still keeping perfect frame-by-frame timeline sync and having the parent project and UI responsive.
Essentially my workflow is similar to unchecking the “realtime” checkbox, except I am keeping the main parent project UI still fully responsive and intractable, while the engine is executing long frames inside of itself.
In that situation the Engine COMP should cook again to update the output when the frame eventually finishes - are you not seeing that?
Not until the timeline advances to the next frame. I am staying on the same frame until I’m done with it, because all of my logic is linked to me.time.frame and counting exact frame indices.
On the same frame, I assumed this is working as intended, because the frame is “finished” and no operators “check” if they need to cook for the reason of advancing timeline.
Oh I see - in that case yes, probably working as intended.
If it were me I might leave the Engine COMP running normally and use its completing a frame to progress a separate clock for whatever relies on its output.
Sorry, one more thing!
When I .pulse() the reload par using Python, the engine does not seem to actually reload the tox, although onReady() callback does trigger for example.
Only clicking the reload par manually in the par UI actually makes it unload/load, which takes a moment (yellow warning appears).
Thanks for this deep scrutiny - it’s great to catch things. It turns out referencing the Engine COMP’s reload parameter from a script or expression always ended up referencing the initialize parameter instead. This is fixed in the next release.
Thanks for the report.
Great, cause I have more!
Reloading an engine COMP drops node output connections while loading, then reconnects them back when it has been loaded.
However, outgoing connections to operators with multi-inputs do not reconnect in this process.
Thanks - logged that to look into too. In the meantime, you could use Null OPs between the output and the input so they reconnect - not ideal but hopefully better than not reconnecting at all.
The reconnecting to multi-input OPs (such as Merge) is now fixed in builds 2023.11566 and later.
Cheers