Contents
Visualizing Floats
 
 
Printer-Friendly VersionPrinter-Friendly Version
 


Part of:



[More information...]
 

Latest News
spacer View All spacer
 
November 22, 2009
 
Video Game Watchdog National Institute On Media And The Family Shutting Down [11]
 
Modern Warfare 2 Infinity Ward's 'Most Successful PC Version' Yet [12]
 
New Tech, Design Details Of Project Natal To Emerge At Gamefest In February
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
November 22, 2009
 
Trion Redwood City
Sr. Evnironment Modeler
 
Trion Redwood City
Sr. Environment Artist
 
Sucker Punch Productions
3D Environment Artist
 
Sucker Punch Productions
Network Programmer
 
Sucker Punch Productions
Character Artist
 
Sucker Punch Productions
Texture Artist
 
Monolith Productions
Sr. Software Engineer, Engine - Monolith Productions - #113767
 
Sony Online Entertainment
Brand Manager
spacer
Latest Features
spacer View All spacer
 
November 22, 2009
 
arrow Upping The Craft: Susan O'Connor On Games Writing [6]
 
arrow Small Developers: Minimizing Risks in Large Productions - Part II [7]
 
arrow iPhone Piracy: The Inside Story [48]
 
arrow And Yet It Grows: Analyzing the Size and Growth of the European Game Market [5]
 
arrow NPD: Behind the Numbers, October 2009 [13]
 
arrow Reflecting On Uncharted 2: How They Did It [5]
 
arrow Sponsored Feature: Rasterization on Larrabee -- Adaptive Rasterization Helps Boost Efficiency
 
arrow Postmortem: Wadjet Eye's The Blackwell Convergence [2]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
November 22, 2009
 
Time Fcuk
 
Accepting the Inherent Value of Games
 
Planckogenesis, Part II: Song Structure & Gravy Train [1]
spacer
About
spacer News Director:
Leigh Alexander
Features Director:
Christian Nutt
Editor At Large:
Chris Remo
Advertising:
John 'Malik' Watson
Recruitment/Education:
Gina Gross
 
Features
  Visualizing Floats
by Mick West
6 comments
Share RSS
 
 
January 7, 2009 Article Start Previous Page 2 of 3 Next
 

Some Solutions

Use relative coordinates. The origin in your universe is in a fixed position, but you can perform all your calculations in a space relative to an origin closer to the action, such as the camera viewpoint. Positions themselves can be stored as floats relative to some other local origin, whose position relative to the universe origin is defined in a more accurate manner.

Use fixed points. If it's important to your game that everything look and act the same whether near the origin or far away from it, then you can use fixed-point numbers to store your positions.

Essentially, it's like using integers but with a sufficiently small unit, so for example 1 could represent 0.1mm, or whatever works for your situation. This can be extended to use 64-bit fixed points for even greater range and accuracy.

Use doubles. For defining points that are a long way from the origin, you can use double precision floating point numbers. You can either define all positions as doubles and then convert to a local space for manipulation as floats, or define a remote region's position using doubles and use relative positions within that space using floats.

Boundary Conditions

We often think of polygons and their edges as pure mathematical planes and lines, which is useful when formulating algorithms to solve certain problems. Consider a simple 2D problem: deciding which side of a line a point is on.

This kind of test is often used when determining if a point is inside a triangle or other similar tasks. So, we specify it mathematically: Given a line formed by two points A and B, and a third point P, we calculate the Z component of the cross product of AP and AB, Z, such that Z=((P-A)x(B-A)).z.

If Z is negative, then C is on the left, and if Z is positive, it's on the right of the line. This relationship is purely mathematical.

To see if a point is inside a 2D triangle, a simple method is to traverse the points of the triangle in a clockwise order and use the same test to see if the point is to the right of each of the three edges of the triangle.

This test can also be used for 3D line-triangle collision detection by first transforming the triangle's points into the space of the collision line (using the transform that would make the line parallel to the z-axis, reducing the problem to two dimensions).

Figure 2: The line from A=(0,0) to B=(5000,5000) separates all points P in this region into two triangles based on the sign of z of the cross product APxAB.

 If we have two triangles that share an edge (as most triangles do in video games), and we apply the above tests to them, we should be able to accurately determine which triangle a line lays on. Figure 2 shows two triangles and the results of the test (Z<0) on the line AB that defines the edge they share. What a nice, clean, mathematical split.

Of course, the obvious problem with this test is for points that lay on the line between the polygons, where Z=0. In our pure mathematical world, a line is an infinitely thin region between the polygons. But in the practical world of floating points, the reality is rather different.

Figure 3: In the region x and y from 800.0 to 800.001 there are a number of indeterminate regions between the triangles.

If you zoom in on the line, down to the level of the individual float regions I described earlier, you will see the line defined by Z=0 is composed of a series of regions (see Figure 3). What's more, if you zoom in on the same line, but go farther from the origin, you see that the size of these regions increases (as Figure 4 illustrates).

Figure 4: At a different position on the same edge 9x and y from 4,800.0 to 4,800.001) the indeterminate regions are much larger.
 
Article Start Previous Page 2 of 3 Next
 
Comments

Thibault Jochem
profile image
232 bit patterns in a 32bit ?? wtf ....

I guess something went wrong with the "^"

Ann-Marie Ratcliffe
profile image
Ah, I see someone got there first, so I'll just second the comment.

Not sure if the formatting got corrupted by the Content Management, but all your '2 to the power of' numbers got squashed into one, so 2^32 became 232, and so on.

Peter Freese
profile image
This is a great article, reposted from Mick's blog: http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/

One point of correction (which I noted on Mick's blog page) is that changing the scale of units doesn't solve (or change) the accuracy. Using the example of Los Angeles to New York, it doesn’t make a bit of difference whether 1.0 represents 1 meter, 1 kilometer, or 1 parsec. Accuracy will still only be +/- 0.5 meters at the distance of New York to LA from the origin. The issue here is that accuracy is limited by precision at that range, regardless of the units.

Another way of thinking about this is that changing from meters to kilometers may decrease the numerical error from 0.5 to 0.0005, but the units of the error change as well, i.e. 0.5 meters is still equivalent to 0.0005 kilometers.

Simon Carless
profile image
Thanks, guys - this is actually originally reposted from Game Developer magazine (where it first appeared). We fixed the typo with 2^32, incidentally, and the other inaccuracy.

Raymond Grier
profile image
I don' think this article properly explained the actual source of the problems with floating point arithmetic:
There are only a limited number of values that can be represented by 32 bits but an infinite number of decimal values between 0.0 and 1.0, therefore each value is some decimal value less than the next biggest one with the same bit combination in it's 8-bit power section. To make things worse, the distance between 2 consecutive values is different depending on what the 8-bit combination is, which makes it hard toi anticipate the amount of error when performing an operation on 2 floats.
Everyone whoi studied science in school knows that the source of error at the end of an operation is at least as big as the biggest source of error of the 2 operands, if not bigger. if you then use that result in another operation with a another float (and so on....), the source of error keeps compounding and this is why flaoting point math has accuracy problems. The examples in the article are ultimately a result of this problem.

Vojislav Stojkovic
profile image
Another typical problem with floats -- one that stems from the issues addressed in this article -- is the comparison. If we're talking about results of computation with several steps in it, then comparing two such floats directly is always risky business. Likewise, comparing a result of floating point computation to zero is also risky. Instead, of direct comparisons, programmers should calculate the error and compare it to a predefined epsilon value.


none
 
Comment:
 


Submit Comment