Re: Position of object changing

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Wed, 01 Jul 1998 14:47:31 -0700

Steve Baker wrote:
>
> On Wed, 1 Jul 1998, Angus Dorbie wrote:
>
> > It's very easy.
> >
> > The simplest way is to store xyz for top level scene graph objects
> > and the eye in double precision.
> > Then each frame you subtract a large offset from these double
> > precision numbers to to keep the eye near the origin. You then
> > cast to float and send to performer or OpenGL.
>
> In principal, this is all true...
>
> > It's trivial to implement at the application level.
>
> Hmmm - this is easy to say when you don't consider all the OTHER
> things that a real application has to do.
>
> The problems are that each top level node (which is going to include
> EVERY terrain tile) becomes a DCS. You now have zillions of DCS's
> which means that geostate sorting and isect caching becomes ineffective.

Zillions is an exaggeration.
The database often does have to be constructed differently for
best performance but there are other schemes which don't
injure performance as much, such as database tiles with inbuilt
local offsets and a single DCS above multiple tiled sets. Or
if state changes are a concern you separate state below
independent DCSs, none of these makes the implementation
difficult.
This will usually cost you matrix work or state changes, that's
a given.

For many applications this isn't even an issue.

> What happens when you have multiple eyepoints that are a significant
> distance apart? ...etc.

The eyepoint issue is an interesting one however all players in a
scene on a single I.G. are typically within a few kilometers of
each other so as long as the base origin is within a reasonable
distance of each you have plenty of precision.

Other I.G.s have different eyepoints and therefore database origins,
and this works just fine as long as positional information is passed
in global coordinates in double precision which any sensible system
does anyway.

If this really is a problem then a traversal mask on multiple DCSs
sharing the same sub graph solves this in the rare case that it's a
problem.

>
> (and its always the 'etc' that takes the time to do!)
>
> When you get into all the practical details of making stuff like
> intersection testing and database paging work at the same time,
> it gets hard - and messy - and (if you are not v.careful) will do
> bad things to performance.

As with everything else you need only subtract the eye from the
isector vector positions.

>
> No, it's very far from trivial.

I still disagree with this, but I concede that the observation
is a relative one compared with other tasks and is related to
the complexity of an application.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.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:57:39 PDT

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