Maximum size of a scene and float accuracy problem

Community Forums/General Help/Maximum size of a scene and float accuracy problem

RemiD(Posted 2014) [#1]
Hello, :)

Can someone explain what is the float accuracy problem in simple terms and what would be the maximum size of a scene (width#,height#,depth#) to prevent float accuracy problems ?

3000x3000x3000units is ok if i want to have a float precision of 0.1 ?

Thanks !


Floyd(Posted 2014) [#2]
Single precision floats are 32-bit values. The "value" part of this gives only 24-bit precision. The other bits tell the sign and where to put the decimal point ( really binary point ).

Notice that 2^10 is 1024, about a thousand, so ten bits are about like three decimal digits. 24 bits are about like 7 digits.

The big world problem is that there are still small things in the world, and large and small values don't play well together. Suppose you have, say, a camera at a location with x = 50. You move it by 1 and the new location has x = 51. Here I assume x is a float.

What if you had an enormous game world and you travel to Mars. Perhaps the camera now has x = 10000000. If you now try to move by 1 nothing happens. The value x = 10000001 is not possible, requiring eight digit accuracy.

There are various tricks to get around this, such as moving the world around the camera rather moving the camera in the world. You may not need them for your "3000 sized" example. That leaves room for about three digits of precision after the decimal point, so 3000.001 is possible.


Floyd(Posted 2014) [#3]
I probably should mention a little known Blitz3D quirk that can be very confusing if you are dealing with large numbers.

When Blitz3D prints a float, or converts it to a string, it rounds the value to six digit accuracy. That often leads to better looking output, printing 2.0 rather than something like 1.999999 which has resulted from the inevitable tiny accumulated errors.

But it also means that you don't see the actual value of large floats. Here is an example. The value of x# is first 5000000 and then 5000001. The true values are seen by converting to Int(x), but they both get rounded to 5000000 when Printed as floats.

x# = 5000000

Print
Print x
Print Int(x)

x = x + 1

Print
Print x
Print Int(x)

WaitKey



Matty(Posted 2014) [#4]
0.1 is fine for that size.


RemiD(Posted 2014) [#5]

You may not need them for your "3000 sized" example. That leaves room for about three digits of precision after the decimal point, so 3000.001 is possible.



0.1 is fine for that size.


Good ! Thanks for the infos :)

So if we want a one millimeter accuracy (0.001units), we can have a world as large as 9999units ? Because 0.001 uses 4 digits and 9999.999 uses 7 digits ?


Matty(Posted 2014) [#6]
That may be cutting it fine...


RemiD(Posted 2014) [#7]
Ok thanks.


*(Posted 2014) [#8]
Anything beyond -65535 to 65535 on x,y,z can cause zbuffer problems


Krischan(Posted 2014) [#9]
To bypass Zbuffer problems it helps to keep the camera "captured" in a small area around 0,0,0 and only move the world around the camera, run this demo and uncomment the described line after that to see the difference. This has been designed for very large space areas.

Homekeeping


Kryzon(Posted 2014) [#10]
I like this snippet to experience how float imprecision affects a scene. Use A and Z to move the camera.




RemiD(Posted 2014) [#11]
Try to replace 5000.0 by 1000.0 for "SPEED", then it is easier to see at which distance the drawing of shapes starts to be imprecise and they appear to shake.