I have a problem with timelines; they seem to perform differently in different play modes, and also (more worryingly) in the same play mode over multiple iterations.
When moving actors around using timelines along with the AddActorLocalOffset node, I noticed that they didn’t always move the actor the same amount over succesive iterations.
The problem is vastly magnified depending on which windows I have open and which type of Play I am using. For instance, if I have the ouput log open (on an second monitor) while playing in fullscreen the actor moves a slightly different amount each time. It also behaves differently (with or without the output log open) using either Play in the ‘windowed’ selected viewport, PIE, or Standalone game.
The most consistant seems to be when playing in the Selected Viewport in fullscreen, but even then, there are occasions where it gets it ‘wrong’.
Here’s a link to a video demonstrating this problem. Sometimes the problem is quite subtle and requires looking closely, sometimes it is glaringly obvious:
Steps to duplicate:
Using the first person template, move a cube (with all collision disabled) to directly in front of the player so you don’t have to move etc.
In the level blueprint, add a SetActorLocation node to the location you placed the cube, and an input action to trigger it.
Create a 1 second timeline with a single float track and two keyframes; 0 at 0 seconds, -10 at 1 second.
Connect the timeline to the SetActorLocation node via the PlayFromStart pin.
Connect a AddLocalOffset node to the Update of the timeline, and the float track of the timeline to the Delta Location Z of the AddLocalOffset node.
Add a second block in the level and place it beside the location the first block falls to (for comparison)
Run multiple times in various Play modes. Notice that the block will not always move to the same location.
Even in Fullscreen it will get it wrong every so often
In desperation I tried adding the Delta to the offset, but that didn’t make any difference (as far as I understand, Timelines shouldn’t need Delta since they are (effectively) absolute time)
Please laugh at me and correct me if I am doing something wrong, but I have rewritten my animation system 3 times now before it finally dawning on me that there might be something fundamentally wrong with timelines…
Hi!
My point is, that timelines do not appear to behave consistantly as (I was under the impression that) they are intended to. i.e. if they are intended to behave in a framerate-independent manner, then surely I should be able to drive movement from it?
For example; I (not in the example i gave) use a timeline to simulate a gravity curve, I would expect it to behave the same each time, regardless of which Play mode i am using and/or how many iterations of it I have used. (As to why I would be using a gravity curve like this rather than using physics, it is a looong story!)
Actually, the gravity example I gave above is a poor one; the motion I am actually using timelines for a far more complex. However, even the simple usage as explained in my original post doesn’t work as expected, which is why I posted it to illustrate.
It’s correct that the variation of your output pin “New Track 0” ist constant over time.
But possibly this doesn’t guarantee that the “Update” is triggered each or at constant intervals.
a) the “AddLocalOffset” may be called sometimes more and sometimes less often, until the timeline has finished, or…
b) the “AddLocalOffset” may be called e.g. each frame, but there’s some jitter, means it sometimes gets triggerd a millisecond sooner, and sometimes a few ms later, providing slightly different values.
However, since it’s a summation of relative offsets, this may cause differences in the number of summands or in the value of the summands, and so a higher or lower sum (-> distance).
I assume that the different play modes create different system loads, or the behaviour it isn’t predictable at all.
This is not about predictability of the timeline. The way it works is that it calculates, based purely on the delta time from the current frame versus the previous, where in the timeline curve you are and outputs that value accordingly. So you should never use the raw output to change the position of anything, as you cannot predict or control the frame rate.
For example, if your timeline is a simple line set as 1 for every output, and your frame rate is 30 the offsite will be 60 per second if you are running at 60 frames per second, or 30 if you are running at 30 frames per second. Using it that way is just wrong.
Instead, set the timeline as the position that your actor should be, and set the actor to that position each frame instead of adding a delta. That will ensure that by the time X in your timeline, your actor will be precisely in position Y. That makes sense?
After your suggestion I replaced the AddLocalOffset with a SetActorLocation (using the ForwardVector) and this looks to behave consistantly; therefore the problem lies not with the Timeline, but the AddLocalOffset node.
Incidentally, I added logging to the test project to see which of your two suggestions was the most likely culprit, and (rather terrifyingly) it seems both are happening.
The timeline was calling the offset somewhere between 117 and 122 times per iteration running in a windowed Selected Viewport, consistantly 121 in a fullscreen Selected Viewport, but only (and consistantly) 63 times in Standalone.
This to me proves your second sentence, and suggestion (a) is correct.
But also, even when succesive iterations have the same ‘call count’ the cube still falls different amounts; this can only point to your second suggestion (b) also being true.
I guess my takeaway from all this is that timelines ARE framerate-independant over time, but one cannot rely on the value being predictable at any given frame.
Also, that AddLocalOffset is not that great when called every frame!
Thanks very much. I had actually come to the same conclusion myself in my last comment (and with much help from Rolffson’s advice), but it is good to have someone confirm this (and explain it far better than I did!)
Even better, I can now confidently return to my project, knowing that the inconsistant behaviour is well and truly behind me!
Thank you very much to everybody who commented and helped!