Steve Baker (steve++at++mred.hti.com)
Mon, 1 Nov 93 10:17:37 -0600
When the dynamics task creates a data packet, it time-stamps it, when
the graphics task is nearly ready to start a new frame, it extrapolates
the data forwards to the point when the video retrace is likely to
occour for this data.
The extrapolation would be necessary in order to remove the latency
through the system - even if the dynamics code were utterly synchronised
to the frame rate. One of the nastiest features of VR systems that I have
seen is the total ignorance of the effects of failing to remove latency.
This is the single biggest cause of so-called simulator sickness - especially
in head and eye-tracked systems.
Given that you need the extrapolation anyway, the cost of using a variable
or asynchronous frame rate is minimal.
The other aspect of all of this is the effect of graphics overloads. These
are very hard to avoid when the system is being driven near to its limits
(ie Always :-) ) and when a frame take too long to render, you generally
don't want the dynamics stuff to slow down as well. (eg A car driving down
a complicated-looking street should travel at the same speed as on driving
through a featureless plain given that all other simulation parameters are
equal!!
Steve Baker
Hughes Training Inc.
Arlington, Texas.
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:05 PDT