New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpolation woes #63

Closed
seece opened this Issue May 7, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@seece
Copy link

seece commented May 7, 2017

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:

Annoying interpolation

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

This comment has been minimized.

Copy link
Member

kusma commented May 8, 2017

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:

image

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

This comment has been minimized.

Copy link
Author

seece commented May 8, 2017

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

@kusma

This comment has been minimized.

Copy link
Member

kusma commented May 8, 2017

@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

This comment has been minimized.

Copy link
Contributor

eteeselink commented Jun 11, 2017

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

This comment has been minimized.

Copy link
Member

kusma commented Jun 12, 2017

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

@eteeselink

This comment has been minimized.

Copy link
Contributor

eteeselink commented Jun 12, 2017

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

This comment has been minimized.

Copy link
Member

kusma commented Feb 16, 2018

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.

@kusma kusma closed this Feb 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment