5 ms·

This displays a fundamental lack of understanding of how floating point works. In particular, we are concerned about the accuracy of the floating point represen

by ubasu 15y ago

This displays a fundamental lack of understanding of how floating point works. In particular, we are concerned about the accuracy of the floating point representation, which is characterized by the machine precision. Typically, single-precision has 8 digit accuracy, while double-precision has 16-digit accuracy. Furthermore, we don't use 128-bit representations because they are slow for numerical computation, because we need more trips through the smaller-sized bus. See http://en.wikipedia.org/wiki/Floating_point http://en.wikipedia.org/wiki/Floating_point

JabavuAdams 15y ago
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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y ago
  [deleted]
aidenn0 15y ago
This article understands how floating point works. People using floating point often have a fundamental lack of understanding how floating point works. Floating point numbers are a leaky abstraction that exist only for performance optimization. Using floats as a default is an example of premature optimization.
- eru 15y ago
  The default should be rationals or even algebraic numbers?
- sharpneli 15y ago
  Also people writing floating point off because it does not fit well into situations where you have evenly divide something (e.g galaxy into picometer sized voxels) show fundamental lack of understanding how floating point works. One of the biggest reasons floats are used is that error propagation is much better when floats are used in many numerical algorithms. In a nutshell. If you want coordinates in galaxy use fixed point (or in game level). If you want to calculate values of hyperbolic trigonometric functions or whatever use floats.
- cdavid 15y ago
  Floating point do not exist for performance optimization - they were much slower than fixed points at first (not anymore on general purpose CPU). The point of floating point is to have the same accuracy (number of meaningful digits) independently of its amplitude, but that means that their precision is indeed not uniform (near 1, 64 bits float has a precision of ~ 1e-16, near 100000, near 1e-11, etc...). In that sense, saying that floating point suck shows a lack of knowledge about them, since the observed behavior by the OP is exactly what they have been designed for. If you want the same precision independently of the amplitude, then indeed fixed point may be what you want. But you have to keep in mind that it will give you a lot of other issues as well.

by ubasu 15y ago

JabavuAdams 15y ago

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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y ago
[deleted]

aidenn0 15y ago

This article understands how floating point works. People using floating point often have a fundamental lack of understanding how floating point works. Floating point numbers are a leaky abstraction that exist only for performance optimization. Using floats as a default is an example of premature optimization.

eru 15y ago
The default should be rationals or even algebraic numbers?
sharpneli 15y ago
Also people writing floating point off because it does not fit well into situations where you have evenly divide something (e.g galaxy into picometer sized voxels) show fundamental lack of understanding how floating point works. One of the biggest reasons floats are used is that error propagation is much better when floats are used in many numerical algorithms. In a nutshell. If you want coordinates in galaxy use fixed point (or in game level). If you want to calculate values of hyperbolic trigonometric functions or whatever use floats.
cdavid 15y ago
Floating point do not exist for performance optimization - they were much slower than fixed points at first (not anymore on general purpose CPU). The point of floating point is to have the same accuracy (number of meaningful digits) independently of its amplitude, but that means that their precision is indeed not uniform (near 1, 64 bits float has a precision of ~ 1e-16, near 100000, near 1e-11, etc...). In that sense, saying that floating point suck shows a lack of knowledge about them, since the observed behavior by the OP is exactly what they have been designed for. If you want the same precision independently of the amplitude, then indeed fixed point may be what you want. But you have to keep in mind that it will give you a lot of other issues as well.