Re: Performer view frame accurate?
John Rohlf (jrohlf++at++tubes)
Sat, 10 Jun 95 11:13:27 PDT
>
> Hi all,
>
> I want an object to stay stationary with respect to the viewer. Here is
> what I tried:
> - Put the object under a DCS.
> - Each frame calculate the matrix for the new viewer
> position/orientation.
> - Call pfChanViewMat() with this matrix.
> - Call pfDCSMat() with this matrix.
>
> So the view and object both use the same matrix. This almost works. I can
> see part of the object within my view, but it jiggles around. I printed out
> the matrices used for the view and for the DCS each frame in a draw
> call-back, and sure enough they are different! Surely both the view
> transform and the DCS transform are passed down the Performer pipeline (ie
> they should be frame accurate), but it seems one of them is not. If I run
> in a single process then the matrices printed out are the same, but it still
> appears to jiggle around!
>
> Can anyone shed any light on what's going on? Or how to keep an object
> completely still with respect to a viewer? I could just use a draw call-back
> to load some constant matrix onto the stack, but I also want other viewers
> to be able to see the object at the location of the first viewer.
>
> Any ideas?
>
> Rob.
>
> ------------------------------------------------------------------------------
>
> Robert Webb. robertw++at++wormald.com.au
>
> ------------------------------------------------------------------------------
>
Perhaps you have some form of collision detection enabled which
collides with the object and deflects the viewpoint. I am certain both
DCS and pfChannel view matrix are propagated properly down
the pipeline - your printout in the DRAW is misleading because
the matrix for the DCS is that of the APP's copy which is 1 or 2 frames
in the future. This is a strange side effect of Performer's multiprocessing
but we deem it livable because it saves lots of memory and processing
time.
The fact that you get jitters in single process leads me to believe
that something other than multiprocessing wackiness is the problem.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:35 PDT