Precision Errors and Streaming

#1 well, if you make your models 1/10 scale, your terrain, in practice, becomes 10 times larger, so 8km becomes 80km, by scale....

#2 Thanks for the suggestion however it seems like when you scale down the precision errors move to the other side of the scale.

#3 The way T3D does its matrix stack magic encourages precision errors with the rendering at pretty low numbers. Get further than around 4000 units from the origin, using the normal metre scale, and you'll see your avatar begin to jitter slightly. Scaling everything down by a factor of 10 simply means that you see this jitter 400 units from the origin.

The biggest contribution to the precision errors is the way that the matrices are stacked up. The best precision would be obtained by assuming that the camera position is always (0,0,0) and rendering all objects relative to that. What T3D does is to send the camera transform to the graphics pipeline, then multiply that by the objects transform. For objects close to a camera which is far from the origin, the precision errors in the two matrices get multiplied and become significant at pretty small coordinates which many other engines can handle without issue.

Things that should never be subject to coordinate precision issues are affected in T3D. The skybox for example, is always a fixed size cube rendered at a fixed distance from the camera. There's no reason for it to show precision errors. BUT, get further than around 20000 units from the origin, and the sky will start to jitter because its position is being multiplied by the camera matrix which has accumulated lots of error by that point.

#4 Thanks for the easy to understand explanation, Guy.

#5 I wonder if some of that could be knocked off by clearing the camera matrix periodically (once per frame would be optimal) to avoid constantly multiplying by erroneous data. Heck, maybe they already do this - I haven't looked at that.

I also wonder how much trouble it would be to turn that upside down and move the scene instead of the camera. Tribes set the stage for this issue I think - FPS meant to be played in a relatively (by flight sim standards) small area.

#6 Yeah, what you really want is for things close to the camera to be given the best chance of rendering with the highest precision instead of the way it currently is which is to give things closest to the origin the best precision.
You're unlikely to notice errors in rendering for something that is far away from you.

Also, there are 2 different facets to this. There's the precision of the rendering pipeline which gives visual glitches, but there's also the precision applied to physics calculations. Solving the first issue could be done by re-thinking the way the camera transform is applied. Solving the second isn't really possible without converting to doubles (which doesnt actually solve anything, it just pushes things out a bit further), using fixed point, or implementing a paged coordinate system.

#7 Thanks everyone for the comments. It seems like the problems doom the majority of the engines around. It would be great to see some type of resolution for this engine. I think that would bring in a LOT of users wanting to make simulation applications and large scale games.

@ Guy - The paged coordinate system seeems to be a popular method from the research that I have done. Have you tried to implement this into Torque.

#8 Not tried it myself, but a few others have attempted it. I think it's pretty doable for a single player game, but there are a load of hurdles that you'd have to jump for a multiplayer game.

#9 Sounds good. Single player is all that I am interested in.