This question was created in reference to: [Lock to display rate at runtime usage in [Content removed]
Hi,
We’re seeing visible jitter caused by sub-frame interpolation, particularly when two actors are moving in sync. Due to interpolation artifacts, they don’t stay perfectly aligned.
As a workaround (instead of reauthoring the motion with stepped keys), we tested enabling “Lock to Display Rate” in Sequencer, which resolves the issue. However, we came across this thread from about two years ago suggesting that “Lock to Display Rate” might not be supported anymore. Can you confirm whether that is still the case since it’s still present in the Editor?
Additionally, the thread mentioned that “because it can cause the same frame to be evaluated multiple times, it can cause events to fire multiples times, when they should only be fired once”. Could you clarify under what circumstances a frame would be evaluated multiple times? While we haven’t observed this behavior in our general testing, we’d like to understand when it might happen, even if just using it in Editor playback, so we can be especially careful when validating our setup.
My understanding is that Lock to Display Rate temporarily limits the game’s render rate to match the Sequence’s configured Display Rate, so I wouldn’t expect extra frames to be processed that would result in duplicate evaluations.
I would say "“Lock to Display Rate” might not be supported anymore" isn’t entirely accurate anymore. It would be more than we’ve seen its uses across our different user groups, and we want to try and make sure it gets better support across Sequencer, but that is a lower priority in regards to some of our other work.
Additionally, the thread mentioned that “because it can cause the same frame to be evaluated multiple times, it can cause events to fire multiples times, when they should only be fired once”.
My understanding is that Lock to Display Rate temporarily limits the game’s render rate to match the Sequence’s configured Display Rate, so I wouldn’t expect extra frames to be processed that would result in duplicate evaluations.
Correct, if your game is running at 60 fps and your display rate is 30 fps, it will duplicate the frame until enough time has passed for the next frame to fire. But at a variable frame rate, this can look odd. Also this would be the source of where multiple events can fire.
Generally speaking, the primary issue is that it doesn’t support all the aspects of the sequencer that we would like, so that’s often why we wave people off of it.
Just to make sure I’m understanding the FPS portion correctly: looking at the code, it seems like when “Lock to Display Rate” is enabled, the sequence player effectively limits the game’s FPS to match the sequence’s Display Rate (using GEngine->SetMaxFPS()).
If that’s the case, wouldn’t the game also be running at a maximum of 30 FPS during playback ? In that scenario, I wouldn’t expect additional update frames to be available where the same sequence frame would need to be evaluated again.
Am I interpreting that correctly, or is there something in the timing behavior I might be overlooking?
You are interpreting the code correctly, but there is always nuance to things. In a standard engine configuration where you aren’t using a fixed-frame tick, yes, you shouldn’t run into that issue. But if you do run at a fixed frame tick, then setting the max fps like that is ignored.
Also, to point out, when evaluating at a fixed rate, like locking to the display rate does, when we set the evaluation method, we switch over to a platform clock source for the sequence, but not the game, so the intent is that they are evaluating on whole frames using both methods. It’s just not guaranteed.