¿Cómo elijo el factor de escala de un mundo de juegos en 3D?

Estoy haciendo un prototipo de juego de tanques 3D con alguna simulación física, estoy usando C ++. Una de las decisiones que debo tomar es la escala del mundo del juego en relación con la realidad. Por ejemplo, podría considerar que 1 unidad de medida en el juego corresponde a 1 metro en realidad. Esto se siente intuitivo, pero siento que podría estar perdiendo algo.

Puedo pensar en los siguientes problemas potenciales:

1. Compatibilidad con programas de modelado 3D. (?)
2. Precisión numérica (¿Importa esto?) Especialmente a grandes escalas, cómo los juegos como Battlefield tienen mapas enormes: ¿cómo no pierden precisión numérica si usan mapas 1: 1 con escala del mundo real, ya que la representación en coma flotante tiende a perder más precisión con grandes números (p. ej., con proyección de rayos, simulación física)?
3. Como se Juega. No quiero que el movimiento de las unidades se sienta lento o rápido al usar valores del mundo real como la -9.8 m/s^2gravedad. (Esto podría ser subjetivo).
4. ¿Está bien escalar / reducir activos importados o se adapta mejor a un mundo con su escala original?
5. Prestación de rendimiento. ¿Las mallas grandes con el mismo conteo de vértices son más lentas para renderizar?

Me pregunto si debería dividir esto en varias preguntas ...

Generalmente debes hacer lo que funcione.

1. Dado que tiene objetos de la vida real, tiene sentido hacer coincidir su escala (las aplicaciones de modelado 3D generalmente tienen unidades de medida configuradas, metros, pies, etc.), pero una vez que se aleje de los tanques y entre en los árboles y otros objetos del paisaje, probablemente necesitarán a escala personalizada para adaptarse a su estilo de juego (por lo que modela un árbol y tiene medios para escalarlo en el editor del juego para que se vea bien, muchas veces reutilizará el mismo árbol pero con una escala diferente para agregar variedad).

2. No mueva la cámara lejos del origen del mundo, sino mueva el mundo alrededor de la cámara colocada cerca del origen del mundo. De esta forma, evita muchos problemas de precisión que surgen cuando la GPU / física necesita comparar con precisión los valores que tienen una precisión pobre. Si mueve el tanque y la cámara a 10 km del origen, su precisión será en cuestión de fracciones de un milímetro con flotador32 y eso puede causar efectos similares a la lucha Z entre los modelos transformados.

3. Tendrás que ajustar las constantes globales para que tu juego se sienta bien. Es de la misma manera que cambias la escala relativa de los mundos para saltear las partes aburridas y empacar cosas más interesantes en un área pequeña de 4x4 km (ciudad, río, montaña, etc.) que están muy lejos unas de otras en el mundo real.

4. Si se veían mejor escalados, escalarlos. Si encajan como están, quédese con eso. Los juegos y las películas son más un arte que una copia ciega de la realidad. Así que has encontrado un árbol de aspecto agradable, que solo tiene un modelo de 2 m de altura, por supuesto, lo escalas y adaptas tu juego por otros medios (paleta de ajustes, detalles de textura, etc.)

5. Dudo que haya alguna diferencia siempre que tomen la misma cantidad de píxeles en la pantalla para mostrar.

Aquí va.

1. Los programas de modelado 3D tienden a permitirle seleccionar la escala de la unidad. Puede estar limitado a Imperial o Métrico, pero es solo un número. Los números se pueden convertir / escalar / ajustar fácilmente. Realmente no importa qué sistema utiliza la unidad, siempre y cuando se utiliza ese uno . Manténgase constante, por lo que 1 metro no se convierte en 1 pie.

   Editar: Libro: Codificación de juego completa, Tercera adición, Capítulo 15, pág. 525, "Metros, pies, codos o Kellicams?"

2. Los juegos con grandes trozos de vértices pueden hacer varias cosas. Por un lado, pueden dividirlo en pequeños fragmentos, y luego los datos que se refieren a ese fragmento pueden especificar un desplazamiento. Algo similar a usar Octrees, que es una optimización de renderizado para evitar renderizar grandes porciones de vértices invisibles. Alternativamente, un doble puede almacenar 1.79769e + 308 , que es un número bastante grande, pero detallado. Un flotador puede almacenar 3.40282e + 038, que tampoco está mal.

   Editar: Codificación de juego completa, Tercera adición, Capítulo 13, pág. 410, "Coordenadas y sistemas de coordenadas" (Tabla agregada al final de la publicación)

3. Probablemente quiera usar un sistema métrico o convertirlo a su propio sistema de unidades. Vale la pena señalar que es probable que modifiques un poco ese valor. Claro, su valor ajustado no será físicamente exacto. Pero podría sentirse más preciso en, por ejemplo, -9.3 m/s^2.

4. Usted puede hacerlo de cualquier manera. Aunque yo diría que escalar el activo. Si escala el mundo, tendrá que pasar y cambiar la gravedad, los cálculos de velocidad y todo tipo de otras cosas. Al importar activos en Unity3D, normalmente tengo que ajustar la escala del modelo en la configuración de importación, por lo que supongo que Unity lo escala. Si querías algo más en ese sentido.

5. Grande o pequeño, el tamaño de los polígonos / malla no importa NUNCA tanto como cuántos polígonos hay. Supongo que puede haber un ligero cambio de rendimiento dependiendo de cuántos píxeles ocupa el modelo, pero eso es todo. Aparte de eso, un número 10 o 100 no cambia nada en el extremo de la computadora. Sigue siendo el mismo número de bits para procesar, solo que bits diferentes son 0.

Editar: La siguiente tabla asume un número de coma flotante IEEE de 32 bits.

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

Toda esta información, y más, en Game-Coding Complete. Escrito por Mike McShaffry. Un profesional de la industria que trabaja en juegos que van desde Black Jack hasta Thief: Deadly Shadows.