Here it goes.
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?"
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)
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
.
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.
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.