I was planning to add condition support for UMovieSceneSpawnTrack so I can disable some of the tracks on some platforms but I noticed that bSupportsConditions was recently disabled for UMovieSceneSpawnTrack and UMovieSceneBindingLifetimeTrack because of ordering issue. Could not find more information about this issue. I already implement also cook time condition checking for platform condition. But perf gain when comparing to runtime UMovieScenePlatformCondition check is not great. I was wondering if I can get more information about issue mentioned in CL that disabled condition support for UMovieSceneSpawnTrack. How safe is to reenable condition support for UMovieSceneSpawnTrack? Is there any plan to fix underlying issue?
Not sure if its right place to ask this question but I was writing about this CL36466408. I cannot find any information mentioned in the CL. Any information would be welcome.
Apologies for the delay in getting back to you. We disabled conditionals on the spawn tracks because of where spawning and binding occur. Right now, conditions determine whether a track is imported into the ECS evaluation. Now, this might feel like a good idea because ultimately, if the goal is that you don’t want the object to spawn for a certain condition, you might get the behaviour you want. The issue, though, is that for the general case, conditions may flip during a tick, and you may want to have it be spawned or despawned, and it may just be an invalid binding at that point. So it was safer to disable that behaviour.
How safe is to reenable condition support for UMovieSceneSpawnTrack?
This really depends on how it’s used. Like I mentioned above, you would need to evaluate the conditional once, guarentee that all downstream connections aren’t relying on it, (like an attach track on another object).
Is there any plan to fix underlying issue?
Currently, no; this would require a complete rearchitecture of where and how conditionals are applied to guarantee that objects spawn and handle any other dependencies appropriately.
Thank you for response. One more question if you don’t mind. I was wondering if deactivation of the track in editor can lead to similar issue with downstream connections?
No, because the result is slightly different. Deactivated tracks are removed at compile time for the sequencer, meaning that, to the runtime, they don’t exist at all. Later, when linking occurs in the ECS, there is a difference between not knowing about a track representation at all and the object possibly being present or not.