fixed time step

fixed time step

Post by Milan Stezk » Thu, 03 Jul 2003 00:01:10



Hi,
I have half of this method working (according to
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSt...
um=totd&id=-1) - this means, that the physics in my engine are not dependent
on the speed at which the frames are rendered and they work the same on all
computers. I have bumped into a problem when the frames are rendered fast
enough so that they are the same, because the was no update to the physics.
So it is obsolete to render them when they are the same. It is enough then
to render at the speed of the physics update. People in that flipcode forum
solved it with the interpolation, so in the period between two physics
updates they were rendering the scene with interpolated matrices. Thanks to
this, the movement was smoother on faster machines. I dont really know how
to do this. To what position/rotation should I be interpolating ? I still
dont know where the object will end up. Or do they just guess what will be
the final position/rotation and they use the last velocity vector and
rotation matrix ? Maybe I still dont understand this topic thoroughly but I
dont want to use the variable time step and fill my code with *deltatime.
 
 
 

fixed time step

Post by Gordan Siki » Thu, 03 Jul 2003 02:06:29


Hi,


> Hi,
> I have half of this method working (according to
> http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSt...
> um=totd&id=-1) - this means, that the physics in my engine are not dependent
> on the speed at which the frames are rendered and they work the same on all
> computers. I have bumped into a problem when the frames are rendered fast
> enough so that they are the same, because the was no update to the physics.
> So it is obsolete to render them when they are the same. It is enough then
> to render at the speed of the physics update. People in that flipcode forum
> solved it with the interpolation, so in the period between two physics
> updates they were rendering the scene with interpolated matrices. Thanks to
> this, the movement was smoother on faster machines. I dont really know how
> to do this. To what position/rotation should I be interpolating ? I still
> dont know where the object will end up. Or do they just guess what will be
> the final position/rotation and they use the last velocity vector and
> rotation matrix ? Maybe I still dont understand this topic thoroughly but I
> dont want to use the variable time step and fill my code with *deltatime.

(very breafly)

Formula for linear interpolation is as follows:

y = (y1-y0)/(t1-t0)*(t-t0) + y0

where t, is moment when you are looking for a value, y is calculated
value, and (t1,y1), (t0,y0) are last two known points. In your case, you
would use projections of position, and angles instead of y, or anything
you need.

Be aware that if you are using interpolation this way, you are
introducing "pure delay" into the system; you are drawing values of time
stamp t0+t, and the current time stamp is t1+t (one step lag). The
player is using output (scene on the monitor) as a feedback, and longer
the pure delay greater the possibility that controller (i.e. player:)
will become unstable.

Workaround might be to extend t beyond t1, and in this case you have
extrapolation, i.e. you are extrepolating values based on last 2 known
points. This way you are minimizing "pure delay", but extrapolation is
allways more "dangerous" than interpolation, meaning that computed
values might depart from correct values, resulting in some kind of
saw-tooth effect.

You might also implement some higher order interpolation (or
extrapolation), but in any case you should be very sure what are you doing.

ciao,

Gordan

 
 
 

fixed time step

Post by Hans-Bernhard Broeke » Thu, 03 Jul 2003 02:33:14



> So it is obsolete to render them when they are the same. It is enough then
> to render at the speed of the physics update. People in that flipcode forum
> solved it with the interpolation, so in the period between two physics
> updates they were rendering the scene with interpolated matrices.

A simpler way to think of this might be: if your real physics
simulation engine isn't fast enough to keep up with the graphics frame
rate, you can still use a special simplified one to quickly generate
intermediate frames.  Essentially, you'ld set all forces to zero for
the intermediate step, so all objects just fly freely along their
paths.

Or you could just decrease the timestep of your physics simulation so
it's certain to never be slower than any sensible framerate (100Hz,
say).  Some 3D graphics hardware allows framerates to go higher than
the display refresh rate itself, but that's quite a silly option
except for the purpose of benchmarking the 3D hardware itself.
--

Even if all the snow were burnt, ashes would remain.

 
 
 

fixed time step

Post by Mark Piff » Thu, 03 Jul 2003 07:14:33


On 1 Jul 2003 17:33:14 GMT, Hans-Bernhard Broeker



>> So it is obsolete to render them when they are the same. It is enough then
>> to render at the speed of the physics update. People in that flipcode forum
>> solved it with the interpolation, so in the period between two physics
>> updates they were rendering the scene with interpolated matrices.

>A simpler way to think of this might be: if your real physics
>simulation engine isn't fast enough to keep up with the graphics frame
>rate, you can still use a special simplified one to quickly generate
>intermediate frames.  Essentially, you'ld set all forces to zero for
>the intermediate step, so all objects just fly freely along their
>paths.

Still no one yet has satisfyingly answered my question from the other
thread: what to do with interactions (collisions) that happen between
fast moving objects and which would go by unnoticed, if the scene were
only statically investigated at t0 and t1? How are those games doing
that, which feature moving targets and very fast moving bullets?

Mark
--
Mark Piffer
MCU and DSP programming & software design

 
 
 

fixed time step

Post by Christer Ericso » Thu, 03 Jul 2003 13:43:21



says...

Quote:> [...]
> Still no one yet has satisfyingly answered my question from the other
> thread: what to do with interactions (collisions) that happen between
> fast moving objects and which would go by unnoticed, if the scene were
> only statically investigated at t0 and t1? How are those games doing
> that, which feature moving targets and very fast moving bullets?

