Interpolation woes

[seece]

I'm not sure if I'm missing something here but Rocket's behaviour in between keys really bugs me. Let me present the problem visually:

I apologize for using Ground Control for the screenshot :)
I'd expect the first key to finish its interpolation and instantly change to interpolating the next key. But the curve seems to stay constant for a while which is very visible in some animations.

Is this the way it should work?

[kusma]

Yeah, this unfortunately is the way it should work, and it's not ideal. The reason is that the two keyframes are on different rows, and as such have different positions in time, so there will be a gap of one row there (your drawing shows half a row, but the gap is one row). The problem is with the model, it's not a bug; what you've specified is three segments, one with interpolation to next one, then one without. followed by another one with interpolation again. If you try moving the keys to have some spaces between them, you'll see that this (below) is what fundamentally happens:

The problem here is that the segment between 2 and 3 isn't zero-length, it's one row long.

There's been several ideas for how to fix this, but the problem is that they all require to change the network protocol, which breaks compatibility with other clients.

The seemingly simplest fix would be to allow the protocol to specify an incoming and an outgoing value for each key. This way, the same keyframe-location can be used for both values at the discontinuity. The bad part about this is that it doesn't directly lead to an easy editing model. Two values at the same location would need a more involved editor, with some switching between incoming/outgoing here, and displaying two values per row in a clean way. I suspect that this can be solved by diverging between the editor model and the player model, though.

However, this bring me to the next thing, and that is that if we want to break the protocol, I would like that we broke it a lot more at once; that is switch into sending arbitrary quadratic polynomial segments instead of the current list of row. value and mode per key. This will allow further editor features in the future without breaking the protocol again.

[seece]

Thanks for the explanation. My current workaround is just to make the tracker speed very fast, then the constant segments are much shorter.

[kusma]

@seece: Yeah, that's what I've been doing myself. It's kind of something you probably want to do anyway, because it allows for more precise sync-details (for demos where that matter). But it still sucks that it has to be worked around.

[eteeselink]

How about a button that marks a cell as "the value in this cell counts for the last frame of this row, not the first frame of this row"? I.e. just like you toggle interpolation mode with i, you could toggle value aligment with, say a and mark it visually somehow (i'd steal excel's "bottom align" icon).

This'll only get you in trouble if you want a single-row-long interpolation between two values, which is pretty uncommon and kusma's workaround works fine for that.

[kusma]

@eteeselink: Yeah, that could be an option. It'd still need a protocol extension to communicate this with the player, though.

[eteeselink]

Ah too bad. Somehow I had always assumed the protocol was per-frame but now that I think about that I realize how stupid it is :-) (i haven't touched this codebase for a decade or so) (fuck we're old)

[kusma]

So, this isn't really a bug per the current definition, even if it's annoying. I'll close this for now, but keep the problem in mind for the future.