Michael T. Jones (mtj++at++babar.asd.sgi.com)
Wed, 24 Apr 1996 10:38:51 -0700
:When will Performer provide access to double precision in both
:modeling and matrix operations similar to those in OpenGL (glRotated,
:glTranslated, glLoadMatrisd, glMultMatrixd, etc.)?
Careful here. OpenGL lets you pass double-precision values into the
functions, but all implementations that I'm aware of immediately
convert them to single-precision floating point before taking any
further steps, such as translations, matrix stack operations, etc.
To be clear, the results from using SP and DP would be exactly the
same on every machine that IRIS Performer operates on, were we to
support double precision.
Given that, there is one argument for and one against direct Performer
support for double precision. For: an application may use the geoset
data for it's own purposes and need the extra precision. This is a
good argument. Against: we'd get half of the effective bus bandwidth
since we'd send 8-bytes rather than 4 for each vertex, and the GFX
subsystem would be busy tossing out the extra bytes as it's first
task. This would mean lower performance. Our choice: single-precision,
lower data traffic, and greater performance until such time as the
machine would really use the extra precision.
:We are developing a "real" world simulation system using a geocentric
:coordinate system and, therefore, require the accuracy of double precision.
I'd agree with "desire", but not with "require". The reason is...
:Currently, we are applying an offset to our terrain database in order to
:gain a few decimal places in floating point precision.
...that this approach works well when carefully implemented. 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.
Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590
Michael T. Jones Silicon Graphics, Advanced Systems Division
mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
"Du musst Amboss oder Hammer sein" -- Goethe
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:46 PDT