Wie wähle ich den Skalierungsfaktor einer 3D-Spielwelt?

Ich mache einen 3D-Panzerspiel-Prototyp mit einer Physiksimulation und verwende C ++. Eine der Entscheidungen, die ich treffen muss, ist das Ausmaß der Spielwelt in Bezug auf die Realität. Zum Beispiel könnte ich 1 Maßeinheit im Spiel so betrachten, dass sie in der Realität 1 Meter entspricht. Das fühlt sich intuitiv an, aber ich habe das Gefühl, dass mir etwas fehlt.

Ich kann mir Folgendes als potenzielle Probleme vorstellen:

1. Kompatibilität mit 3D-Modellierungsprogrammen. (?)
2. Numerische Genauigkeit. (Ist das wichtig?) Insbesondere bei großen Maßstäben haben Spiele wie Battlefield riesige Karten: Wie verlieren sie nicht an numerischer Genauigkeit, wenn sie 1: 1-Karten im realen Maßstab verwenden, da die Gleitkommadarstellung bei größeren Karten tendenziell an Präzision verliert Zahlen (zB mit Ray Casting, Physiksimulation)?
3. Spielweise. Ich möchte nicht, dass sich die Bewegung von Einheiten langsam oder schnell anfühlt, während fast reale Werte wie die -9.8 m/s^2Schwerkraft verwendet werden. (Dies könnte subjektiv sein.)
4. Ist es in Ordnung, importierte Assets zu vergrößern oder zu verkleinern, oder passt es am besten zu einer Welt mit ihrer ursprünglichen Skalierung?
5. Renderleistung. Sind große Netze mit derselben Scheitelpunktanzahl langsamer zu rendern?

Ich frage mich, ob ich das in mehrere Fragen aufteilen soll ...

Im Allgemeinen sollten Sie alles tun, was funktioniert.

1. Da Sie reale Objekte haben, ist es sinnvoll, deren Maßstab anzupassen (3D-Modellierungs-Apps verfügen normalerweise über Setup-Einheiten, Meter, Fuß usw.), aber sobald Sie sich von Panzern in Bäume und andere Landschaftsobjekte bewegen, werden sie wahrscheinlich benötigt Um individuell an Ihren Spielstil angepasst zu werden (so modellieren Sie einen Baum und haben die Möglichkeit, ihn im Spieleditor zu skalieren, damit er gut aussieht. Oft verwenden Sie denselben Baum wieder, jedoch mit einer anderen Skalierung, um Abwechslung zu schaffen).

2. Bewegen Sie die Kamera nicht weit vom Ursprung der Welt weg, sondern bewegen Sie die Welt um die Kamera herum, die sich in der Nähe des Ursprungs der Welt befindet . Auf diese Weise vermeiden Sie viele Präzisionsprobleme, die auftreten, wenn GPU / Physik Werte mit geringer Präzision genau vergleichen müssen. Wenn Sie Panzer und Kamera 10 km vom Ursprung entfernt bewegen, liegt Ihre Präzision mit float32 in Bruchteilen eines Millimeters. Dies kann ähnliche Auswirkungen wie Z-Kämpfe zwischen transformierten Modellen haben.

3. Sie müssen globale Konstanten anpassen, damit sich Ihr Spiel gut anfühlt. Auf die gleiche Weise ändern Sie die relative Größe der Welt, um langweilige Teile zu überspringen und interessantere Dinge in ein kleines 4x4 km großes Gebiet (Stadt, Fluss, Berg usw.) zu packen, das in der realen Welt weit voneinander entfernt ist.

4. Wenn sie besser skaliert aussehen - skalieren Sie sie. Wenn sie so passen wie sie sind - behalten Sie das. Spiele und Filme sind eher eine Kunst als das blinde Kopieren der Realität. Sie haben also einen gut aussehenden Baum gefunden, der nur 2 m hoch modelliert ist. Natürlich skalieren Sie ihn und passen Ihr Spiel auf andere Weise an (Optimierungspalette, Texturdetails usw.).

5. Ich bezweifle, dass es einen Unterschied gibt, solange die gleiche Anzahl von Pixeln auf dem Bildschirm angezeigt wird.

Hier kommt's.

1. Mit 3D-Modellierungsprogrammen können Sie in der Regel die Einheitenskala auswählen. Könnte auf Imperial oder Metric beschränkt sein, aber es ist nur eine Zahl. Zahlen können einfach konvertiert / skaliert / angepasst werden. Es spielt eigentlich keine Rolle , was Einheitensystem Sie verwenden, solange Sie verwenden ein . Bleiben Sie konstant, damit 1 Meter nicht zu 1 Fuß wird.

   Bearbeiten: Buch: Game Coding Complete, Dritte Ergänzung, Kapitel 15, S. 525, "Meter, Füße, Ellen oder Kellicams?"

2. Spiele mit großen Scheitelpunkten können verschiedene Aufgaben ausführen. Zum einen können sie es in kleine Blöcke aufteilen, und dann können Daten, die sich auf diesen Block beziehen, einen Versatz angeben. Ähnlich wie bei der Verwendung von Octrees, bei der es sich um eine Renderoptimierung handelt, um das Rendern großer Teile unsichtbarer Scheitelpunkte zu vermeiden. Alternativ kann ein Double 1.79769e + 308 speichern , was eine ziemlich große, aber detaillierte Zahl ist. Ein Float kann 3.40282e + 038 speichern, was auch nicht zu schäbig ist.

   Bearbeiten: Spielcodierung abgeschlossen, dritte Ergänzung, Kapitel 13, S. 410, "Koordinaten und Koordinatensysteme" (Tabelle am Ende des Beitrags hinzugefügt)

3. Dann möchten Sie wahrscheinlich ein metrisches System verwenden oder es in Ihr eigenes Einheitensystem konvertieren. Bemerkenswert ist, dass Sie diesen Wert wahrscheinlich ein wenig optimieren werden. Sicher, Ihr optimierter Wert ist physikalisch nicht korrekt. Aber es könnte sich beispielsweise genauer anfühlen-9.3 m/s^2 .

4. Sie können es so oder so tun. Obwohl ich sagen würde, den Vermögenswert zu skalieren. Wenn Sie die Welt skalieren, müssen Sie die Schwerkraft, Geschwindigkeitsberechnungen und alle möglichen anderen Dinge ändern. Beim Importieren von Assets in Unity3D muss ich normalerweise die Modellskala in den Importeinstellungen anpassen, daher gehe ich davon aus, dass Unity sie skaliert. Wenn Sie etwas mehr in diese Richtung wollten.

5. Ob groß oder klein, die Größe der Polygone / Maschen spielt fast keine Rolle, wie viele Polygone es gibt. Ich nehme an, es kann eine leichte Leistungsänderung geben, abhängig davon, wie viele Pixel das Modell einnimmt, aber das war's. Abgesehen davon ändert eine Zahl von 10 oder 100 nichts am Ende des Computers. Es ist immer noch die gleiche Anzahl von zu verarbeitenden Bits, es ist nur so, dass verschiedene Bits 0 sind.

Bearbeiten: Die folgende Tabelle nimmt eine 32-Bit-IEEE-Gleitkommazahl an.

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 diese Informationen und mehr finden Sie in Game-Coding Complete. Geschrieben von Mike McShaffry. Ein Branchenprofi, der an Spielen von Black Jack bis Thief: Deadly Shadows arbeitet.