Animation update logic?

[dakom]

This isn't really sodium or frp specific at all.. but it touches on the same themes (continuous vs. discrete time) so I figured I'd ask here.

Basically - I'm in the beginning stages of trying to figure out how to do proper gaming on the web, using pong as a proof of concept, writing the game loop logic from scratch.

On one foot - what I have so far is to have a worker update the game state, and then render it within requestAnimationFrame() somehow.

Where I'm stuck is how to deal with the gap between worker updates and screen ticks. You can see a graphic and my (as of yet unanswered) question on gamedev here: https://gamedev.stackexchange.com/questions/148263/accounting-for-drift-between-ticks

I'm basically having trouble wrapping my brain around it... what I'm thinking is just to keep updating the world as much as possible in a continuous loop and then the rendering will simply render whatever newest state it has on each tick. It's not perfect, but I just can't think of a way to sync it to ticks perfectly... keep coming back to needing to predict the future amount of gap before the next frame :\

Fwiw on the input side of things I am using Sodium, so that input state is consolidated from different sources and synced with state updates

[clinuxrulz]

Not a complete answer, but just a thought.

Look up integrals. Learn what they are. Solve the integral equation for the physics your doing, then simply have once Cell<Time> cTime and go Cell<Position> cPos = cTime.map(posEquation). That will give you a error free position over time (disregarding float point error).

Next you need to predict time of impact which will trigger an event to update your parameters of your equation. So you then will need something like a Cell<Lambda1<Time,Position>> cPosEquation instead of posEquation, So => Cell<Position> cPos = cTime.apply(cPosEquation).

When you are doing the last step at time of inpact, you need to pass your time of impact time to your "last" posEquation for your initial positioning config for your next posEquation.

I'm a little unsure of my answer, because I've never tried it before.

[clinuxrulz]

Some math to derive an example position over time equation. My integral math is a little rusty, been ages since I've done this stuff.

v = integral(a) + v0
v = a * t + c0 + v0
when t = 0, v = v0
v0 = c0 + v0
c0 = 0
v = a * t + v0
p = integral(v) + p0
p = 0.5 * a * t * t + v0 * t + c1 + p0
when t = 0, p = p0
p0 = c1 + p0
c1 = 0
p = 0.5 * a * t * t + v0 * t + p0

That last line is an example of position of an object over time under the influence of gravity alone.
- p is the position.
- a is the acceleration (gravity), which is a fixed constant in this example, otherwise you would have a different p answer entirely.
- t is the time.
- v0 is your initial velocity.
- p0 is your initial position.

If p, a, v0 and p0 are scalars, then its a 1-dimensional motion. If you use 2d vectors for those, then its a 2-dimensional motion. If you use 3d vectors for those, then its 3-dimensional motion. (You can use the same formula regardless of dimension).

Edit: I followed your links and saw: https://gafferongames.com/post/fix_your_timestep/ . So I think I do not have the answer your after. I would have to learn more to give you a better answer.

Also exact integrals get very difficult as more elements get added to your physics engine, such as drag and friction. So I think most of them focus on numerical approximations, and for efficiency they use incremental computation of that numerical approximation. So its best to visualize your position function as a incremental computation of a numerical approximation of some integral equations. Since your frame time will most likely always land between two time steps of the numerical approximation, you need to do linear interpolation (or cubic/others for more advance) of the postion between those time frames to obtain a smooth animation on the screen. And that seems to be what that link to the article is all about.

For an idea of what a incremental function of position might look like:
fn incrementalPos(state: PosState, time: Time) -> (PosState, Pos)

The incremental calc keeps enough state via PosState to allow incrementally numerical updates to the internal integrals. Structured that way you can play catch-up numerical integration and interpolation in one, to provide a smooth animation and to insure the motion of the object is frame-rate independent. (Your object will have the same trajectory regardless of frame rate.) You can then feed this in your update loop powered by something like sDeltaTime with accum attached to keep state.

[dakom]

Thanks @clinuxrulz - this is all very helpful! I recently bought a book on 3D math... and it's a bit overwhelming but I'm absorbing a bit here and there. I see upcoming chapters deal with Quaternions and Integrals so when I get there, I'll try to pay a bit more attention

If I understand correctly - your answers are solely on the worker/physics-update side of things. Right now on that side I'm simply just updating position via multiplying it by deltaTime and some speed - but no doubt everything you wrote above will become vitally more important if I want to have something a bit more organic.

My question was a bit different, more about how to deal with the gap that happens between the physics being updated and the screen being repainted. Yes it will be accounted for on the next physics update, but visually there's still a little gap and it's never going to be consistent.

It seems that the consensus is that this is simply the state of the art. There's no way around it, but this gap is by definition less than refresh rate of a screen and it's not noticeable for the most part (plus as screen rates get faster, it's less of an issue)

Thanks for your in-depth response!

[clinuxrulz]

I wonder. If we know how long it takes to update the physics and render to the screen from prior frames, then we could get the physics to step that amount of time in advance. So the end of the frame is in sync with the physics. However user input will still lag by that same time in advance.

[dakom]

I hadn't considered the implications on input, but I did think about fast-forwarding in that case, just in a sort-of back-of-the-napkin kindof way. I gave up simply because it didn't feel right to assume that the next update will be anything like the last.

No doubt though that this sort of optimization is possible in many cases, it's an interesting idea

[Ziriax]

To understand quaternions better, I suggest you take a look at geometric algebra, see for example this video, this book, or Google around for better books/resources.

Basically, in 2D (resp 3D) a rotation by a quaterion is actually just a double reflection about two 2D lines (resp 3D planes), the rotation will be the double of the angle between the two lines (resp planes). You can easily get a feeling of that by drawing it on the piece of paper.

Furthermore, the lines (resp planes) can be rotated without changing the effect of the rotation. So if you have 4 lines (planes) for doing 2 consecutive rotations, you can always rotate the first pair so that the second line of the first pair coincides with the first line of the second pair (or vice versa = associativity). Now a reflection about two coincident lines (planes) is an identity operation, meaning that any sequence of rotations can be collapsed to a single rotation (in matrix terms, the product of matrices is a single matrix).

Likewise, a translation is a double reflection about two parallel lines (planes), the distance will be the double of the distance between the two 2D lines (3D planes). This is known as dual-quaternions. Again you can move the two lines without changing the translation, collapsing any sequence of translations into a single translation.

You can now combine these two, coming to the geometrical conclusion that any sequence of translations and rotations can collapse into a single translation and rotation, just by rotating and translating the line (plane) pairs.

A friend of mine has been working on ganja.js, a nice Javascript library for doing this an a lot more.

But be warned, geometric algebra is still considered "alternative math", not well accepted by the mainstream community, just as reactive programming was when I discovered it... It is very addictive, because it merges so many different mathematical areas into a single beautiful framework. Actually, by just starting with a linear space and adding a single property (that a geometric product * exists for which v * v is a real number), the full and rich geometric algebra follows.

[dakom]

Thanks, I'll need to come back to this when I get my hands a little dirtier

[clinuxrulz]

I really enjoy reading the 3 posts starting here: https://slehar.wordpress.com/2014/03/18/clifford-algebra-a-visual-introduction/

I've always used Quaternion, memorized the formulas. But never knew how they worked. Until now! Thank you very much.

[dakom]

Someone shared this with me recently... a bit more my speed and I love the way he teaches. It's a playlist, not just the one video, but I can't seem to get the forum to embed it as a link: