Keep changes on Keyframe causes easing
Turning on keep changes causes a single keyframe to have an ease in/out response.
Grab a slider, signal manipulator, timer, and keyframe.
Keyframe the slider to 1.
Plug the timer output into the keyframe power.
Plug the slider into the signal manipulator.
Switch the manipulator to remapper mode so you can see the graph.
With keep changes off, you'll see the expected linear transition.
With keep changes on, you see a slight ease in, and a more dramatic ease out. The value also nearly reaches 1 only half way through the timer output.
@raz0rbackzwei We did get an answer from John Beech on Twitter.
@TAPgiles, well you were right about the exponential growth. As John stated, the slow down at the end is due to Dreams attempting (poorly imo) to add in additional interpolation to balance out the effect.
That said, I still don't see a reason why this couldn't be implemented in a way that does not have this side effect.
Seems to me it'd only be a matter of updating the current value to be equal to the new value, as long as the new value is not less than the previous frame's value. As I said before, I could implement exactly this in Dreams logic, so certainly it can be done in pure code.
I can write out how I think it's working frame by frame with a detailed example if you like. Just takes a lot of work 😅
When it starts it shoots straight up in that video you posted, right? That's where I got exponential from. In reality it's not compounding, and it's not exponential. I just don't know what the mathmatical term is XD
If only Mm had the answer...
Hopefully when VR is out this forum gets some love again. Seems pointless to debate here xD
Amigo, it doesn't get exponentially faster as you state in your video. Look at the graph. It speeds up and then gets slower. That completely debunks your theory that it's compounding over time. It literally does the opposite.
Keep changes does not cause "easing." The result may be similar, but it's quite different to ease-in-out I think.
It's not intended to "freeze stuff where this keyframe tells it to." As I explained in my tutorial, it's more accurate to say... when a keyframe becomes unpowered it will put the object back to the state it was before the keyframe was powered. If keep changes it turned on, it won't put the object back after it becomes unpowered. It doesn't lock it in or guarantee anything.
It's a subtle distinction but understanding why it works this way is all about the subtleties.
It helps to think about what is happening *per frame*. The keyframe is affecting the position *each frame* so it is keeping-changes *each frame*. This produces weirdness as discussed, but it makes perfect sense from a logic engine standpoint of how the code actually works.
It could perhaps be changed to work differently to avoid the side effects, that's fine by me. But there are currently very easy workarounds which completely remove the issue. So while I was definitely in the camp of "this is a bug and doesn't make any sense and should be fixed!" now I'm more like "oh yeah, I do this little tweak and now that works just fine."
I feel the same about this as cgCody.
Happened to me as well and comes with strange side effects during animations. Not only the easing. I feel like it messes with the stored values, too
That makes no sense. The sole job of the option is to freeze the value at whatever it was last at. One could create simple logic that serves that function, so I fail to see how coding it as such would be a case of "Well it's just impossible to do it any other way, so just deal with the *unintended* side effect.'
Also, if you look at the remapper graph, you'll see that the signal speeds up then slows down. It doesn't just get faster and faster. 🙂
All that is to say, even IF it was coded this way purposely as one way to get the job done, it's still a bug. It's still doing something that is not the intended purpose of the feature. As someone that does a lot of animation stuff, it's a pretty BIG unintended side effect. Took me since EA to realize this was causing weird timing issues on much of my stuff. If that's not a bug, then the description should be renamed to keep changes+ease in/out.
This is just how keep changes works. They could change it to somehow detect something like this, but it actually makes a lot of sense when thinking about how it must actually work under the hood.
Basically, each logic frame it takes the state from whatever it happens to be, to (power percentage) towards the recorded state. Then it leaves it there because it's got "keep changes" on. Next frame it does the same--but from that changed position. So it compounds over time.
I explain this in a tutorial: https://youtu.be/8GLzkNHVpmQ?t=118