• Advertisement
Sign in to follow this  

[Theory]Inacurate large floating point values at large game worlds

This topic is 3291 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well, I have yet to reach to the point where it matters in my games, but I was thinking: As you all know, floating point types are composed from two sections(3 if you count the sign): base and exponent. The lower the exponent, the better the precision, because you can represent more digits after the dot. However, lowering the exponent also decreases the size of the range of possible values you can represent, because the number of digits in base is limited, and every digit you add to the right side of the number must be taken from the left side of the number. So this is my question: in large game worlds, where objects can be placed far away from the center, which means their position values have little precision, how do you keep the required accuracy?

Share this post


Link to post
Share on other sites
Advertisement
Extra position info. This is either by splitting the world into cells that are within precision limits, by enlarging the position data type (to 64 bits or more), or possibly other clever methods.

Some games 'relocate' the world whenever the player's position reaches a certain limit (or if it crosses pre-defined boundaries in the level). Relocation moves the player or new cell to 0,0,0 and moves everything else to compensate.

Share this post


Link to post
Share on other sites
This is actually a problem that we encounter a lot in our games, considering they take place in huge empty swaths of space. We've been through several solutions, none of which really work that well - fixed point is limited unless you're willing to go 64 bit; floats are a obviously problem and even doubles (64-bit floats) don't totally fix it because they often have to be coerced to floats for certain brain-dead libraries that don't understand doubles; and so on.

The method we're working on next is dividing the universe into cells, as Nypyren mentioned. So far it seems to work very well, but it can be tricky to compute the coordinate changes when the player (or any other object for that matter) crosses cell boundaries.

Share this post


Link to post
Share on other sites
One good solution is to use a sort of hybrid floating/fixed point representation for all coordinates. In addition to a floating point position, integer "segements" are used to provide further precision. A segment represents some predefined unit length. All positions are normalized to this representation, and all calculations are then performed relatively. When rendering for example, all positions can be calculated relative to the camera's position to ensure maximum precision for things close the viewer. As a simple example in one dimension, if the segment length is 1024, then 5846.123 has a (segment, float) representation of (5, 726.123).

This approach has a number of advantages:
1) calculations and the final result are essentially 32-bit quantities which are friendly for passing to graphics hardware.
2) By using a clever packing, positions will have a more compact representations than alternative full 64-bit representations.

There is a bit of cleverness in handling transformations such as rotations. This approach is covered in great detail in Game Programming Gems 4- an awesome addition to any library! Hope that helps. :)

Share this post


Link to post
Share on other sites
AshleysBrain - That KINDA works. But only a bit.

Problem 1 is that math operations accumulate error at differing rates depending on what order you do the operations. This leads to an issue where, if you move the camera away from the origin, you can end up in situations where you lose precision much faster than you would like.

Problem 2 is that floats aren't as good as ints for positions (link above on fixed point). So if you mistakenly use floats for world coordinates, keeping the camera at the origin doesn't gain you very much, since you still have to translate stuff from the middle of nowhere back towards (0,0,0). Now, you do gain some, since you just removed problem 1. So you are much much closer to the actual precision of a float, but as noted you can still do better with multi-level coordinate systems and fix point. You can always convert those back to float representations when you need to push info to the graphics card to display.

Share this post


Link to post
Share on other sites
Quote:
Original post by AshleysBrain
How about keeping the player/screen at 0,0 and moving the rest of the world?


That sort of thing happens automatically when Chuck Norris plays any kind of game. Including real life.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement