advancing animation in fixed time-steps & frame-rate independence

Started by
24 comments, last by Promit 15 years, 7 months ago
hi, if you use fixed time steps in your game, whether with your own physics library or Intel Havok, nVidia PhysX, Bullet, ODE... you are most likely using this algorithm that deals with the maximum number of iterations in the following way: //-------------------------- *** ORIGINAL algo - capping the NUMBER

cnt= 0;
time= 10;

maxSteps= 5;

while(time > 0 && cnt < maxSteps)
{
  step(); cnt++;
  time--;
}

//--------------------------
Iterations, cnt= 5
"Time left", time= 5

most might recognize that the inner part of your 'stepSimulation' function resembles this algorithm, best described here: "Fix Your Timestep!" now, the problem with its practical implementation is in that you have to guess the NUMBER, and it manifests in two ways under certain circumstances: 1.) guess was too low for target CPU - "moon gravity effect" 2.) no matter how high - on some target 'slow enough CPU' it will "spiral to death" which is not a "real problem", because you can sort it out in design-time, but the peculiar thing is that it also seem to try to deal with the reminder of the time after the iterations have finished, with -interpolation- , which i think only introduces the errors and its not really necessary? //----------------------------------------------------------------------------------------- i propose two solutions, this practically solves both problems and removes any errors possibly introduced by "interpolation": //-------------------------- *** 1st algo - scaling the TIME "inside"

cnt= 0;
time= 10;

scaleFactor= 1;

while(time > 0)
{
  step(); cnt++;
  time--; time-= scaleFactor;
}

//--------------------------
Iterations, cnt= 5
"Time left", time= 0

//-------------------------- *** 2st algo - capping the TIME "outside"

cnt= 0;
time= 10;

if(time > 5) time= 5;

while(time > 0)
{
  step(); cnt++;
  time--;
}

//--------------------------
Iterations, cnt= 5
"Time left", time= 0

there is "a paper" on this and there you can find practical implementation and copy/paste source code to REPLACE your existing algorithm, so this can be easily tested in 5-10 minutes, and the difference is very obvious: "sampleTest.html" in essence, these are the solutions related to these discussions: http://www.gamedev.net/community/forums/..452753 http://www.gamedev.net/community/forums/..393475 what do you think? does this approach solves some of your problems? thank you, gameBoX Linux //----------------------------------------------------------------------------------------- ApochPiQ,
Quote:For better or worse, people are powerfully impacted by presentation.
- absolutely, how to make TAGS in this forum? are there buttons for TAGS like in other forums on the internet?
Quote:There are many places to submit such papers; a little bit of research can find several candidates for you, or you are free to ask where to publish it in a forum such as this one
- i cant find anything, can someone give me a name or link or organization or some address? [Edited by - abaraba1 on September 19, 2008 7:26:17 AM]
Advertisement
Quote:- absolutely,
how to make TAGS in this forum? are there buttons for TAGS like in other forums on the internet?
You can create source boxes using [source][/source]. To quote text, use [quote][/quote].

You can also create clickable links by using the HTML 'href' tag.
thanks, its fixed.
(tho it took quite some time, basically whatever i write the next time i edit im confronted with something different, it breaks lines, inserts some symbols, preview is different to the final page, some stuff is automatically inserted in the final message like 'yahoo.com', which i didnt want ..but all that is not important so lets NOT talk about that, lets just talk about algorithms..)


i see you are the author of CML:
- "The CML (Configurable Math Library) is a free C++ math library for games and graphics." (http://cmldev.net/)


thats great!
you're perfect to make some comment on this algorithms because this is the very place where mathematics merge with graphics in the most literal way


- would you agree these algorithms address and solve the problem?
- whats your opinion on how it works in practice - visual appearance?


thank you



//-----------------------------------------------------------------------------------------
Quote:There are many places to submit such papers; a little bit of research can find several candidates for you, or you are free to ask where to publish it in a forum such as this one

- i cant find anything,
can someone give me a name or link or organization or some address?


[Edited by - abaraba1 on September 19, 2008 5:47:24 AM]
Quote:Original post by abaraba1
thanks, its fixed.

i see you are the author of CML:
Co-author, actually (I worked with one other programmer on the project). But thanks for noticing :)
Quote:thats great!
you're perfect to make some comment on this algorithms because this is the very place where mathematics merge with graphics in the most literal way
Unfortunately, physics (at this level at least) is not my area of expertise. There are plenty of folks here who have a lot of experience in that field though, so I imagine that now that the presentation is cleaned up a bit, you're likely to get some feedback on your ideas.
>>"Unfortunately, physics (at this level at least) is not my area of expertise"

ok, fair enough,
but let me underline that this is not about Physics at all - it is about Graphics, its about Animation, its about FPS.. it is also about Mathematics since it is about an Algorithm ...its not about Physics

* its about the Algorithm that distributes those animation FRAMES per second, in a REAL-TIME



