On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote: > What are your thoughts about fixed-point numbers? If have, say, a 16.16 > fixed-point number and the units are meters, you get a maximum range of > 65 kilometers with a resolution of about 15 micrometers (Reed mentioned > notrons but in practice meters are the most useful for any kind of > human-scale modeling). I'm not a big fan of the "one coordinate system > to rule them all" school of virtual worlds, I'm more interested in > smaller spaces hyper-connected together relative to each other using > portals, scene graph tricks (the contents of space A are embedded in I think portalling is good for many things and can also be used compatibly with continuous space system - like u can have each door to a house/dungeon a portal. I'll avoid if I can tho.
> space B at some offset) or just saying "the edge of this space is > adjacent to this other space..." Fixed point is basically like integer where the resolution is even all the way thru. The nonuniform resolution of floating point can be turned from a weakness to a strength by floating the origin because you get to carry dense sub millimeter rez space with u as u move around. So I vote against fixed point. I reckon GPU makers went away from fixed point for similar reasons. For similar reasons, floating origin in fp space increases the scalability of a continuous virtual world - we were able to model planet-earth such that u can go from space to face and still have smooth motion and interaction - that's going from 60million m in space to ground level. See the (20MB) video:http://planet-earth.org/video/sydzoom2.avi It is not smooth frame rate because I snapped it on my notebook, but it proves the scalability point well enough. > > I'm mainly concerned about the network-abstract representation, of > course. You still need to have tricks in the renderer (like continous > recentering) to support huge-space schemes. I have been thinking that objects in the active list (being displayed or capable of interacting with avatar) should have not positions, but a pointer to their position in space and time that resides in a block of such positions. Then when you need to update all object positions due to user navigation it can update the block in linear time. Note this is just for the display system object positions - not their real world positions held on the object system (which could reside partly on server). in a floating origin system the display system object positions are always the minimum values relative to the avatar - hence they are unique to avatar and do not correspond to their object system positions. > > Also, with fixed-size sectors, I'm not sure how you would do a really > huge area like the entire planet earth (although as we've established > from the discussion, floating point numbers fair little better). If you 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 > just connect the edges, that's still many many thousands of sectors. true, it introduces problems. > Perhaps one way of approaching at it is as a sparse-matrix problem or a > hash space. I don't know the best answer to that as I bypass segmentation and have not looked for efficient segmentation systems. > > At any rate: coordinate systems are hard. I don't find them hard 'cause i keep it simple :) But u still have to have multiple coord systems e.g. for geospatial apps - but at some pt in the graphics pipeline it all gets to carteasian x,y,z,t space. chris > _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
