Angus Dorbie (dorbie++at++sgi.com)
Wed, 01 Jul 1998 16:09:54 -0700
I never said it was or that I had a magic database wand. But
my proposed solution and claim to simplicity supposed that
one started constructing the right database from the outset.
I'm not suggesting a database is easy to convert but it's
unfair to consider database conversion in the complexity of
a solution, only database construction and one is no more
difficult to build than the other.
>
> > > 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.
No it's not naive Steve, this is not entirely typical of
applications. I did offer a solution for the alternative
case but even so, with the right matrix manipulation
for the ship & missile, even at 200 miles you may have enough
precision for both channels.
>
> > 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").
Multiple systems is typical of real world configurations.
It may be desirable to have single systems driving multiple I.G.s
but as I pointed out there's a solution for that also which you
seem to have misunderstood (see below).
>
> > 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).
Wrong, the same cell exists bellow multiple DCSs, the transformation,
traversal mask and cull result for each branch is different. The
scheme resolves your 200 mile missile problem and does so really easily.
These are only the very highest level scene DCS's which need to be
altered and with the right database there shouldn't be that many.
>
> > > (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.
Well infact a real implementations of what I've described
(at least the ones I've worked on) don't track the eye each
frame but rather choses a fixed base which changes occasionally,
so for real world applications synchronization isn't infact a
problem.
This is no more complex (just easier to conceptualize for
beginners), the fixed base gets subtracted from the scene
object positions, and the eye instead of the eye going to
zero.
>
> 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.
>
The respect is mutual, but I too have worked on full-up 'real'
systems, and even working for SGI I don't just sit around here
spinning cows all day ;-)
It's been pointed out that the solution I supplied was trivial
because the app it works for is also trivial. I agree with this
to some extent, but for many this is the only solution which is
required. I also believe, and it's been my experience, that
none of the obstacles here greatly increase the complexity
of a solution.
I still believe that this isn't difficult, the principals
are really simple and as usual the complexities of a solution
have greatly overplayed in this thread.
Cheers,Angus.
-- "Only the mediocre are always at their best." -- Jean GiraudouxFor 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
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:39 PDT