Why floating point for coordinates?

[EasyRaider]

Excuse my ignorance, but...

It seems to me that in a large world, floating point gives excessive precision for vertices near the origin, but may not have enough precision at the outer areas. With integers you would have the same precision everywhere.

So why does OpenGL, graphics hardware and whatnot use floats?

[Ostsol]

What if you want the texture to be repeated multiple times across the polygon? In order for this to work one must be able to assign a texture coordinate that is greater than 1. Also, keep in mind that current integer types supported in hardware are very low in precision. NVidia's FX12 provides 10 bits of mantissa, while ATI's FP24 (minimum for texture addressing in PS2.0) provides 15 (or 16?).

[EasyRaider]

What if you want the texture to be repeated multiple times across the polygon? In order for this to work one must be able to assign a texture coordinate that is greater than 1.

Hmm, that kind of makes sense. I didn't think about texture coordinates.

Also, keep in mind that current integer types supported in hardware are very low in precision.

Well, I was wondering why hardware and APIs weren't designed to use integers in the first place.

[arjan de lumens]

Some reasons not to use integers for e.g. vertex coordinates:
Divisions, in particular perspective divisions, are not very well-behaved with integers or fixed-point numbers (overflow, rounding errors). Integer divisions are also inherently much slower than some of the methods that can be used for approximated FP division in hardware.
Overflow behaviour. With integers, too large values result in saturation (16-bit integer example: 30000+30000=32767) or value wraparound (16-bit integer example again: 30000+30000=-5536). If this happens to vertex coordinates, you won't be able to recognize your 3d model.
With integers, small numbers will result in rounding errors that are quite large compared to the numbers themselves - if you try to multiply or divide anything by such a number, you will get large absolute errors or even divides by zero.

In general, it is just easier to do most sorts of calculations (in particular for 3d graphics/physics modelling) with quantities that behave like ordinary real numbers; floating-point numbers have behaviour that, for practical purposes, lies much closer to that of real numbers than integers/fixed-point numbers do.

These arguments apply mostly to geometry/T&L calculations and don't apply to the same degree to e.g. color blending or input vertex/texture map data, where limited range and rounding errors aren't such intractable problems.

[Xmas]

What if you want the texture to be repeated multiple times across the polygon? In order for this to work one must be able to assign a texture coordinate that is greater than 1. Also, keep in mind that current integer types supported in hardware are very low in precision. NVidia's FX12 provides 10 bits of mantissa, while ATI's FP24 (minimum for texture addressing in PS2.0) provides 15 (or 16?).
But that's no argument against integers (or fixed point) in general. You could also use high precision fixed point instead.


An interesting thought, EasyRaider, I have to say. It is indeed not quite obvious why a non-uniform distribution would be better than a uniform distribution in space.
The main reason for using floats, I think, are transformations and the different spaces.
No matter how big the range of your data type is, you're most likely not going to fully use it in your models in model space. And if you only use a small part of it, you're better off with floats, since they're more precise at small numbers. And even if you used the full range of fixed point numbers for your models, you'd have to scale them when transforming to world space, and multiplying with small fixed point numbers kills your precision.

Transformations need lots of multiplications, and everything in your view will be close to the origin when you transform to view space. Floats are better suited for those needs.

[EasyRaider]

Just saying thanks for the replies!

[Humus]

There's absolutely nothing keeping you from submitting vertices as ints.

glVertexPointer(3, GL_INT, ...); ..... perfectly valid. Though it may not be accelerated by all hardware.

[Simon F]

Excuse my ignorance, but...

It seems to me that in a large world, floating point gives excessive precision for vertices near the origin, but may not have enough precision at the outer areas. With integers you would have the same precision everywhere.


