Re: Double-Precision, Large-Area Databases, and SIGGRAPH

New Message Reply Date view Thread view Subject view Author view

Michael T. Jones (mtj++at++intrinsic.com)
Tue, 04 May 1999 20:21:09 -0700

At 05:50 PM 5/4/99 -0700, you wrote:
>There's a slight problem with your original post Michael.
>
>The notion that you can apply the chunk offset for each terrain cell in
>method B without a matrix and therefore get bound box geoset culling is
>wrong. It would require a lot of translations applied directly to the
>vertices and infact these woiuld have to be applied instantly whenever
>the eye origin changed.
>
>Bottom line you need that single precision offset on the model matrix to
>accomodate some variable delta between the eye and the terrain
>reguardless of the scheme used.
>
>Apart from this both suggestions are perfectly fine. In double precision
>choose an offset near the eye and subtract that value from both the eye
>and the model matrix, then cast to single precision. Operation A is a
>subset of B where the exact eye point is chosen as the point near the
>eye, it is however not significantly different.

Bold as it is to disagree with Angus, I think my original email must have
been confusing. Always the optimist, I will try again and see if I can say
it better this time. I'm sure that once it's presented clearly everyone will
understand how method B works.

Both method A and method B require that each cell be constructed
with coordinates based on a local origin, such as placing (0,0,0) at the
center of the cell. These methods also require recording as extra data
the high precision location of this origin, for example by using double
precision coordinates to record the "exact" location of this (0,0,0) in
the global coordinate system.

Now, in method A we keep the eyepoint at (0,0,0) in the special render-time
world space by inversely transforming all of the tiles by the inverse of
their displacement from the current high-precision eyepoint. This is done
with a transformation located at the root of each tile's scene graph. The
contents of the transformation is likely just a translation that represents
the difference between the eyepoint in high precision and the tile's origin
in high precision. Method A is the basic method.

Method B, the advanced method, is a little bit more tricky. One way to
prepare to visualize it is as follows. Let's say you used method A, but
just for fun, you add a displacement (dx,dy,dz) to the relocation matrix
at the root of each tile's scene graph. And, you also replace the (0,0,0)
eyepoint of method a with (dx,dy,dz). What would be the difference in
the resulting image? none. (make sure that you understand why the
only difference would be if one or more of dx, dy, or dz, when added
to the furthest coordinate in a tile's geometry or to the elements of
the tile translation matrices would cause single precision overflow;
algebraically there is no difference.)

Now that we know we can add our deltas with impunity so long as they
are not too big, we ask, why would we do this? Well, here's where we
have the ability to juggle things so that IRIS Performer can do all of
the necessary tile relocation while avoiding relocating the tile that is
directly below us -- the very one that has the highest LOD geometry
and likely the most bounding boxes. The motivation for this is that
Performer does not [at least did not when I was there ;-)] test geoset
bounding boxes when transforms are in force. What we do is to see
what tile the eyepoint is "in," use that tile's high-precision center as the
center the translations of all other tiles are computed from, draw that
tile "naked" without translation (i.e., at it's (0,0,0) local origin) and
use the displacement of the high-precision eyepoint from the high-
precision center of the tile we're "in" as our (dx,dy,dz) for the eye
point. This requires a few extra subtractions and figuring out which
tile the eyepoint is in. In exchange, you get geoset bounding box tests
in the main tile near the eye, which can make a big difference in some
cases.

Hopefully this was interesting enough for such a long description.

Regards,
Michael "Treasurer-to-be" Jones
Intrinsic Graphics CTO: http://www.intrinsic.com
SIGGRAPH treasurer candidate: http://www.siggraph.org/elections/index.html

----------
Michael T. Jones - <mailto:mtj++at++intrinsic.com>mtj++at++intrinsic.com -
<http://www.intrinsic.com/>Intrinsic Graphics Inc. - (650) 210-9933
A frog in a well says "The sky is as big as the mouth of my well"

At 05:50 PM 5/4/99 -0700, you wrote:

There's a slight problem with your original post Michael.

The notion that you can apply the chunk offset for each terrain cell in
method B without a matrix and therefore get bound box geoset culling is
wrong. It would require a lot of translations applied directly to the
vertices and infact these woiuld have to be applied instantly whenever
the eye origin changed.

Bottom line you need that single precision offset on the model matrix to
accomodate some variable delta between the eye and the terrain
reguardless of the scheme used.

Apart from this both suggestions are perfectly fine. In double precision
choose an offset near the eye and subtract that value from both the eye
and the model matrix, then cast to single precision. Operation A is a
subset of B where the exact eye point is chosen as the point near the
eye, it is however not significantly different.


Bold as it is to disagree with Angus, I think my original email must have
been confusing. Always the optimist, I will try again and see if I can say
it better this time. I'm sure that once it's presented clearly everyone will
understand how method B works.

Both method A and method B require that each cell be constructed
with coordinates based on a local origin, such as placing (0,0,0) at the
center of the cell. These methods also require recording as extra data
the high precision location of this origin, for example by using double
precision coordinates to record the "exact" location of this (0,0,0) in
the global coordinate system.

Now, in method A we keep the eyepoint at (0,0,0) in the special render-time
world space by inversely transforming all of the tiles by the inverse of
their displacement from the current high-precision eyepoint. This is done
with a transformation located at the root of each tile's scene graph. The
contents of the transformation is likely just a translation that represents
the difference between the eyepoint in high precision and the tile's origin
in high precision. Method A is the basic method.

Method B, the advanced method, is a little bit more tricky. One way to
prepare to visualize it is as follows. Let's say you used method A, but
just for fun, you add a displacement (dx,dy,dz) to the relocation matrix
at the root of each tile's scene graph. And, you also replace the (0,0,0)
eyepoint of method a with (dx,dy,dz). What would be the difference in
the resulting image? none. (make sure that you understand why the
only difference would be if one or more of dx, dy, or dz, when added
to the furthest coordinate in a tile's geometry or to the elements of
the tile translation matrices would cause single precision overflow;
algebraically there is no difference.)

Now that we know we can add our deltas with impunity so long as they
are not too big, we ask, why would we do this?  Well, here's where we
have the ability to juggle things so that IRIS Performer can do all of
the necessary tile relocation while avoiding relocating the tile that is
directly below us -- the very one that has the highest LOD geometry
and likely the most bounding boxes. The motivation for this is that
Performer does not [at least did not when I was there ;-)] test geoset
bounding boxes when transforms are in force. What we do is to see
what tile the eyepoint is "in," use that tile's high-precision center as the
center the translations of all other tiles are computed from, draw that
tile "naked" without translation (i.e., at it's (0,0,0) local origin) and
use the displacement of the high-precision eyepoint from the high-
precision center of the tile we're "in" as our (dx,dy,dz) for the eye
point. This requires a few extra subtractions and figuring out which
tile the eyepoint is in. In exchange, you get geoset bounding box tests
in the main tile near the eye, which can make a big difference in some
cases.

Hopefully this was interesting enough for such a long description.

Regards,
Michael "Treasurer-to-be" Jones
Intrinsic Graphics CTO: http://www.intrinsic.com
SIGGRAPH treasurer candidate: http://www.siggraph.org/elections/index.html

Michael T. Jones - mtj++at++intrinsic.com - Intrinsic Graphics Inc. - (650) 210-9933
A frog in a well says "The sky is as big as the mouth of my well"

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue May 04 1999 - 20:20:36 PDT

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