From: Tom Jolley (jolley++at++fltsim.stl.mo.boeing.com)
Date: 07/18/2001 12:10:58
Hi Yair,
Thanks for the information. I have more questions about pfASD.
It looks like what I'm seeing is the change to the pfChannel's
view matrix is not synchronized to the change in the DCS node above
the ASD node when the COMPUTE process evaluates the ASD's geometry.
I think the DCS change is lagging the view matrix change from the
COMPUTE process's point of view. Does the COMPUTE process start a
new frame between when the pfChannel is updated and the scene graph
is updated?
Questions about pfASD::setCullEnlarge:
1. If the channel's FOV is 90 degrees (symmetrical) what happens
when the fov multiplier (first argument) is greater than 2.0?
2. If the channel's FOV is asymmetric, how does the setCullEnlarge
function handle this?
3. Should near and far (the other two arguments) always be greater
or equal to 0.0?
Another thing that I am seeing is some of the asd geometry is culled
when the pfChannel's FOV is asymmetric. This leaves noticeable
holes in my model. I have been unable to correct this using
setCullEnlarge.
Yair Kurzion wrote:
>
> Hi Tom !
>
> pfASD evaluates its visible geometry in an asynchronous process (COMPUTE).
> A COMPUTE frame may take longer than a regular APP/CULL/DRAW frame, and so
> the visible geometry may be correct for an eye position in the past.
>
> To solve that, pfASD has to be culled for a larger frustum than the channel
> viewing frustum. How large depends on the application:
>
> o The larger (more complex) the pfASD model, the longer it takes to evaluate,
> and the older the geometry you render is.
>
> o The faster the eye position moves (especially - angular rate), the wider the
> cull frustum has to be.
>
> Take a look at the man page for pfASD::setCullEnlarge. It lets you modify the
> cull frustum of a pfASD.
>
> -yair
>
> > I am seeing what looks like unusual culling effects with geometry
> > in a pfASD node. I have the pfASD node as a child of a pfDCS node.
> > When I change the eyepoint position and the DCS position by the
> > same amount parts of the geometry in the pfASD node, that should
> > be visible, are culled. When the positions stop changing the
> > culling catches up and the geometry looks the way I expect it to.
> >
> > I see the same thing using asdfly (using run_simple) when I rapidly
> > change the eyepoint position backwards. It looks like it takes a
> > couple of frames for the culling to catch up.
> >
> > Anyone have any explanations or solutions? Can ASD be used in an
> > application with channels covering 360 degrees or with side channels
> > and a high roll rate?
> >
> > --
> > Tom Jolley
> > jolley++at++fltsim.stl.mo.boeing.com
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
> --
> \_________ \_____ \__ \__ \_____ Yair Kurzion
> \_________ \_____ \__ \__ \_____ yair++at++sgi.com
> \__ \__ \____\__ \__ http://reality.sgi.com/yair
> \__ \__ \__ Work: (650) 933-6502
> \__ \__ \__ Home: (408) 226-9771
> \__ \__ \__
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- Tom Jolley jolley++at++fltsim.stl.mo.boeing.com
This archive was generated by hypermail 2b29 : Wed Jul 18 2001 - 12:11:01 PDT