DCS matrix during perf. stages

New Message Reply Date view Thread view Subject view Author view

Ran Yakir (rany++at++bvr.co.il)
Wed, 8 Jun 1994 09:43:45 +0000


Hi

I read in some older letter ("Re: multiprocessing/ multibuffering ???" by Jim
Helman), that Performer keeps a separate copy of the scene graph for the APP
and CULL stages (I'm ignorring ISECT now). The exact words were :

>> When Performer runs multiprocessed, the scene graph is
>> multibuffered with the APP, ISECT and each pfPipe's CULL process
>> having its own copy of each scene graph node. Updates propagate
>> frame-accurately from the APP stage of the pipeline. Each frame,
>> all changes to the scene graph (e.g. - a change to a DCS matrix or
>> to the scene graph topology) are copied from the APP by the ISECT
>> and CULL processes.

Now, why is this not true for the DRAW process too ? I know the draw process
can not change the scene. For example, it can not change a DCS matrix. However,
if a DCS matrix is changed in the APP for frame # (n), the change will enter
CULL only at next frame, because CULL is doing frame # (n-1), but DRAW will see
the change immediately, even though it renders frame (n-2) now.
I've tried that with a DCS, and it was as stated above. It seems that this
could lead to problems with DCS's close to the eyepoint, which will be rendered
in a 'future' position as far as DRAW process knows.
Am I wrong ? If I'm right, is there a solution ?

Thanks

Ran Yakir

-- 
 __                                  | Ran Yakir
 /_)  _  __   \  / _   / o __        | Graphics App. Chief Engineer
/ )_ (_(_) )   \/ (_(_/<_(_)(        | BVR Technologies Ltd.
              _/                     |   
-------------------------------------+--------------------------------
Phone :                              | E-mail : rany++at++bvr.co.il
  Work : 972-3-5715671               |
  Res. : 972-3-6995364               |
Fax    : 972-3-5715668               |

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:50:19 PDT

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