In games, we typically model very fast bullets as rays, or fast-but-
not-quite-that-fast bullets as line segments from the current
to the next position. Thus bullets are never "only statically
investigated at t0 and t1" and can never pass unnoticed through
objects.

Christer Ericson
Sony Computer Entertainment, Santa Monica

 
 
 

fixed time step

Post by Hans-Bernhard Broeke » Thu, 03 Jul 2003 18:33:32



> On 1 Jul 2003 17:33:14 GMT, Hans-Bernhard Broeker

> Still no one yet has satisfyingly answered my question from the other
> thread:

... and so you decided to intrude on this one, or what?

Quote:> what to do with interactions (collisions) that happen between
> fast moving objects and which would go by unnoticed, if the scene were
> only statically investigated at t0 and t1?

Under the premises of this thread, that's a non-issue.  The goal here
was to make the behaviour of the physics simulation independent of the
graphics frame rate, by decoupling the physics update from the
graphics redraw process.

Quote:> How are those games doing that, which feature moving targets and
> very fast moving bullets?

By not trying to do collision detection in terms of fixed timesteps,
or living with the artefacts.

E.g. there were car-racing games back then, on the C64, where you
could drive right through a solid object to cut a corner of the race
track --- if only you did it fast enough so the collision detection
code didn't notice.
--

Even if all the snow were burnt, ashes would remain.

 
 
 

fixed time step

Post by Milan Stezk » Fri, 04 Jul 2003 23:51:30


Thanks everybody for the help. Now I've got it complete.
I had also these two possible solutions on my mind (with delay -
interpolation or prediction - extrapolation). I just did not know if there
is another one which is more elegant. I decided for the solution with
interpolation. I render between t-1 and t , so there is a short lag which is
exactly the time between the physics updates long. I update the physics
every 50 ms and this lag is not noticable to me anyhow and I can always make
it even shorter by decreasing the delay between my physics updates.
I have to store previous orientation and position of every object in the
scene. I interpolate using quaternions. I have my own functions to operate
with vertices and matrices. Physics updates are done with my functions so I
have full control of the meshes but the interpolations are done with the
OpenGL matrix manipulation functions (except the quaternion conversion) ,
because I dont need any exact vertex position info during the render phase.
I hope I get some hardware transform acceleration (only on hw T&L cards
ofcourse) if I use the OpenGL functions for transformations like
glTransform, glRotate,glMultMatrix ?



> Hi,


> > Hi,
> > I have half of this method working (according to

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSt...
Quote:> > um=totd&id=-1) - this means, that the physics in my engine are not
dependent
> > on the speed at which the frames are rendered and they work the same on
all
> > computers. I have bumped into a problem when the frames are rendered
fast
> > enough so that they are the same, because the was no update to the
physics.
> > So it is obsolete to render them when they are the same. It is enough
then
> > to render at the speed of the physics update. People in that flipcode
forum
> > solved it with the interpolation, so in the period between two physics
> > updates they were rendering the scene with interpolated matrices. Thanks
to
> > this, the movement was smoother on faster machines. I dont really know
how
> > to do this. To what position/rotation should I be interpolating ? I
still
> > dont know where the object will end up. Or do they just guess what will
be
> > the final position/rotation and they use the last velocity vector and
> > rotation matrix ? Maybe I still dont understand this topic thoroughly
but I
> > dont want to use the variable time step and fill my code with
*deltatime.

> (very breafly)

> Formula for linear interpolation is as follows:

> y = (y1-y0)/(t1-t0)*(t-t0) + y0

> where t, is moment when you are looking for a value, y is calculated
> value, and (t1,y1), (t0,y0) are last two known points. In your case, you
> would use projections of position, and angles instead of y, or anything
> you need.

> Be aware that if you are using interpolation this way, you are
> introducing "pure delay" into the system; you are drawing values of time
> stamp t0+t, and the current time stamp is t1+t (one step lag). The
> player is using output (scene on the monitor) as a feedback, and longer
> the pure delay greater the possibility that controller (i.e. player:)
> will become unstable.

> Workaround might be to extend t beyond t1, and in this case you have
> extrapolation, i.e. you are extrepolating values based on last 2 known
> points. This way you are minimizing "pure delay", but extrapolation is
> allways more "dangerous" than interpolation, meaning that computed
> values might depart from correct values, resulting in some kind of
> saw-tooth effect.

> You might also implement some higher order interpolation (or
> extrapolation), but in any case you should be very sure what are you
doing.

> ciao,

> Gordan

 
 
 

1. A Fixed Step Blend

In Corel Draw 10 when one chooses Blend from the Effects menu pull down, one
gets a dockable blend menu with four icons one can click on.  The first icon
is for "blend Step."  On this blend step page is a button for Fixed Spacing.
For me this button is always greyed out.  What do I do to activate this
button?

Thanks,
Jim

2. Plugins supplied with 3.0.5 are 16 Bit not 32 Bit????

3. MEL command for frame step in time slider

4. Software Advice

5. Free 2D/3D step by step tutorials!

6. MAC Freeze ups with Adobe Premiere

7. Cartooning - Step by Step

8. Step by step

9. Airbrush Step by Step Video

10. Airbrush Skizzen Technik - Step by Step