32/64-bit Floating Point Numbers

[Elof Valantor]

I have a newbie-ish question to ask. It's not strictly an issue with Irrlicht, but it does apply to Irrlicht.

Floating point numbers (f32, u32)... the way I understand it is a 32-bit floating point number has a sign bit, 8 exponent bits, a hidden bit and 23 bits used for the actual digits. That equates to 7 digits with a decimal point somewhere amongst them (and a x10 to the power of number). Is that correct?

Now if I had a program that was going to be moving things around on a very wide scale (say metres to terametres) I would need 14 digits of precision. 64-bit floating points would accommodate that (with 52 bits for the digits giving 16 digits of precision).

A lot of Irrlichts functions that you would use to manipulate the position of something (rotations, etc) use f32... so I suppose my question is, is there some way of using f64/double instead to maintain the precision?

[Radikalizm]

I have a newbie-ish question to ask. It's not strictly an issue with Irrlicht, but it does apply to Irrlicht.

Floating point numbers (f32, u32)... the way I understand it is a 32-bit floating point number has a sign bit, 8 exponent bits, a hidden bit and 23 bits used for the actual digits. That equates to 7 digits with a decimal point somewhere amongst them (and a x10 to the power of number). Is that correct?

Now if I had a program that was going to be moving things around on a very wide scale (say metres to terametres) I would need 14 digits of precision. 64-bit floating points would accommodate that (with 52 bits for the digits giving 16 digits of precision).

A lot of Irrlichts functions that you would use to manipulate the position of something (rotations, etc) use f32... so I suppose my question is, is there some way of using f64/double instead to maintain the precision?

What probability is there of you actually having to manage objects over distances of terameters?
Precision of object placement can be completely managed by a decent world-unit definition and by local coordinates based on local origin points, there's no need to slow down your calculations by using 64-bit precision

[bitplane]

You can't just dump objects like this into the scene graph anyway, your z-buffer will fail way before you run out of floating point precision, you'll need to render things in a custom order and separate your visual and physical representations.

In the granddaddy of enormous space shooters, Elite, and its sequel Frontier, Braben used a combination of a logarithmic scale and a local coordinate system relative to the nearest large mass. In Elite this was done using 8-bit integers, and 16-bit integers in Frontier.

In general though, the reason why most modern 3rd person RPG games don't have an environment larger than about 16km^2 is most likely due to the limitation of 32-bit floats.

[gerdb]

hi,

you could use opengl as device context

there are function headers for double values, e.g. glvertex3/4d,

but i dont know if there are any precision differences to floats

anyway as bitplane said the graphical visualization does not need doubles

so separate doc (64 bit data) and view ( 32bit graphing),

the human eye dont see any difference to float positions, because of the small screen raster

more interesting are 64bit/128bit colors, there will be noticeable differences to 32bit, assumed you have a screen capable of displaying these colorspaces.

see video::ECF_A32R32G32B32

mfg/cu