On 2/13/07, Peter Amstutz <[EMAIL PROTECTED]> wrote: > On Sun, Feb 11, 2007 at 08:40:13AM +0900, chris wrote: > > > Hee hee! That's really what I aim to minimise with the floating origin!! > > I don't believe it is so manageable in a conventional origin-relative > > system. > > The spatial error that I talk about generally increases linearly with > > distance from origin so that is not such a big problem if you move the > > origin every now and then - like every 3 km in MS flight simulator. > > But there are a few situations where it can increase in powers of 2 - > > rare so you can discount them if you want (I don't, but that's me). > > So if there is no absolute origin, how do you organize anything in the > space at all? I'm confused. There is and absolute origin in the object system. Let's say your application uses double precision geospatial coordinates for objects - I'll call these application coordinates. The object system, which may be entirely or partly on the server holds objects with positions relative to an absolute origin and tracks their movement and the movement of avatars normally.
In the display system, which includes the graphics pipeline, object positions are in cartesian (x,y,z) single precision floats. Call these world coordinates. When an object is placed in the active environment surrounding the avatar, its coordinates are projected from application coordinates into double precision cartesian. The same is done for the avatar position. The double precision position of the avatar is then subtracted from the object position and you have a small relative object position as a result. That is then converted into single precision (x,y,z) that is now much more accurate than it would have been if the display system used an absolute origin. The new object is added to the active object framework. While it remains active, navigation of the avatar results in reverse translation deltas going to the active object framework which moves the objects accordingly. So as the avatar "moves" towards an object, it's single precision coordinate gets decremented and becomes smaller. The closer an object is to the avatar the more significant digits its coordinate values have. >You said that recentering everything is an > expensive operation, yet you seem to be proposing that you move the > center every frame??? I related to examples where recentering of a segmented coordinate system have been reported as expensive by the developers themselves. This is because of the overheads of maintaining many coordinate systems and trying to use it in the rendering pipeline. With a floating origin you only have one coord system in the active world coordinates. The only overhead is that, when the active object framework does its usual job (e.g. each frame is may ask all the objects to move, return events and it does collision detection then rendering), it also translates the objects by the reverse avatar navigation translation - three additions per object - not v expensive. Also, given that the avatar is at the origin, this small expense is offset to some extent by small performance improvements in rotation and scaling about the observer, distance and proximity calcs between observer position and other positions because the observer is at (0,0,0). There is also the fact that you can do more calculations in single precision and on some architectures single precision square root and divs are twice as fast. So in the balance there is no significant performance cost and may even be small performance improvements - depending on what operations are being done frequently. >Or are we talking about more than just a minor > tweak to the renderer, but actually building an entirely new "non > traditional" rendering loop directly in OpenGL? There is nothing difficult about adding an extra small task to the active object framework. There are obviously changes to the way navigation controls are handled and potentially collision detection - minor. Plus, if you want to take advantage of some of the potential performance tweaks then you would need to tweak the renderer. If you want to take advantage of other benefitial techniques that flow out of floating origin there would be more changes to the application/rendering pipeline - such as in the object LOD algorithm. > > If you're proposing a new whole new rendering method, my second question > is how does such a rendering approach influence the representaion? For of objects? They are still represented in local object coords. > VOS, we're mainly concerned with representation in a way that can be > stored in a database and sent over the nework, rather than the specifics > of how it is rendered. Our assumption has been sector-based rendering > model, where there are lots of small sectors each with its own origin, U can keep this for the object application coordinate system anyway, but, as described above, one change happens at the point that you convert to single precision world coordinates. > with portals connecting sectors together. What you are proposing, if > its supposed to be origin-free(?), seems to require some representation > where objects are expressed relative to their neighbors, rather than > relative to the global coordinate system. No - in each user's display system active objects, only, are *relative to the user's avatar*, which happens to be at (0,0,0), and in terms of the application coordinates they are *also* relative to the avatar's application coordinate in the object system. The object system keeps track of moving objects and avatars in app coords relative to an absolute origin. >If that's the case, then how > do you manage sprites (avatars, etc) which are moving around constantly? As for description on active object framework above. > > I think we've fallen down the rabbit hole. Just don't be late for the party! :) chris _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
