5 ms·

Wow, I hadn’t imagined that because the coordinates are sent to the GPU as floats, that means triangles start voxelizing when you get further away from origin.

Wow, I hadn’t imagined that because the coordinates are sent to the GPU as floats, that means triangles start voxelizing when you get further away from origin. Seems like it could make an awesome shader-free animation if you translated the entire worlds position by a ridiculously large (increasing in value) float.

robertAngst 8y ago
Let me say that this topic made me realize how crazy some of the problems in programming are. I cant even imagine programming at FB and amazon scales.
- CyberDildonics 8y ago
  Numerical accuracy of floats and splitting up data into chunks that don't depend on each other are almost as different as any two problems can get.
  - workerIbe 8y ago
    I imagine someone used a float as an index, once.
    - __s 8y ago
      I've dealt with systems using floats as IDs in their DB. Better than when the monetary values were floats
    - CyberDildonics 8y ago
      Actually in the CG shader language you can index arrays with floats to get automatic linear interpolation, but I digress...
    - kibibu 8y ago
      Twitter used to use JavaScript numbers to represent various ids in their JSON API. These are, per the JavaScript spec, double-precision (64-bit) floating point numbers. You can only really use these to represent 53-bit integers, so they had to add string versions. (see https://developer.twitter.com/en/docs/basics/twitter-ids https://developer.twitter.com/en/docs/basics/twitter-ids)
Const-me 8y ago
> that means triangles start voxelizing when you get further away from origin They can in a few edge cases, but in most cases they don’t. Simplifying many things, to render a model, a game engine uploads 2 things to GPU: 1. Model’s vertex buffer + index buffer. The vertices are in mesh’s own coordinate system, and most 3D designers don’t design their meshes placed 100km away from origin. 2. A single 4x4 matrix, containing ( world * view * projection ) transform. World transforms the model from local to world coordinate system, view from world to camera related, and projection from camera related to 2D screen coordinates + depth. If you’re 200km far from origin, and are looking at a model near the camera, world transform will contain large values because you’re very far, view transform will also contain large values because camera’s also very far, but multiplied together they won’t have very large values, because model is near the camera. And if your model is very far from the camera, so the ( world * view * projection ) transform contains huge values, you won’t notice precision degradation, because the whole model will occupy a single pixel at most.
- andreareina 8y ago
  I thought that subtracting two large numbers to get a small one is one of the things that gives you precision issues in floats?
  - Const-me 8y ago
    You can use 64 bit floats for intermediate matrices. A matrix is just 16 numbers, quite fast to compute even with doubles. Also if you’ll do nothing and ignore precision issues, numerical errors made while calculating the WVP matrix won’t cause such voxelization of models. A model can be slightly misplaced, maybe jittery between frames, but the shape will stay fine.
    - andreareina 8y ago
      Thanks for the explanation!
- dahart 8y ago
  > They can in a few edge cases, but in most cases they don’t. [...] world transform will contain large values because you’re very far, view transform will also contain large values because camera’s also very far, but multiplied together they won’t have very large values, because model is near the camera. This is a good point; this problem is more prone to show up in a ray tracer than a rasterizer, since rasterizers have to apply the camera transform to the geometry, and ray tracers don't. It's pretty easy to see this problem while using Maya though. Z-buffer resolution in the editor drops off from the origin. We might see this issue crop up with increasing frequency as more and more people use GPUs for ray tracing...
dahart 8y ago
Note it's only voxely if you translate in all 3 dimensions. If you were far away in just x, but not y & z, you'd get a weird looking image that's slabby in x but detailed in y & z. It's cool that the pbrt renders hold up in voxel form, like the model's still solid and the shadows don't freak out or anything. The problem is fairly well known in film & games production. Artists, especially world designers, all know to model things near the origin and not far away because precision drops as you move away. They will also sometimes avoid modeling small things in small units like millimeters even though they might prefer it, because the units dictate how big your floats get, which in turn determines how fast you lose precision. Here's the voxel prediction chart: https://en.m.wikipedia.org/wiki/IEEE_754#/media/File%3AIEEE754.png https://en.m.wikipedia.org/wiki/IEEE_754#/media/File%3AIEEE7...
- Const-me 8y ago
  > They will also sometimes avoid modeling small things in small units like millimeters even though they might prefer it Scaling model from meters to mm only changes precision in model’s units, but the precision in real millimeters stays the same, so the units don’t matter. I think they avoid millimeters because down the art pipeline people who’ll use the models expect meters, e.g. to place the stuff in a metric world without extra scale involved.
  - dahart 8y ago
    You're right that normally a more important consideration for production is consistent units. The units do matter though, since the absolute float value is what determines your precision. The author of this article translated by 200k units, so the precision loss is relative in this case. But artists might need to translate something 100 meters, so their precision loss depends completely on their choice of units.
    - Const-me 8y ago
      > their precision loss depends completely on their choice of units. If an artist needs to translate a model 100 meters off center, and the model is in meters, the graph you’ve linked says the precision will be 10^(-5) model’s units, which is 0.01mm. If the same model is in mm, the graph says the precision for 100*1000 will be 10^(-2) model’s units, which is the same 0.01mm. As you see, it's independent on the choice of units.
white-flame 8y ago
There was a 3d engine a while back, focused on collision and pathing, which used 32-bit fixed point values for everything, citing this problem. If you divide out your game world size by the resolution a 32-bit number offers, it ends up being very practical. However, I don't know how overflow was handled for intermediates, if there was "enough" buffer around the outside of the world or if the math just worked out. Certainly 64-bit fixed point would be "sufficient".

robertAngst 8y ago

Let me say that this topic made me realize how crazy some of the problems in programming are. I cant even imagine programming at FB and amazon scales.

CyberDildonics 8y ago
Numerical accuracy of floats and splitting up data into chunks that don't depend on each other are almost as different as any two problems can get.
- workerIbe 8y ago
  I imagine someone used a float as an index, once.
  - __s 8y ago
    I've dealt with systems using floats as IDs in their DB. Better than when the monetary values were floats
  - CyberDildonics 8y ago
    Actually in the CG shader language you can index arrays with floats to get automatic linear interpolation, but I digress...
  - kibibu 8y ago
    Twitter used to use JavaScript numbers to represent various ids in their JSON API. These are, per the JavaScript spec, double-precision (64-bit) floating point numbers. You can only really use these to represent 53-bit integers, so they had to add string versions. (see https://developer.twitter.com/en/docs/basics/twitter-ids https://developer.twitter.com/en/docs/basics/twitter-ids)

Const-me 8y ago

> that means triangles start voxelizing when you get further away from origin They can in a few edge cases, but in most cases they don’t. Simplifying many things, to render a model, a game engine uploads 2 things to GPU: 1. Model’s vertex buffer + index buffer. The vertices are in mesh’s own coordinate system, and most 3D designers don’t design their meshes placed 100km away from origin. 2. A single 4x4 matrix, containing ( world * view * projection ) transform. World transforms the model from local to world coordinate system, view from world to camera related, and projection from camera related to 2D screen coordinates + depth. If you’re 200km far from origin, and are looking at a model near the camera, world transform will contain large values because you’re very far, view transform will also contain large values because camera’s also very far, but multiplied together they won’t have very large values, because model is near the camera. And if your model is very far from the camera, so the ( world * view * projection ) transform contains huge values, you won’t notice precision degradation, because the whole model will occupy a single pixel at most.

andreareina 8y ago
I thought that subtracting two large numbers to get a small one is one of the things that gives you precision issues in floats?
- Const-me 8y ago
  You can use 64 bit floats for intermediate matrices. A matrix is just 16 numbers, quite fast to compute even with doubles. Also if you’ll do nothing and ignore precision issues, numerical errors made while calculating the WVP matrix won’t cause such voxelization of models. A model can be slightly misplaced, maybe jittery between frames, but the shape will stay fine.
  - andreareina 8y ago
    Thanks for the explanation!
dahart 8y ago
> They can in a few edge cases, but in most cases they don’t. [...] world transform will contain large values because you’re very far, view transform will also contain large values because camera’s also very far, but multiplied together they won’t have very large values, because model is near the camera. This is a good point; this problem is more prone to show up in a ray tracer than a rasterizer, since rasterizers have to apply the camera transform to the geometry, and ray tracers don't. It's pretty easy to see this problem while using Maya though. Z-buffer resolution in the editor drops off from the origin. We might see this issue crop up with increasing frequency as more and more people use GPUs for ray tracing...

dahart 8y ago

Note it's only voxely if you translate in all 3 dimensions. If you were far away in just x, but not y & z, you'd get a weird looking image that's slabby in x but detailed in y & z. It's cool that the pbrt renders hold up in voxel form, like the model's still solid and the shadows don't freak out or anything. The problem is fairly well known in film & games production. Artists, especially world designers, all know to model things near the origin and not far away because precision drops as you move away. They will also sometimes avoid modeling small things in small units like millimeters even though they might prefer it, because the units dictate how big your floats get, which in turn determines how fast you lose precision. Here's the voxel prediction chart: https://en.m.wikipedia.org/wiki/IEEE_754#/media/File%3AIEEE754.png https://en.m.wikipedia.org/wiki/IEEE_754#/media/File%3AIEEE7...

Const-me 8y ago
> They will also sometimes avoid modeling small things in small units like millimeters even though they might prefer it Scaling model from meters to mm only changes precision in model’s units, but the precision in real millimeters stays the same, so the units don’t matter. I think they avoid millimeters because down the art pipeline people who’ll use the models expect meters, e.g. to place the stuff in a metric world without extra scale involved.
- dahart 8y ago
  You're right that normally a more important consideration for production is consistent units. The units do matter though, since the absolute float value is what determines your precision. The author of this article translated by 200k units, so the precision loss is relative in this case. But artists might need to translate something 100 meters, so their precision loss depends completely on their choice of units.
  - Const-me 8y ago
    > their precision loss depends completely on their choice of units. If an artist needs to translate a model 100 meters off center, and the model is in meters, the graph you’ve linked says the precision will be 10^(-5) model’s units, which is 0.01mm. If the same model is in mm, the graph says the precision for 100*1000 will be 10^(-2) model’s units, which is the same 0.01mm. As you see, it's independent on the choice of units.

white-flame 8y ago

There was a 3d engine a while back, focused on collision and pathing, which used 32-bit fixed point values for everything, citing this problem. If you divide out your game world size by the resolution a 32-bit number offers, it ends up being very practical. However, I don't know how overflow was handled for intermediates, if there was "enough" buffer around the outside of the world or if the math just worked out. Certainly 64-bit fixed point would be "sufficient".