Re: Latency critical viewing transformation updates?

New Message Reply Date view Thread view Subject view Author view

Javier Castellar (javier++at++sixty.asd.sgi.com)
Thu, 24 Oct 1996 11:06:34 -0700


If you run in APPCULLDRAW (single process) then the internal performer latency
will be ZERO, but then you will not take adavantage of multiprocessing.

You can reduce the latency while using multiprocessing to one frame intead of
two (from point of view of the APP and without counting the "video" frame)
using a mode named CULLoDRAW. In this mode, CULL and DRAW are processing the
same frame at the same time (well, actually draw is slightly behind).

In previous versions of performer CULLoDRAW only worked with single pipe, I did
not tried on the latest versions in multipipe.

Keep in mind that the culling creates a "list of things to do in the draw" from
the APP point of view, which means that the point of view in the draw has to be
consistent, becasue the culling is clipping out database out of the point of
view. If the point of view in the draw is different it means that you could run
out of database.

Typically performer will "transport" the initial point of view across the
software pipeline, adding 0, 1 or 2 frames latency depending of the
multiprocessing mode (see pfMultiprocess).

Typically the users will have another asyncronous process reading the head
tracker using a serial port. it will add a 1/2 frame latency to put the data in
to the APP.

In order to compensate both the tracker and the performer latency some people
has developed prediction of the point of view.

Instead of using the point of view from the tracker you can stimate where is
going to be after 2 frames in function of the previous history of the tracker
data. Since the humans are not androids yet, there are limits in both angular
speed and angular acceleration (traslation is not so demanding) that you can
take in count to design the "digital filter".

Some people even included accelerometer sensors in addition to the tracker,
building a much faster predictive digital filter.

You may find interesting a siggraph paper from Hughes, in wich they descrive
this kind of set up.

There is a very high end helment buit by Hughes that reduce the user latency
(we should say that reduce the error), looking like a "latency free" tracking.

Also running a higher vertical retraces may help since the latency due to
multiprocessing is n_frames*1/frame_rate

-Javier

-- 
*************************************************************************
* Javier Castellar Arribas          * Email:         javier++at++asd.sgi.com *                 
*                                   * Vmail:            	 3-1589 *            
* Member of Technical Staff         * Phone:  415-933-1589 / 2108 (lab) *
* Core Design - Applied Engineering * Fax:                 415-964-8671 *     
* Advanced Systems Division         * MailStop:                  8L-800 *
************************************************************************* 
* Silicon Graphics Inc.                                                 *
* 2011 N. Shoreline Boulevard,                                          *                        
* Mountain View, California 94043-1386, USA                             *
*************************************************************************
"Violence is the last refuge of the incompetent"
						Hardin Seldon
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:48 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.