When I speak of a single continuous world space I am referring only to the subset of the application that is being used in the display system: the part of the app that includes the grahics pipeline. This is where we are forced to used single precision because of hardware limits and performance and this is where it is good to avoid overheads or artificial boundaries in an apparently confinuous space (like in Morrowind, when walking along a path, it would halt and you'd get a message like "loading external environment" and then you can continue). At any one time it is only a subset of the aplication space.
for more background you may want to look at these papers: published in Cyberworlds 2006: http://planet-earth.org/cw06/thorne-CW06.pdf to be published in the Journal of Ubiquitous Computing and Intelligence special issue on Cyberworlds: http://planet-earth.org/ubcw/thorne-UBCW.pdf published in proceedings of Cyberworlds05: http://planet-earth.org/cw05/FloatingOrigin.pdf 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. The best description of a on-the-fly origin shifting system I have seen is O'Neil's "A Real-Time Procedural Universe, Part Three: Matters of Scale": http://www.gamasutra.com/features/20020712/oneil_01.htm Although it is not a true continuous floating origin it gives similar effect. On 2/7/07, Peter Amstutz <[EMAIL PROTECTED]> wrote: > On Fri, Feb 02, 2007 at 12:15:47PM +0900, chris wrote: > > > > Yes - that's why we use a single continuous world space. Many systems > > like VGIS divide the earth into fixed sized sectors. This sort of > > segmentation creates many overheads. > > The Dungeon Siege game segmented its world into SiegeNodes, each > > with its own local coordinate space. When the viewpoint crossed a > > boundary between nodes, the local coordinate system changed to that > > of the node being entered and a ``Space Walk'' began. > > The space walk visited each active node and recalculated coordinate > > transforms to shift objects closer to the new local origin. This > > ensured coordinates did not get large enough to cause noticeable spatial > > jitter. It uses considerable processing resources to do space walk and > > the frequency of performing recalculations has to be limited: ``as > > infrequently as possible to > > avoid bogging down the CPU'' {Bilas}: > > http://www.drizzle.com/~scottb/gdc/continuous-world.htm > > Okay, I've had a chance to read over and digest the "continous world" > document. As I understand it, the "world" is basically a set of "nodes" > which are connected to form an adjacency graph. The edges describes how > the nodes are oriented/transformed in space in relation to each > surrounding node. The camera works in the coordinate space of whatever > particular node it's on, and everything else is recentered relative to > the current node. > > I think this fits in very well with using portals in VOS. A normal > portal is a polygon in space which causes the renderer to recursively > start rendering the sector behind the portal, clipped to the portal > polygon. This works nicely for indoor areas because if the portal isn't > visible, it doesn't have to consider the room behind the portal at all. > It's also used by some engines to connect indoor and outdoor areas (for > example, I believe indoor areas in World of Warcraft are portals to a > separate map, so that a viewer who is outside the building doesn't have > to consider the building interior in rendering.) > > The second kind of portal is a space-warping portal. This works the > same as a normal portal, except that a space transform (rotation and > translation) is applied to the target sector. This means that target > sector no longer has to be in the same coordinate system as your current > space. Your current space has one origin, the space on the other side > of the portal has another origin, and they're defined relative to each > other. Thus, crossing the portal boundary is in effect recentering the > entire space. > > I've always been against a unified coordinate system for virtual worlds > for philosophical and pragmatic reasons (you're never going to get > people to agree on how to allocate "space" except via some central > authority), so it's good to consider that this is probably the best > technical solution as well. agreed - as far as the object system, which is the main part of the application - you need appropriate coordinate system(s) - like lat, lon, height and reference system for geospatial. And for outer space some segmentation is likely. The translation from object system coordinate system to display system coordinate system happens with the LOD/visibility/active object activation. Then the active object framework is in charge of taking updates of object positions from the free navigation system (navigation deltas). regards, chris > > -- > [ 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 ] > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFyM8CaeHUyhjCHfcRAt1bAJ923pmURBdOhU0eEl8qdbrImYFrugCeOKvt > fnH9vjbL6zA9M1gumIxRZUY= > =2Joh > -----END PGP SIGNATURE----- > > _______________________________________________ > 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
