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.
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.
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...
[1] https://www.gamasutra.com/view/feature/131393/a_realtime_pro...
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.
Unless the field of view is sufficiently narrow?
Good catch.
If the projection matrix is extremely non uniform (e.g. orthographic with very large Z size and very small XY size, or perspective one with FOV angle very close to zero), the described problem can still be encountered.
But I did mentioned “a few edge cases”, this is one of them.
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%3AIEEE7...
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.
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.
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.
Edit: this translates to 320m if you want 0.01mm precision.
The number's the roughly the same even if you'll model in km or imperial units.
Certainly 64-bit fixed point would be "sufficient".
I cant even imagine programming at FB and amazon scales.
(see https://developer.twitter.com/en/docs/basics/twitter-ids)