Hacker News Reader

Comment by amelius | Hacker News Reader

Why would you even use floats when dealing with geometric data? With floats, coordinates near the origin have more precision than other coordinates, and this usually doesn't make sense because the choice of the origin is just a convention. Better to use fixed-point numbers for geometric data, so all coordinates have the same precision.

View on HN

Geometry is only a part of the problem; much more compute goes into lighting and textures. Also scenes rarely span enough orders of magnitude of physical scale that the differences in precision matter (except may when using FP16). Finally, you probably can accept reduced precision for faraway objects (usually the camera is at the origin).

This is true, but nobody likes working in fixed-point because it's inconvenient and languages don't have good support for it. (I think this is a language problem, not an argument for floats.)

You can workaround this by doing most of your math in local coordinate spaces though, so it's fine for games.

Is this where I post the code I wrote twenty-five years ago to do 16-bit fixed-point 3D rendering? https://github.com/pjc50/ancient-3d-for-turboc

The target architecture was a 33MHz 486 PC running in "real" (ie sixteen-bit) mode. While hardware floating point was sometimes available (DX systems) it was quite slow.

> Why would you even use floats when dealing with geometric data?

Perf? Which hardware does have support for math on fixed-integers? (e.g. sqrt, inverse sqrt, ray triangle intersection accelerations, etc.)

Didnt Quake 1 use fixed-point 256x256 vertex meshes for all the 3d models? with morphing instead of skeletal animations on top of that resulting in funky wobbly artefacts.

IIRC the vertex coordinates were single precision floats (at least that's what my 24 year old pascal code uses :-) ) that were then additionally scaled and translated (so the center point was at the floor). What made it wobbly was the animation technique used. It had several animation sequences (walking, running, dying, etc..), each with multiple frame specifying the coordinates of a fixed number of 3D vertices. The indices of those vertices corresponded to the indices in a list of 2D vertices giving coordinated into a single 2D texture. IIRC Animation between frames used linear interpolation.

Reply on news.ycombinator.com