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 :-)
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. 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 > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
