I'm working on 3d planet engine with terrain. Now I have quadtree planet with SRTM terrain. It's work fine but exept one. Camera begins rumble-tumble(jitter) :) on the low altitude(close to the zero altitude).
Here is a my video I've made this...
Could you help me to head me right way please))
Thanks.
looks like "float" is not enough for your plane physics. try if "double" solves the problem.
looks like "float" is not enough for your plane physics. try if "double" solves the problem.
What Krypt0n says: Lack of precision usually manifests this way. When you zoom up close, you magnify this error, and it is seen as jittering, or jumping around. (Anyone hearing 'House of Pain' in their head now?)
Small errors becomes big, and with computers that store finite information (finite precision), you will always have small rounding errors. It is just a matter of finding a tolerable level of error, which may be changing from 'float' to 'double'. If you zoom deep enough, you will end up having trouble even with doubles, but with proper constraints, you can avoid that, like for instance not allowing to go to exactly zero altitude when the ground is at zero. (You don't want to be able to zoom in to see the atoms that the ground is made of...) You have a head attached to your body, for instance, that elevates you a bit from the ground.
Another way to account for rounding errors, is how you define your units, wether you define one meter to be 1 unit, or 100 units, for instance. Bigger values is less prone to be affected like this than smaller values, but bigger values may limit the size of your world, so it is a trade-off.
EDIT: Thinking about it, far too big values may also be a problem, in that it will require a really small value to change the position in a smooth way, so there is probably a 'sweet spot' somewhere in the centre of the two extremes.
I think the problem are not the values for rendering, because it's stable when he just moves around, it rather seems like the it only jitters when physics is involved, which might be due to very fine time steps and some squaring etc. you might do because of e=m*c^2 :)
switching to doubles is usually not a great solution, adjusting ranges is better, but in case of a plane simulation, where you simulate just a few units and it's a really big space with maybe detailed movement (e.g. rolling slowly on the ground), double might be ok'ish.
and I'm not 100% sure it's really the problem either, so I suggested to try it out, sorry if there was no detailed explanation 'why'. I was rather really trying to remote debug it. maybe it won't help.
Thank for your reasonable answers. I use double values, but GPU is foat32. You know GoogleEarth it's huge! But there is nothing about jittering close to the terrain...Now I m thinking about each quad of the terrain quadtree that have to be rendererd by their own view matrix...
Floats have better precision on small values. One solution is to divide your terrain into tiles, and center vertices for each tile to 0. Each tile have their own coordinate frame and will require separate model matrices. When the camera is close to a tile, the vertices in camera space will have small values and precision should be acceptable. At greater camera distance the precision will get worse, but less noticeable. The trick then is to do all matrix calculations with doubles, and only convert to single precision in the end. Do not send model and view matrices as two separate matrices to the shader and multiply in the shader. Calculate model-view matrix using double precision on the CPU, then upload final matrix to shader as single precision.
QFE. I have to do exactly this for rendering anywhere close to planetary scale.
Also keep in mind that one has to do a similar partitioning for physics, or it suffers from the same floating-point accuracy issues.
