[ODE] interpolating between physics frames to get the actual positions in the render time

[John DeWeese]

How fast are you rendering? I think under many circumstances you will in 
fact see jitter, and you can minimize this by choosing update 
frequencies that divide somewhat cleanly into each other (i.e. small 
denominator). If you're already way faster than the refresh, you can do 
fast-as-possible updates so as to reduce the average residual latencies 
between visual and physics frames (that's probably what ends up 
happening in your case, Mr. GeForce 9 Quantum 60000), but then you add 
the problem of not exactly syncing your render frames with the vsync 
(too fast), so it's best to throttle down to 60fps or a nearby clean 
division. Most of us are spoiled and just spit those frames out like 
Moore's law doesn't matter any more, as in the quake 3 timedemo 
benchmarks up there in the 300fps range. The best fit for update 
frequencies will still be integer multiples, so that every graphics 
frame would be synced to a physics frame. If you're running an adaptive 
step size, you can only concentrate on reduce the residual latencies by 
carefully choosing the step size to fit with the next render, or 
something like this.

For example, running full screen 60Hz with vsync enabled, double 
buffered, frame rate at 60fps. With physics at 100Hz, that means that 
physics updates 5 times for every 3 graphics frames, which means you're 
seeing sequences of [1,2,2,1,2,2,...] physics updates per visual frame. 
The corresponding residual latencies between physics update and screen 
update would then be [0.667, 0.333, 0.0, ...] times the duration of one 
physics update. It's these latencies and the period of resync that get 
ya. Since it's a repeating sequence, it snaps back into exact 
synchronization with a period of 3 graphics frames, or 20Hz. Maybe 
something like that wouldn't bother your eye, but a near-match in 
frequencies could be much worse: with physics at 65Hz and the graphics 
at 60Hz, the theory goes that the graphics would resync to the physics 
every 12 graphics frames, i.e. a 5Hz resync rate on a 60Hz display 
refresh, which might look like a 5Hz jitter when things are moving fast 
enough on the screen. I'd need to test this, since I've never really 
payed attention. I either accept the buffer tearing in a windowed 
environment, or render simple demos at 1 zillion fps so the residual 
frame error is super small event at full screen with vsync.

gl wrote:

>I'm running ODE at 100Hz and just rendering as fast as I can, and I have yet
>to detect any kind of jitter whatsoever with vsync enabled (although I do
>plan to do basic linear interpolation between frames at some point, just to
>make > 100fps useful).  I guess the problem is more pronounced at lower
>update rates.
>--
>gl
>
>----- Original Message -----
>From: "juhani honkala" <juhnu@all-m.com>
>To: <ode@q12.org>
>Sent: Thursday, April 17, 2003 6:16 AM
>Subject: Re: [ODE] interpolating between physics frames to get the actual
>positions in the render time
>
>
>  
>
>>thanks for your replies..
>>
>>I'm using 100 hz physics coz it's used in the multiplayer client/server so
>>    
>>
>I
>  
>
>>need deterministic results of the physics across
>>different clients(and in the server as well). This efficiently means that
>>    
>>
>I
>  
>
>>can't lock the physics rate to an integer multiply of
>>the screen refresh rate until I force the screen refresh rate(or frame
>>    
>>
>rate)
>  
>
>>being 50 hz flat or some other meaningful value
>>the every client can maintain. It's really the thing I don't want to do
>>    
>>
>(not
>  
>
>>100% about that anymore tho;) Without need for
>>the exact synchronization between the server and client would I definitely
>>adjust the physics step to an integer multiply of
>>the actual frame rate.. or even using variable physics timestep but in
>>    
>>
>this
>  
>
>>case it's no-go i think.
>>
>>the idea of extrapolating instead on interpolating between the frames was
>>kinda nice..would keep the lag smaller.
>>
>>Have to think about it.
>>
>>
>>
>>
>>juhani
>>
>>
>>
>>_______________________________________________
>>ODE mailing list
>>ODE@q12.org
>>http://q12.org/mailman/listinfo/ode
>>
>>
>>    
>>
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode
>  
>