Re: When to change scene hooks

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Thu, 11 Nov 93 21:44:45 -0800


>
> My question is:
>
> Will adjusting the ownship DCS's after pfFrame cause a DCS to shift
> during a Cull/Draw? If so what can I do to get around this. I
> don't want to have to adjust the DCS's in updateView because of
> turret stabalization calculations that need access to intermediate
> transformation matrix values after a DCSRot for the turret.

The short answer is no. All the state related to pfNodes in
the scene graph, including pfDCSes, propagates frame
accurately, so the cull won't see changes made in the app for
frame N+1 until it is culling frame N+1. pfFrame defines the
end of an frame in the application and anything between
two pfFrame()s is part of the same frame.
   
> SimLoop:
> {
> updateView
> - update channel views
>
> pfFrame (draw frame N)
>
> updateSim ( for frame N+1 )
> - get sim inputs
> - calculate new values
> - adjust ownship DCS's (these are direct hooks into the scene)
> pfDCSRot( ownship->dcs_tur, ownship->tur_heading, 0.0, 0.0 );
> do gun stabalization
> pfDCSRot( ownship->dcs_gun, 0.0, ownship->gun_pitch, 0.0 );
> }

But I am curious about your distinction between updateSim and
updateView. From the loop above, without pfSync(), moving the
DCS update wouldn't change any timing w.r.t. other processes in
the pipeline because there is no timing separation between
updateSim and updateView, e.g. in any PFAPP_CULL mode both
overlap the cull: (FR=pfFrame)

| | |
| Sn Vn FR | Sn+1 Vn+1 FR |
|-------==== |-------===== |
| | |
| | CULL n |
| |------------------- |

But if you're using pfSync() after the Sim but before the View,
then there is a difference. (SY=pfSync)

| | |
| Sn SY | Vn FR Sn+1 SY | Vn+1
|------- |==== ------- |====
| | |
| | CULL n |
| | --------------- |

                                      ^
| Note later start of cull

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151


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:05 PDT

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