Overcoming Floating Point Precision Errors!

As any game developer knows, there is a limit to how big things can be. When it comes to any current PC/console, there is a limit to the number value in a floating point. This can lead to many issues such as z-fighting, animation glitchs, and map limits.

Robert Wooden, Blogger

April 13, 2015

5 Min Read

As many games have limited themselves to working within the boundaries of floating point precision, their is solutions that can overcome those boundaries. The one that will be discussed here is a concept you may be familiar with if you have ever found yourself watching 'Futurama'. In the show the spaceship that the team uses is required to travel great distances in a small amount of time. The spaceship's concept is not to move the spaceship around the universe, but rather move the universe around the spaceship.

Grasp this if you will, all games no matter which engine, are centered around a point in world space (x, y, z) or (0, 0, 0). The problem that arrises if a player was to travel to far away from the (0, 0, 0) and lets say was at (100000.05, 0, 0) the 100000.05 would round because all current PC/consoles can only run through so many digits before it is forced to round. So the 100000.05 becomes 100000.1, this will cause problems such as glitching animations, unwated vertex displacement, and image flickers.

What our team at 7DE Studios did for our game Omni Point was use the 'Futurama' concept. This also comes with its own sets of problems, such as destroying any functionality of a rigid body system. So be warned the this concept will lead to a lot of needed Trigonometry calculations in the future. Our team did just that, we made our own rigidbody system. Using a 'Universal Anchor' to parent all things in the solar system, we took calculations from the player and used those to control things such as gravity, walking, jumping, and collision. Along with locking the player in at the point (0, 0, 0) this system has given us more then we expected.

If you choose this route and wish to create a multiplayer game, their will be networking problems. Though that can also be overcome. Instead of calculating player/vehicle position based upon world space, you will need to base each player/vehicle based upon local space of your 'Universal Anchor'. This will allow you to communicate your position as well as recieve other players positions with relative ease.

Choosing this path will also require you to rewrite your own gravity. Seeing as how our project was requiring this regardless, we found it relatively unchallenging. A solution could be to first find the direction of your gravity source IE a planetoid or world space down. Then using the direction and ray's find the distance from you to the surface of the planetoid. With our needs we wanted distance and mass based gravity, so depending on the distance we would translate our transform in the direction of the planetoid by mass^2/distance^2. As we did not have a rigidbody system to no longer detect collisions we also would have to limit the descent once the object came into contact with a model/map, ray's can be your friends. Of course keep in mind that in order to move your character down, you must move the universe up so all your calculations will have to be reflected in reverse to your 'Universal Anchor'.

Another great challenge was simple movement for our new rigidbody system. This is where the Trigonometry comes into play. In order to keep smooth movement a player/vehicle should be translated across the cross product of the surface normal and the player/vehicle right direction. This gives a accurate angle at which to translate the player/vehicle. Using this the player/vehicle can smoothly be moved along the surface without any jittering.

As for alignment its relatively simple for players and npc as you can align them to the world up or as in our case gravity up. Though for vehicles its suggested to get the cross product between your left wheels and right wheels and cross product the two, and use that angle to align with your vehicle up. This allows all your wheels to make the appropriate spot on the surface.

Now let's move along to another problem you will experience due to floating point precision errors. Z-fighting, it occurs due to two models having a similiar vertex coordinate as each other. A example problem that we have experienced ourselves is, when looking from a planets surface to another planet surface any point at which our spherical ocean meet the shoreline of our planet surface their would be flickering. Where they both had been rounded to a exzact matching number such as 100000.1 they computer was unaware of which to show so it would switch between the two options it had.

A way that this can be overcome is to use multiple camera's and combine the image into one. This allows to shorten the range at which the visible vertex needs to round. We ourselves used 4 camera's one near from range .03 to 1, near-mid range from 1 to 20, mid range from 20 to 1000, far from 1000 - 250,000. Anything beyond this point is small enough to not be visible even to the naked human eye. With this we are now able to see from planet to planet all realtime and not through the illusion of a skybox.

While we have now overcome floating point precision problems and moved on to other things such as procedurally generated voxel planets we hope that this in some way may help any other teams looking to obliterate the invisible wall. If you would like to learn of our current progress on procedurally generated voxel planets please visit us at our website or fanpage listed below. Also for anyone that may be interested in supporting our project we also have released a kickstarter.