Comment choisir le facteur d'échelle d'un monde de jeu 3D?

Je fais un prototype de jeu de tank 3D avec une simulation physique, j'utilise C ++. L'une des décisions que je dois prendre est l'échelle du monde du jeu par rapport à la réalité. Par exemple, je pourrais considérer qu'une unité de mesure en jeu correspond à un mètre en réalité. Cela semble intuitif, mais j'ai l'impression de manquer quelque chose.

Je peux considérer les éléments suivants comme des problèmes potentiels:

1. Compatibilité du programme de modélisation 3D. (?)
2. Précision numérique. (Est-ce important?) Surtout à grande échelle, comment des jeux comme Battlefield ont d'énormes cartes: comment ne perdent-ils pas la précision numérique s'ils utilisent une cartographie 1: 1 à l'échelle du monde réel, car la représentation en virgule flottante a tendance à perdre plus de précision avec de plus grandes des nombres (par exemple avec lancer de rayons, simulation physique)?
3. Gameplay. Je ne veux pas que le mouvement des unités soit lent ou rapide tout en utilisant des valeurs du monde réel comme -9.8 m/s^2pour la gravité. (Cela pourrait être subjectif.)
4. Est-il acceptable d'augmenter / réduire les actifs importés ou convient-il mieux à un monde avec son échelle d'origine?
5. Rendu des performances. Les grands maillages avec le même nombre de sommets sont-ils plus lents à rendre?

Je me demande si je devrais diviser cela en plusieurs questions ...

En général, vous devez faire tout ce qui fonctionne.

1. Étant donné que vous avez des objets réels, il est logique de faire correspondre leur échelle (les applications de modélisation 3D ont généralement une configuration d'unités de mesure, des mètres, des pieds, etc.), mais une fois que vous vous éloignez des réservoirs et des arbres et autres objets de paysage - ils auront probablement besoin être personnalisé pour s'adapter à votre style de jeu (donc vous modélisez un arbre et avez des moyens de le mettre à l'échelle dans l'éditeur de jeu pour lui donner une belle apparence, plusieurs fois vous réutiliserez le même arbre mais avec une échelle différente pour ajouter de la variété).

2. Ne déplacez pas la caméra loin de l'origine des mondes, mais déplacez le monde autour de la caméra placée près de l'origine des mondes. De cette façon, vous évitez de nombreux problèmes de précision qui surviennent lorsque le GPU / physique doit comparer avec précision des valeurs qui ont une mauvaise précision. Si vous déplacez le char et la caméra à 10 km de l'origine, votre précision sera de quelques fractions de millimètre avec float32 et cela peut provoquer des effets similaires aux combats en Z entre les modèles transformés.

3. Vous devrez modifier les constantes globales pour que votre jeu se sente bien. C'est de la même manière que vous changez l'échelle relative des mondes pour sauter des parties ennuyeuses et emballer des choses plus intéressantes dans une petite zone de 4x4 km (ville, rivière, montagne, etc.) qui sont loin les unes des autres dans le monde réel.

4. S'ils avaient l'air mieux mis à l'échelle, mettez-les à l'échelle. S'ils s'adaptent tels qu'ils sont - gardez cela. Les jeux et les films sont plus un art que la réalité de la copie aveugle. Vous avez donc trouvé un bel arbre, qui est juste modélisé sur 2m de haut, bien sûr vous le mettez à l'échelle et vous adaptez votre jeu par d'autres moyens (palette de réglages, détails de texture, etc.)

5. Je doute qu'il y ait une différence tant qu'ils prennent la même quantité de pixels à l'écran pour s'afficher.

Ça y est.

1. Les programmes de modélisation 3D ont tendance à vous permettre de sélectionner l'échelle de l'unité. Peut-être limité à Imperial ou Metric, mais ce n'est qu'un chiffre. Les nombres peuvent être convertis / mis à l'échelle / ajustés facilement. Peu importe le système d'unités que vous utilisez, tant que vous utilisez celui- ci . Restez cohérent, donc 1 mètre ne devient pas 1 pied.

   Edit: Book: Game Coding Complete, Third Addition, Chapter 15, p. 525, "Mètres, pieds, coudées ou kellicams?"

2. Les jeux avec de gros morceaux de sommets peuvent faire plusieurs choses. D'une part, ils peuvent le diviser en petits morceaux, puis les données faisant référence à ce morceau peuvent spécifier un décalage. Un peu similaire à l'utilisation d'Octrees, qui est une optimisation de rendu pour éviter de rendre de grandes portions de sommets invisibles. Alternativement, un double peut stocker 1,79769e + 308 , ce qui est un nombre assez grand, mais détaillé. Un flotteur peut stocker 3.40282e + 038, ce qui n'est pas non plus minable.

   Edit: Game Coding Complete, troisième ajout, chapitre 13, p. 410, "Coordonnées et systèmes de coordonnées" (tableau ajouté au bas du message)

3. Vous allez probablement vouloir utiliser un système métrique ou le convertir en votre propre système d'unités. Il convient de noter que vous allez probablement modifier légèrement cette valeur. Bien sûr, votre valeur modifiée ne sera pas physiquement précise. Mais cela pourrait sembler plus précis, par exemple -9.3 m/s^2.

4. Vous pouvez le faire de toute façon. Bien que je dirais de mettre à l'échelle l'actif. Si vous faites évoluer le monde, vous devrez passer par et changer la gravité, les calculs de vitesse et toutes sortes d'autres choses. Lors de l'importation d'actifs dans Unity3D, je dois normalement ajuster l'échelle du modèle dans les paramètres d'importation, donc je suppose qu'Unity la met à l'échelle. Si vous vouliez quelque chose de plus dans ce sens.

5. Grand ou petit, la taille des polygones / mailles n'a pas autant d'importance que le nombre de polygones. Je suppose qu'il peut y avoir un léger changement de performances en fonction du nombre de pixels pris par le modèle, mais c'est tout. Mis à part cela, un nombre de 10 ou 100 ne change rien du côté de l'ordinateur. C'est toujours le même nombre de bits à traiter, c'est juste que les différents bits sont 0.

Modifier: la table en jachère suppose un nombre à virgule flottante IEEE 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

Toutes ces informations, et plus, dans Game-Coding Complete. Écrit par Mike McShaffry. Un professionnel de l'industrie travaillant sur des jeux allant de Black Jack à Thief: Deadly Shadows.