Re: Position of object changing
VSM 13 (vsm13++at++hol.fr)
Mon, 6 Jul 1998 11:34:44 +0200
>
>> 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.
>
>I try to use some DCS to translate the DataBase, these solution doesn't
works, if you have a large coord. problems before, you conserve it.
a solution, may be, is to use SCS to flatten, so we transform the polygon
coord., but is it possible in all application ( very large database used
with pfDBase, multichannel ( may be some errors is the limits of screen)
I think that the way to move database and to fix the eye, is a good
solution, but it's need to think to all the details of the application ( GL
Callback, Mobiles, HUD, and dialog with a host) and it's not easy.
=======================================================================
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:40 PDT