Re: Jumping

New Message Reply Date view Thread view Subject view Author view

Rob Jenkins (robj++at++quid)
Fri, 20 Sep 1996 15:08:57 -0700


On Sep 20, 2:43pm, Cris Villarma wrote:
> Subject: Jumping
> I'm moving a set of 3-D models in a circle and have the eyepoint
> centered on one of the models. I've noticed that all of the models,
> besides the center one, deviate back-and-forth in position when
> they should be "travelling" in a straight line. (the deviation
> is small but very noticeable)

Hi Cris

If you have large world coordinates and all you position are given in absolute
coords you may be running out of floating point precision. If so, Michael Jones
posted a good discussion of handling this a while back which I'll paste below:

"
..... What you need are some non-performer DP values:
   a DP eyepoint location,
   a DP global origin, and,
   a DP local origin for each big chunk of your world.
(The maximum chunksize should be limited to about 1/2 the dynamic range
of SP given your chosen model coordinate system epsilon).

In operation (method A):
   put the eye wherever you want (DP).
   put the global origin at the eye (DP).
   set the performer eye to 0,0,0. (SP is fine for this ;-)
   for each chunk
      compute chunkOffset as chunkOrigin - globalOrigin (DP)
      (this is the happy part ... even though the two numbers
      above are DP, the difference fits into a SP number nicely)
      set performer DCS for chunk to chunkOffset (SP)
   pfFrame();

Alternate method (saves one DCS, under the eye). Make sure you *really*
understand method A before thinking about this.
   put the eye wherever you want (DP).
   figure out which chunk is under the eye -- the "localChunk".
   set the global origin to the localChunk's origin. (DP)
   compute eyeOffset as eyepoint - globalOrigin;
      (though these subtrahends are DP, their difference is
      representable in SP)
   set the performer eye to eyeOffset
   for each chunk
      compute chunkOffset as chunkOrigin - globalOrigin (DP)
      (this is the happy part ... even though the two numbers
      above are DP, the difference fits into a SP number nicely)
      set performer DCS for chunk to chunkOffset (SP)
   pfFrame();

Once it all makes sense to you, implement method B if there is much
complexity in your database. The advantage of B is that there's no
matrix (or just an identity matrix) in the performer scene graph above
it, so that libpr geoset bounding box culling will be performed. This
can be a big win in the local area when many cultural features are
present and geodes contain many geosets.

Someday, perhaps Performer will provide double precision values
for the eyepoint and global offset in the pfChannel, and either a
special pfOrigin node or a new semantic for DCS nodes to make the
implementation of methods A and B automatic. Until then, the code
outlined above is identical to what we'd do--just as efficient and
probably better since it makes the relationships between the chunk
dynamic ranges and SP/DP precisions more exposed and thus likely
more widely understood.

Michael "Think Globally, Offset Locally" Jones

P.S. the case for DP geoset data so that CAD modelling tools, FEA
     programs, and such have access to the high-precision data
     that they need is a good one and not one that's lost on us.
----------------------------------------------------

Cheers
Rob

-- 
________________________________________________________________
Rob Jenkins
Silicon Graphics
robj++at++csd.sgi.com
=======================================================================
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:35 PDT

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