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

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Wed, 05 May 1999 13:15:21 -0700


This still seems bogus to me.

Your original post said this "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."

That is not possible. Your latest elaboration tries to suggest that this
is possible by changing the eye transformation for each tile instead of
changing the model matrix, but this is the EQUIVALENT thing. Not only
does it confuse lighting and culling, but the way you'd ACTUALLY do this
is to modify the MODELVIEW matrix, ie use a DCS or a callback per tile.
So all those cull callbacks (or contorted bound calculations but IMHO
this would be hellish), draw callbacks and screwed up lighting (I
suppose distant lights would be OK since these are translates) are a
mess.

Bottom line, like I said you still need that modelling manipulation
between the eye and the terrain cell. You can call it a viewing
transformation and maybe you'll fool some of the people, but I'm not
fooled.

Cheers,Angus.

> Michael T. Jones wrote:
>
> 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"

-- 
"Microsoft's system was like a forest that hadn't had a controlled
 burn in decades, just waiting for one person with a match to turn
 it into a disaster. Melissa was Microsoft's fault. They left their
 system wide open to this sort of abuse, they knew it could happen
 and did nothing." -- Bruce Perens

For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed May 05 1999 - 13:15:28 PDT

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