On 2/10/07, Karsten Otto <[EMAIL PROTECTED]> wrote: > I am not quite sure what kind of precision is necessary here... I'd > expect that it should be enough to center the current sector for > displaying purposes, and re-center to the new sector once you cross a > portal boundary. Considering relatively small sectors, I'd imagine an > error factor of a few centimeters is not too disturbing when the > objects in question are 50 meters away. This is probably two pixels > difference on the average display resolution. I can live with that :-)
What is "enough" precision is the main problem with all segmentation approaches - what is enough is worked out from experience/testing or guessing. But in terms of general simulation there is no one size that will always work when 10m or less can make a noticeable difference. > > Regarding physics simulation, which (if I understand you correctly) > suffers the most from matrix creep, well... I am no expert, but > couldn't you calculate this in a virtual coordinate space, derived > from the world coordinates in such a fashion that all objects > involved are close to the center? And then, once you reach some > "stable" result, convert the virtual coordinates back to world > coordinate space and continue from there? That may not be > particularly precise or realistic, but again, as long as the system > behaves more or less consistently, I can live with it. if your physics - say bouncing boxes like my example - is performed in it's own local coordinate space then it could be made consistent every time - but I can't see how you would combine the rendering of this in realtime with the rendering of the scene - unless you artificially composite painters algorithm style. In that case it would work but all sorts of rendering things would not be consistent with rest of scene - shadows, lighting, occlusion etc. And to get the compositing part to look good might be difficult and slow the performance of your rendering system. e.g. if you used BSP tree system like fly3d then how do you composite a physics sequence over 200 frames when it crosses several partition planes? chris > > Regards, > Karsten Otto > > Am 09.02.2007 um 16:29 schrieb Peter Amstutz: > > > On Wed, Feb 07, 2007 at 08:57:18AM +0900, chris wrote: > > > >> That is not to say this model cannot work as a hybrid system with > >> portals at doorways, for space jumps etc. In fact, for very large > >> scale solar/galaxy systems you would have to either use very high > >> precision in the object system or maybe double precision with > >> portals. > >> > >> but to get optimal accuracy, scalability etc throughout where the > >> avatar travels then the graohics engine should be looking at a > >> continous floating origin. > > > > Don't space-warping portals achive this effect? When you walk through > > the portal (both the "rendering walk" as well as the actual avatar > > moving through), the space rendering is now centered on a new > > coordinate > > system. Provided your sectors are relatively small, this seems to be > > more or less equivalent to the periodic recentering described in the > > Dungeon Siege paper you posted. One of the points of the Dungeon > > Siege > > paper was also that recentering was a relatively expensive > > operation, so > > you didn't want to do it every frame, but only when the camera crossed > > certain boundaries, so it's not truely "continous" in the sense of > > doing > > it before every frame. Besides, that's complete overkill, since the > > point here is precision problems crop up at distances of 30-40km from > > center (assuming 1 notron = 1m) so it takes a very very large world > > before this becomes a problem (or you're doing a geospatial > > simulation...) > > > > Also, for Interreality, the issue is primarily one of representation, > > since we use an off the shelf 3D engine (Crystal Space). So my > > concern > > is how you're going to actually represent those huge worlds (since you > > do have precision problems beyond 30-40km) as a downloaded map, > > once you > > have that data loaded in, rendering is a separate issue. > > > > (I haven't had a chance to read those other links you posted, so > > perhaps > > those explain the idea in more detail). > > > > -- > > [ Peter Amstutz ][ [EMAIL PROTECTED] ] > > [ [EMAIL PROTECTED] ] > > [Lead Programmer][Interreality Project][Virtual Reality for the > > Internet] > > [ VOS: Next Generation Internet Communication][ http:// > > interreality.org ] > > [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu > > 18C21DF7 ] > > > > _______________________________________________ > > vos-d mailing list > > [email protected] > > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > > > _______________________________________________ > vos-d mailing list > [email protected] > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > _______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
