Como escolho o fator de escala de um mundo de jogo em 3D?

Estou fazendo um protótipo de jogo de tanque 3D com alguma simulação de física, estou usando C ++. Uma das decisões que preciso tomar é a escala do mundo do jogo em relação à realidade. Por exemplo, eu poderia considerar uma unidade de medida no jogo para corresponder a 1 metro na realidade. Parece intuitivo, mas sinto que posso estar perdendo alguma coisa.

Posso pensar no seguinte como possíveis problemas:

1. Compatibilidade com programas de modelagem 3D. (?)
2. Precisão numérica. (Isso importa?) Especialmente em grandes escalas, como jogos como o Battlefield têm mapas enormes: como eles não perdem a precisão numérica se usam o mapeamento 1: 1 com a escala do mundo real, pois a representação de ponto flutuante tende a perder mais precisão com maior números (por exemplo, com projeção de raios, simulação de física)?
3. Jogabilidade. Não quero que o movimento das unidades pareça lento ou rápido ao usar valores quase reais, como -9.8 m/s^2a gravidade. (Isso pode ser subjetivo.)
4. É aceitável aumentar / diminuir ativos importados ou é melhor se ajustar a um mundo com sua escala original?
5. Desempenho de renderização. As malhas grandes com o mesmo vértice são mais lentas para renderizar?

Gostaria de saber se devo dividir isso em várias perguntas ...

Geralmente você deve fazer o que funcionar.

1. Como você tem objetos da vida real, faz sentido corresponder à sua escala (os aplicativos de modelagem 3D geralmente têm unidades de medida configuradas, medidores, pés etc.), mas depois que você se afasta dos tanques e entra em árvores e outros objetos de cenário - eles provavelmente precisarão para ser personalizado em escala para se adequar ao seu estilo de jogo (para modelar uma árvore e ter meios de escalá-la no editor de jogos para torná-la boa, muitas vezes você reutilizará a mesma árvore, mas com uma escala diferente para adicionar variedade).

2. Não mova a câmera para longe da origem do mundo, mas mova o mundo ao redor da câmera colocada perto da origem do mundo. Dessa forma, você evita muitos problemas de precisão que surgem quando a GPU / física precisa comparar com precisão valores com baixa precisão. Se você mover o tanque e a câmera a 10 km da origem, sua precisão estará em frações de milímetro com o float32 e isso poderá causar efeitos semelhantes ao combate em Z entre os modelos transformados.

3. Você terá que ajustar as constantes globais para que seu jogo se sinta bem. É da mesma maneira que você muda a escala relativa do mundo para pular partes chatas e colocar coisas mais interessantes em uma pequena área de 4x4 km (cidade, rio, montanha, etc.) que estão distantes uma da outra no mundo real.

4. Se eles parecessem melhor dimensionados - dimensione-os. Se eles se encaixam como estão - mantenha isso. Jogos e filmes são mais uma arte do que sobre a realidade da cópia cega. Então você encontrou uma árvore bonita, com apenas 2m de altura, é claro que você a escala e adapta seu jogo por outros meios (paleta de ajustes, detalhes de textura etc.)

5. Duvido que exista alguma diferença, desde que a mesma quantidade de pixels na tela seja exibida.

Aqui vai.

1. Os programas de modelagem 3D tendem a permitir que você selecione a escala da unidade. Pode ser limitado a Imperial ou Metric, mas é apenas um número. Os números podem ser convertidos / redimensionados / ajustados facilmente. Realmente não importa o sistema de unidades que você usa, contanto que você usar esse um . Mantenha-se consistente, para que 1 metro não se torne 1 pé.

   Edit: Book: Game Coding Complete, Terceira adição, Capítulo 15, pág. 525, "Metros, pés, côvados ou Kellicams?"

2. Jogos com grandes pedaços de vértices podem fazer várias coisas. Por um lado, eles podem dividi-lo em pequenos pedaços, e os dados referentes a esse pedaço podem especificar um deslocamento. Um pouco semelhante ao uso do Octrees, que é uma otimização de renderização para evitar a renderização de grandes porções de vértices invisíveis. Como alternativa, um double pode armazenar 1.79769e + 308 , que é um número bastante grande, porém detalhado. Um float pode armazenar 3.40282e + 038, o que também não é ruim.

   Edit: Game Coding Complete, Terceira Adição, Capítulo 13, pág. 410, "Coordenadas e sistemas de coordenadas" (tabela adicionada na parte inferior da postagem)

3. Você provavelmente vai querer usar um sistema métrico ou convertê-lo em seu próprio sistema de unidades. Vale a pena notar, é que você provavelmente irá ajustar um pouco esse valor. Claro, seu valor ajustado não será fisicamente preciso. Mas pode parecer mais preciso em, digamos -9.3 m/s^2,.

4. Você pode fazer isso de qualquer maneira. Embora eu diria para escalar o ativo. Se você escalar o mundo, terá que passar e mudar a gravidade, os cálculos de velocidade e todo o tipo de outras coisas. Ao importar ativos para o Unity3D, normalmente tenho que ajustar a escala do modelo nas configurações de importação, portanto, presumo que o Unity a dimensione. Se você queria algo mais nesse sentido.

5. Grande ou pequeno, o tamanho dos polígonos / malha não importa tanto quanto quantos polígonos existem. Suponho que possa haver uma ligeira alteração no desempenho, dependendo de quantos pixels o modelo ocupa, mas é isso. Além disso, um número de 10 ou 100 não muda nada no final do computador. Ainda é o mesmo número de bits para processar, mas os bits diferentes são 0.

Edit: A tabela a seguir assume um número de ponto flutuante 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 essa informação e muito mais em Game-Coding Complete. Escrito por Mike McShaffry. Um profissional da indústria trabalhando em jogos que variam de Black Jack a Thief: Deadly Shadows.