it is a little 'while loop' and only 3-5 lines of code, BUT
- this is the very essence of computer ANIMATION and the core 'function call' of any real-time simulation / game, right?


its not about the Physics,
it may be unfortunate circumstance that it ended up implemented in the Physics libraries, while it really belongs in the main program loop.



cheers




//-----------------------------------------------------------------------------
ApochPiQ,
Quote:
Similarly, code/source tags are important as well. They make it easy and convenient to copy/paste code and test it out. Although you are correct that it is still possible to do so without proper tagging, it's a pain.

>>"you can go on live your whole life thinking the earth is flat if you like, its not "important" information if you don't care about it, but if you use it in your line of work.. there was no point in arguing if you were not interested enough to pursue the matter for your own interests"

i find its actually easier to copy/paste without tagging

[Edited by - abaraba1 on September 20, 2008 2:53:05 PM]
Quote:There are many places to submit such papers; a little bit of research can find several candidates for you, or you are free to ask where to publish it in a forum such as this one


ok, i got some answers to this - thank you

SIGGRAPH:
http://www.siggraph.org/publications/instructions


but it doesnt seem to be very simple procedure,
- and would anyone go on to submit this without checking it out with general public first?
- i mean, i dont even know if this is some misunderstanding, i dont know if im right or wrong?
- simply, i cant be sure, and i can not go on claiming something if i cant confirm my results and my conclusions, right?



would anyone care to discuss this and actually confirm OR prove it wrong, im happy with either.


thank you
In reality, your time values will not be nice, neat integers - most usually they will be very small float values. In a system updating in sync with the vertical retrace at 60 fps, the time values will be around 0.016f but will fluctuate around that value quite significantly.

Both of your solutions above appear to me to lead to the same problem that interpolation is introduced in order to solve - once your physics updates go out of sync with the graphics update, the display will begin to stutter as you will be doing, say, three updates one frame, then one the next, then three the next etc.

I haven't tested your algorithms to be fair, but from looking at the code they seem to be pretty much equivalent to just ignoring the accumulator when rendering. Both algorithms do less physics steps within the timeframe than is actually correct.

Interpolation doesn't introduce errors if done correctly, it just displays your graphics 0 to 1 frame behind the simulation.
>>"Both of your solutions above appear.."

sorry, you lost me right there,
we cant discuss this if all you have to offer is your guesses and assumptions..


basically,
on all that what you said, im telling you - you're wrong
Quote:Original post by abaraba1
basically,
on all that what you said, im telling you - you're wrong


First algorithm consumes one time unit per call to step(). Remaining time units are propagated to next frame and interpolation used to "smooth out" visual results.

Both your algorithms consume 2 time units per call to step(). Therefore though 10 units have passed in actual time, only 5 time-units-worth of simulation has taken place.

Therefore in your example, simulation is running at half speed.

Also, regardless of whether you tell me I am wrong or not, there is now the capacity with more realistic values (in particular, different values for time each frame and a value for time that is not evenly divisible by the physics step) for the physics and rendering to fall out of sync so that you get, say, two steps one frame and one the next. This is what causes the visual stuttering that interpolation solves.

You keep referring to errors introduced by interpolation - what errors do you think interpolation introduces? I have two current projects that use the method outlined at gaffer.org and I can assure you that interpolation is not introducing any errors.

Since you are modifying Bullet code in your paper, may I suggest you post something about your discovery on the Bullet forums? Since the lead on that project worked on the Havok engine, I assume he has a fair idea what he is talking about.

[Edited by - EasilyConfused on September 22, 2008 7:07:10 AM]
Quote:Original post by abaraba1
>>"Both of your solutions above appear.."

sorry, you lost me right there,
we cant discuss this if all you have to offer is your guesses and assumptions..


basically,
on all that what you said, im telling you - you're wrong


It's a shame you're taking this attitude, as there are many experienced people on this site that could have given you constructive feedback on this issue. It's a well trodden path that anyone who has done any game physics has 'solved' many times before. Unfortunetly from your posts there seems little point in discussing this with you.

Also I noticed this on the page you linked to...

Quote:
(R) All rights reserved, dont you dare use this code unless you can prove to me you're human being. Use of this algorithm in commercial products without my permission will be cheerfully taken to court.


A few points about this. Firstly (R) is a registered trade mark sign. Do you have a registered trade mark? If so what is it? and what does that have to do with 'your' algorithm? Secondly, what ownership claims do you have for 'your' algorithm? You'd need a patent to prevent commercial use (in countries that allow software patents); do you have a patent for this?

Obviously those are retorical questions, as clearly you don't, but my point is that you are way out of your depth here, making wild claims about things you seem to know little about. I would suggest you take a different, less agressive approach if you really want to find solutions to the problems you have presented.

[Edited by - WillC on September 22, 2008 7:24:07 AM]

This topic is closed to new replies.

Advertisement