3 ms·
> 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 thi
by Const-me 9y 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 9y agoI 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 9y agoYou 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 9y agoThanks for the explanation!
- dahart 9y 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...
- 1wd 9y agoAnd the problem is old and well known e.g. by game developers. For example "A Real-Time Procedural Universe, Part Three: Matters of Scale" by Sean O'Neil from 2002 [1] discusses rendering problems at planetary, star-system and even galaxy scale, including Z-buffer precision and various options regarding 32-bit float vs. 64-bit double vs. 128-bit fixed-point integer + float offsets (for vertex coordinates of a mesh) etc. [1] https://www.gamasutra.com/view/feature/131393/a_realtime_procedural_universe_.php?print=1 https://www.gamasutra.com/view/feature/131393/a_realtime_pro...
- usefulcat 9y ago> 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. Unless the field of view is sufficiently narrow?
- Const-me 9y ago> 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.