44 ms·

No, this is a real problem. Lack of precision of floating point is something that comes up often in game development, now that levels are larger. If you have

No, this is a real problem. Lack of precision of floating point is something that comes up often in game development, now that levels are larger. If you have a level that is 1-2km across, and you store all your positions in floats, then you will notice that animations for instance are quantized. Near the world origin, everything is fine, but far from the world origin individual vertices in the character and props will become quantized to the smallest representable delta. This results in atrocious geometric fizzing and popping.

ubasu 16y ago
Ah, OK, I come from a different background. But this issue of different precisions at different magnitudes is also well-known, and is made clear when studying the definition of floating point. Others have mentioned the "obvious" solution of using relative coordinates, but apparently that has some issues also.
stcredzero 16y ago
Yeah. I've also tried a galactic simulation game and ran into the limitations of floats. 32 bit floats only give you a usable resolution of 1 in 100000 for global coords. Even doubles are too small. This becomes an issue if you want to zoom from local ship view out to the local planetary body. You end up having to do goofy things like make a scaled billboard out of the nearby planets and place them far enough away that nobody notices.
- marshray 16y ago
  I think we can conclude that galactic simulation games are probably a special case for which 128 bit integer coordinates make sense. Once you've subtracted out the offset of your spaceship though, everything you view from there is easier done with float or double.
  - stcredzero 16y ago
    Of course, in particular since in most cases, one must communicate with the GPU using 32 bit floats. (I'm going to guess that this is changing, though.)
    - marshray 16y ago
      Yes, the recent generation of Nvidia GPUs has added hardware support for doubles. This was done to be able to sell hardware for use in financial analysis rather than any use in graphics.
      - stcredzero 16y ago
        The Panda3D Python library uses double-precision floats, due to it's being a Python library. Currently, these are converted to 32 bit floats which are then sent to the GPU.
palish 16y ago
I think you're referring to bone animation. With bone animation, there are 4 "weights" per vertex. Each weight refers to a specific matrix in a "bone matrix palette" (array of matrices). Typically, it's performed as: // start in local space. Deform by bone matrices. float3 pos = 0; for ( int i = 0; i < 4; i++ ) pos += vtx.boneWeight[i] * ( vtx.pos * boneMats[ vtx.boneIdx[i] ] ); // transform from local space to post-projection space. return modelViewProjMatrix * float4( pos.xyz, 1.0 ); In other words, a model is deformed (animated) first, then transformed into worldspace. ------------------------------------------------------ You may have done this instead: // transform from local space into world space. float3 pos = modelMatrix * vtx.pos; // deform by bone matrices. for ( int i = 0; i < 4; i++ ) pos += vtx.boneWeight[i] * ( vtx.pos * boneMats[ vtx.boneIdx[i] ] ); // transform from world space into post-projection space. return viewProjMatrix * float4( pos.xyz, 1.0 ); This will exhibit the quantization errors you mentioned, and is correctable by re-ordering the operations.
- JabavuAdams 16y ago
  Thanks for the detailed answer, but no, it's still a problem. I mentioned animation, but actually it would happen without animation. The problem is subtracting two very large numbers. This happens when you calculate the camera-relative offset of a vert. From the Tom Forsyth article I linked in another reply: > The most obvious place this happens in games is when you're storing world coodinates in standard float32s, and two objects get a decent way from the origin. The first thing you do in rendering is to subtract the camera's position from each object's position, and then send that all the way down the rendering pipeline. The rest all works fine, because everything is relative to the camera, it's that first subtraction that is the problem. For example, getting only six decimal digits of precision, if you're 10km from the origin (London is easily over 20km across), you'll only get about 1cm accuracy. Which doesn't sound that bad in a static screenshot, but as soon as things start moving, you can easily see this horrible jerkiness and quantisation. >By the way, some rendering code doesn't even do that subtraction. Canonically, you bake that subtraction into the offset of your "camera matrix" in your rendering code and let the GPU do it. This is madness - GPUs have even less precision than full IEEE754 floating-point, and you're doing a whole bunch of vector math before you finally do the subtraction. So your precision problems are going to be a lot worse. Best all round if you just subtract camera position from object position on the CPU before it gets anywhere near a GPU.
deleted 16y ago
[deleted]

ubasu 16y ago

Ah, OK, I come from a different background. But this issue of different precisions at different magnitudes is also well-known, and is made clear when studying the definition of floating point. Others have mentioned the "obvious" solution of using relative coordinates, but apparently that has some issues also.

stcredzero 16y ago

Yeah. I've also tried a galactic simulation game and ran into the limitations of floats. 32 bit floats only give you a usable resolution of 1 in 100000 for global coords. Even doubles are too small. This becomes an issue if you want to zoom from local ship view out to the local planetary body. You end up having to do goofy things like make a scaled billboard out of the nearby planets and place them far enough away that nobody notices.

marshray 16y ago
I think we can conclude that galactic simulation games are probably a special case for which 128 bit integer coordinates make sense. Once you've subtracted out the offset of your spaceship though, everything you view from there is easier done with float or double.
- stcredzero 16y ago
  Of course, in particular since in most cases, one must communicate with the GPU using 32 bit floats. (I'm going to guess that this is changing, though.)
  - marshray 16y ago
    Yes, the recent generation of Nvidia GPUs has added hardware support for doubles. This was done to be able to sell hardware for use in financial analysis rather than any use in graphics.
    - stcredzero 16y ago
      The Panda3D Python library uses double-precision floats, due to it's being a Python library. Currently, these are converted to 32 bit floats which are then sent to the GPU.

palish 16y ago

I think you're referring to bone animation. With bone animation, there are 4 "weights" per vertex. Each weight refers to a specific matrix in a "bone matrix palette" (array of matrices). Typically, it's performed as: // start in local space. Deform by bone matrices. float3 pos = 0; for ( int i = 0; i < 4; i++ ) pos += vtx.boneWeight[i] * ( vtx.pos * boneMats[ vtx.boneIdx[i] ] ); // transform from local space to post-projection space. return modelViewProjMatrix * float4( pos.xyz, 1.0 ); In other words, a model is deformed (animated) first, then transformed into worldspace. ------------------------------------------------------ You may have done this instead: // transform from local space into world space. float3 pos = modelMatrix * vtx.pos; // deform by bone matrices. for ( int i = 0; i < 4; i++ ) pos += vtx.boneWeight[i] * ( vtx.pos * boneMats[ vtx.boneIdx[i] ] ); // transform from world space into post-projection space. return viewProjMatrix * float4( pos.xyz, 1.0 ); This will exhibit the quantization errors you mentioned, and is correctable by re-ordering the operations.

JabavuAdams 16y ago
Thanks for the detailed answer, but no, it's still a problem. I mentioned animation, but actually it would happen without animation. The problem is subtracting two very large numbers. This happens when you calculate the camera-relative offset of a vert. From the Tom Forsyth article I linked in another reply: > The most obvious place this happens in games is when you're storing world coodinates in standard float32s, and two objects get a decent way from the origin. The first thing you do in rendering is to subtract the camera's position from each object's position, and then send that all the way down the rendering pipeline. The rest all works fine, because everything is relative to the camera, it's that first subtraction that is the problem. For example, getting only six decimal digits of precision, if you're 10km from the origin (London is easily over 20km across), you'll only get about 1cm accuracy. Which doesn't sound that bad in a static screenshot, but as soon as things start moving, you can easily see this horrible jerkiness and quantisation. >By the way, some rendering code doesn't even do that subtraction. Canonically, you bake that subtraction into the offset of your "camera matrix" in your rendering code and let the GPU do it. This is madness - GPUs have even less precision than full IEEE754 floating-point, and you're doing a whole bunch of vector math before you finally do the subtraction. So your precision problems are going to be a lot worse. Best all round if you just subtract camera position from object position on the CPU before it gets anywhere near a GPU.

deleted 16y ago

[deleted]