Objects are generally modelled around their own local origins and then translated to the appropiate positions (relative to the camera). Thus each has sufficiently high precision when it is close to the viewer (i.e. a neglibible translation (assuming the application's been coded sensibly!!!)). When the object is off in the distance, you then don't need much absolute precision. Relative precision, OTOH, stays roughly constant, which is what you usually want.

If you used integers/fixed point, you'd end up with insufficient accuracy up-close while wasting bits (or running out of range!) when the object is far away. EG if you want Mountain 1 to be in front of Mountain 2 it doesn't matter if the placing is out by a few millimetres, but it would be catastrophic if you hit MAX_INT!

[EasyRaider]

Objects are generally modelled around their own local origins and then translated to the appropiate positions (relative to the camera). Thus each has sufficiently high precision when it is close to the viewer (i.e. a neglibible translation (assuming the application's been coded sensibly!!!)). When the object is off in the distance, you then don't need much absolute precision. Relative precision, OTOH, stays roughly constant, which is what you usually want.


I see now that floating point makes more sense in view space. I was more thinking object placement while editing a level you can move to the more distant parts of. If you can only see the central parts up close, floating point is better again.


If you used integers/fixed point, you'd end up with insufficient accuracy up-close while wasting bits (or running out of range!) when the object is far away. EG if you want Mountain 1 to be in front of Mountain 2 it doesn't matter if the placing is out by a few millimetres, but it would be catastrophic if you hit MAX_INT!

I don't think accuracy or range would be a problem for storing coordinates. With 32 bits you could have 1/65 mm precision with a 65 km world (approximately).

[NeARAZ]

I see now that floating point makes more sense in view space. I was more thinking object placement while editing a level you can move to the more distant parts of. If you can only see the central parts up close, floating point is better again.
Quite many are actually using this - for rendering, everything gets into floats (for obvious reasons), but some things (mainly only object positions) are kept and tracked on "higher" data type - mostly it's 64 bit integers, less often it's double precision floats. With plain floats and "normal" game scenarios you start losing precision just after a few kilometers...
64 bit ints have a nice property that nearly all hardware/compilers support them (eg. PS2), and for those that don't support that in hardware, it isn't quite a loss, as you most often only need addition for coordinates :) The obtained range/precision is kinda huge - IIRC, it's like millimeter precision for distances up to Solar system size.
Double precision floats are poorly supported or not supported at all (again: PS2), hence not-so-widespead use.

[EasyRaider]

Quite many are actually using this - for rendering, everything gets into floats (for obvious reasons), but some things (mainly only object positions) are kept and tracked on "higher" data type - mostly it's 64 bit integers, less often it's double precision floats. With plain floats and "normal" game scenarios you start losing precision just after a few kilometers...


I assumed this was avoided because of the extra int to float conversions. Surely it's acceptable if you need the precision. I'm having a hard time imagining what kind of games would need more than 32 bit integer precision, though. That's significantly finer resolution than the diameter of a human hair over a 65 km area.

[NeARAZ]

I assumed this was avoided because of the extra int to float conversions. Surely it's acceptable if you need the precision.
Hey - you only need to do it for object positions - hence 3 YourSuperTypeToFloat conversions per object. That's really cheap, compared to all the other things that are happening :)
I'm having a hard time imagining what kind of games would need more than 32 bit integer precision, though.
I don't know either, but probably there exist some :) Some discussion on this subject was at gd-algorithms list a while ago: http://sourceforge.net/mailarchive/forum.php?forum_id=6188&max_rows=25&style=flat&viewmonth=200307&viewday=25 (look for "big fat things"). And I think at GDC2003, in one of presentations about Dungeon Siege, they've mentioned something similar.

[Simon F]

If you used integers/fixed point, you'd end up with insufficient accuracy up-close while wasting bits (or running out of range!) when the object is far away. EG if you want Mountain 1 to be in front of Mountain 2 it doesn't matter if the placing is out by a few millimetres, but it would be catastrophic if you hit MAX_INT!

I don't think accuracy or range would be a problem for storing coordinates. With 32 bits you could have 1/65 mm precision with a 65 km world (approximately).
I see your point, but all those bits are probably not really useable. With integer, you'd need to devote a certain number of bits just for 'overflow' and 'underflow' when doing intermediate operations (i.e. multiplications and additions) in, say, transformations. Balancing the number of bits for fraction and overflow is a complete pain-in-the-backside. Admittedly, you can have accuracy concerns with floating-point if you mess up the order of operations but I don't think that it's nearly as much of a concern.

The other this is I wonder if you'd get "full" 32 bit integer accuracy in a chip. Although addition is 'cheap', IIRC, an integer 32bit multiply is more expensive than the 32bit floating point version, since the expensive part, the n-bit*n-bit mul, is an O(n^2)ish operation. In FP, n~23 as opposed to ~32 with an int.