I am making a 3D tank game prototype with some physics simulation, am using C++. One of the decisions I need to make is the scale of the game world in relation to reality. For example, I could consider 1 in-game unit of measurement to correspond to 1 meter in reality. This feels intuitive, but I feel like I might be missing something.

I can think of the following as potential problems:

  1. 3D modelling program compatibility. (?)
  2. Numerical accuracy. (Does this matter?) Especially at large scales, how games like Battlefield have huge maps: How don't they lose numerical accuracy if they use 1:1 mapping with real world scale, since floating point representation tend to lose more precision with larger numbers (e.g. with ray casting, physics simulation)?
  3. Gameplay. I don't want the movement of units to feel slow or fast while using almost real world values like -9.8 m/s^2 for gravity. (This might be subjective.)
  4. Is it ok to scale up/down imported assets or it's best fit with a world with its original scale?
  5. Rendering performance. Are large meshes with the same vertex count slower to render?

I'm wondering if I should split this into multiple questions...


2 Answers 2


Generally you should do whatever works.

  1. Since you have real life objects it makes sense to match their scale (3D modelling apps usually have measurement units setup, meters, foot, etc.), but once you move away from tanks and into trees and other scenery objects - they probably will need to be custom scaled to fit your game style (so you model a tree and have means of scaling it in the game editor to make it look good, many times you will reuse the same tree but with a different scale to add variety).

  2. Do not move the camera far away from the worlds origin, but move the world around camera placed near worlds origin. This way you avoid a lot of precision issues that arise when GPU/physics need to precisely compare values that have poor precision. If you move tank and camera 10km from origin your precision will be in a matter of fractions of a millimeter with float32 and that can cause effects similar to Z-fighting between transformed models.

  3. You will have to tweak global constants to make your game feel good. It is the same way that you change worlds relative scale to skip boring parts and pack more interesting things into a small 4x4 km area (town, river, mountain, etc.) that are far away from each other in real world.

  4. If they looked better scaled - scale them. If they fit as they are - keep that. Games and movies are more of an art than about blind copying reality. So you have found a nice looking tree, that is just modeled 2m tall, of course you scale it and adapt yo your game by other means (tweak palette, texture detail, etc.)

  5. I doubt there's any difference as long as they take the same amount of pixels on screen to display.


Here it goes.

  1. 3D modelling programs tend to let you select the unit scale. Might be limited to Imperial or Metric, but it's just a number. Numbers can be converted/scaled/adjusted easily. It doesn't really matter what unit system you use, as long as you use that one. Stay consistent, so 1 meter doesn't become 1 foot.

    Edit: Book: Game Coding Complete, Third Addition, Chapter 15, pg. 525, "Meters, Feet, Cubits, or Kellicams?"

  2. Games with large chunks of vertices can do several thing's. For one, they can split it up into small chunk's, and then data referring to that chunk can specify an offset. Somewhat similar to using Octrees, which is a rendering optimization to avoid rendering large-portions of unseen vertices. Alternatively, a double can store 1.79769e+308, which is a pretty big, yet detailed, number. A float can store 3.40282e+038, which isn't to shabby either.

    Edit: Game Coding Complete, Third Addition, Chapter 13, pg. 410, "Coordinates and Coordinate Systems" (Table added to the bottom of the post)

  3. Your probably going to want to use a metric system then, or convert it to your own unit system. Worth noting, is that your probably going to tweak that value a bit. Sure, your tweaked value won't be physically accurate. But it might feel more accurate at, say, -9.3 m/s^2.

  4. You can do it either way. Though I would say to scale the asset. If you scale the world, you'll have to go through and change gravity, velocity calculations, and all sort's of other things. When importing assets into Unity3D I normally have to adjust the model scale in the import setting's, so I assume Unity scales it. If you wanted something more along those lines.

  5. Large or small, the size of the polygons/mesh doesn't matter NEARLY as much as how many polygons there are. I suppose there might be a slight performance change depending on how many pixels the model takes up, but that's it. Aside from that, a number being 10 or 100 doesn't change anything on the computer's end. It's still the same number of bits to process, it's just that different bit's are 0.

Edit: The fallowing table assumes a 32-bit IEEE floating-point number.

Game Coding Complete, Third Addition, Table 13.2, pg. 411
Smallest unit         Smallest Representable object  Upper Range    Description of
                      (As a textured polygon)                       largest area

100m                  A group of redwood trees       1.67x10^9      Earth/Moon System
1m                    A Human Being                  1.67x10^7      North and South America
1cm                   A coin                         1.67x10^6      California
1mm                   A flea                         1.67x10^5      San Francisco Bay Area
100 micrometer        A grain of pollen              1.67x10^4      Downtown San Francisco

All this information, and more, in Game-Coding Complete. Written by Mike McShaffry. An Industry professional working on games ranging from Black Jack, to Thief: Deadly Shadows.

  • \$\begingroup\$ Am not satisfied with this answer because it doesn't really add much to the original question and doesn't really give any concrete examples. regarding point 2 I wasn't really asking about Visibility determination or geometry paging nor about maximum floating point number.. but what I really meant is how numerical inaccuracy is handled with large geometry since floating point lose accuracy with larger numbers, it actually can store very large numbers but with poor precision. \$\endgroup\$
    – concept3d
    Oct 9, 2013 at 10:27
  • \$\begingroup\$ Do those edit's suit your liking better? \$\endgroup\$ Oct 9, 2013 at 15:06
  • \$\begingroup\$ well, yes eventhough I was particularly asking about this stackoverflow.com/questions/872544/precision-of-floating-point, especially in physics simulation but I think that needs a separate question. \$\endgroup\$
    – concept3d
    Oct 9, 2013 at 15:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .