Steve Baker (sbaker++at++link.com)
Wed, 1 Jul 1998 17:10:40 -0500 (CDT)
> Zillions is an exaggeration.
There is no such word - it means exactly what I want it to - which
in *this* case is "LOTS" :-)
> 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.
But it's naive to think that one can simply wave a magic wand
and change the way terrain is constructed just to suit *this*
problem - it's often required to be set up some other way for
some other reason such as culling, ISECT, disk bandwidth, memory
fragmentation, memory consumption, 3rd party loaders...
You have to see the big picture. This isn't a spinning cow
or Performer Town. In my case, it's a database the size of
a continent with MANY other constraints on how it's constructed.
> > 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.
See - Naive again! I write simulations of aircraft that can
launch a missile 200 miles with a FLIR camera that sends a
picture back to the cockpit. Other guys in the simulation have
these too - they can send you the picture from their missiles.
> 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.
Well, using a separate IG isn't usually cost-effective - and using
multiple Performer instances implies multiple pagers, multiple copies
of library objects, issues of correlation between IG's....also not
cost-effective (*or* "trivial").
> 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.
...unless the same terrain tile (which is now a DCS) is in view
from both eyepoints (which it often is).
> > (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.
But of course Isect is asynchronous - so more complications.
Look, I know it can be done - I don't argue with that. It's
just not something you can wave away with a general 'this is
easy' kind of attitude.
Sorry Angus - I greatly respect your opinion in many matters - but
the practicality of making this change in a full-up 'real' system
is deep. This doesn't mean it can't be done - it *must* be done
in many cases.
Steve Baker (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker++at++link.com http://www.hti.com
Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:39 PDT