#### Archived

This topic is now archived and is closed to further replies.

# Big coordinate values in Direct3D

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

## Recommended Posts

Hi. I''m doing some thinking about the translation from game world coordinates to rendering coordinates. I''d really like to just use my game object coordinates as the rendering coordinates within my Direct3D rendering ''engine'' but I am concerned about the size of the values causing problems. I recall reading somewhere that Direct3D doesn''t like really big values for the coordinates of stuff that it is rendering. Is this the case or is it just that Direct3D doesn''t like to render a really big RANGE of values (like big distances between the camera and and the back plane)? As an example (hopefully I wouldn''t have something this extreme but...) what if I had a unit at xyz of 50000, 127345, 25 and my camera is reasonably close to that location (say at 50000, 127345, 75 and looking down at the unit). Would Direct3D have a problem with those big numbers? I''m guessing not because the camera translation matrices will decimate them down to something manageable before they get sent off to D3D?

##### Share on other sites
Although I havn''t heard about this problem, it seems like a realistic issue that could come up. My suggestion to you would be just to make a scaling matrix and multiply it with your world matrix. Have it scale to whatever value and everything in the world will just scale down and you can continue to use whatever units you''re using.
~Wave

##### Share on other sites
The problem is not specifically a DirectX one, it has more to do with the resolution possible in 32 bit floating point representation. Basically, the further you get from the origin, the less accuracy you have in the decimal part of your number coordinate system. For a full explanation, check page 286 of "Game Coding Complete", or maybe someone will post a web reference.

A quote from the above book sums it up in practical terms: "This is why most games set their basic unit of measurement as the meter, and constrain presision to 1mm and set maximum range to 100 kilometers" .

If your world area is larger than the 100 km max range, then the standard approach is to divide the world up in such a way that you change the world origin as you move from one area to another. This is exlained pretty well in the Dungeon Siege continuous world article here.

Hope this helps.

Atlay

[edited by - Atlay on February 20, 2004 7:29:28 AM]

##### Share on other sites
Thanks for the replies.

I knew about the constraint on the precision in float values but I didn''t know the specifics. Do you also lose precision in the 1''s and 10''s places as your numbers get really really big or is the precision loss limitted to everything to the right of the decimal point?

For my game, the smallest unit I was even considering was centimeters which would push my upper limit to 1000km. However, I think I can get away with decimeters and that should push my upper limit to 10,000km. If I need to go beyond that (I doubt I will even come close), then I will definitely break my world up into smaller ''worlds''. I might do that anyway just for sector management.

I''m hoping there isn''t any additional issue within D3D and it doesn''t sound like there is.

##### Share on other sites
No, D3D doesn''t have any special issues with float.

However, yes, you do lose places in the whole part of the number as it increases. Float numbers can represent values up to +/- 3.4*10^38. That''s larger than 2,147,483,647, which is the largest positive value expressable by a 32-bit int, which is the same size in memory as a float. So for every representable float value that is higher than 2,147,483,647, you have to take away one that is lower.

I like pie.

##### Share on other sites
quote:
Original post by RenderTarget
However, yes, you do lose places in the whole part of the number as it increases. Float numbers can represent values up to +/- 3.4*10^38. That''s larger than 2,147,483,647, which is the largest positive value expressable by a 32-bit int, which is the same size in memory as a float. So for every representable float value that is higher than 2,147,483,647, you have to take away one that is lower.

I like pie.

I thought that the max value for an 32bit integer is 4 billion something. Anyway, the accuracy of a float is even less than what you stated, since some bits are used to store the exponent part (don''t know what it''s really called, mantissa?) of the float.

1. 1
Rutin
31
2. 2
3. 3
4. 4
5. 5

• 13
• 40
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632963
• Total Posts
3009533
• ### Who's Online (See full list)

There are no registered users currently online

×