Spieltornado-Physik: Wie Aerodynamik in Just Cause 4 (Verkehr) implementiert wird

Jacques Kerner ist Senior Software Engineer bei Avalanche Studios.


Als ob das Spiel vorher nicht verrückt genug wäre

Einführung

Die Spieleserien Just Cause und Avalanche Studios sind bekannt für ihre Open-World-Technologie, die ein abwechslungsreiches und aufregendes Gameplay bietet. Die neueste Version des Spiels - Just Cause 4 - fügte Wind- und Wetterkatastrophen hinzu, die zu einer Neuheit im Stapel von Technologien wurden, die das Gameplay vertiefen. Aber extreme Umweltbedingungen wurden ursprünglich nicht nur als eine Möglichkeit gedacht, eine glaubwürdigere Welt zu simulieren. Die Wut der Natur wird von den Mächten des Bösen gegen Rico Rodriguez kontrolliert. Wir wollten den Wind deutlicher manifestieren und extreme Wetterbedingungen sahen nicht nach plötzlichen Ereignissen aus, die dieser Welt fremd waren. In diesem Artikel werden die von uns entwickelten Techniken vorgestellt, um den Wind in all seinen Erscheinungsformen aus physikalischer Sicht zu implementieren, sowie die Reaktion aller Objekte darauf.

[Unter Katze ca. 120 MB GIF-Dateien]


JC4 Tropical Storm - Frühes Konzept (Volta)

Ein Angebot konnten wir nicht ablehnen

Als die Entwicklung von Just Cause 3 kurz vor dem Abschluss stand, wechselte der größte Teil des Teams zur Vorproduktion Just Cause 4, und der winzige Kernel musste an Patches für JC3 und herunterladbare Inhalte („DLC“) arbeiten. Hamish Young und ich, leitender Programmierer und führender Fahrzeugdesigner, konzentrierten uns auf den Mech Land Assault DLC. Wir sollten der führende Designer der Physik (und die Mechanik des Spielers) und der führende Programmierer der Physik JC4 sein, aber wir waren zu der Zeit, als das Design der neuen Franchise-Serie erstellt wurde, vollständig vom DLC fasziniert, dessen attraktive Merkmale und wichtige Funktionen bestimmt wurden. Diesmal wurde ein groß angelegter Prototyp erstellt, um die neue Grundmechanik und Ricos Reaktion auf den Wind zu testen. Ein Entwurf der Handlung wurde geschrieben, und der Verlag Square Enix genehmigte die anfängliche Entwicklungsrichtung. Das einzige, was noch übrig war, war das Konzept zu beherrschen. Aber wie geht das, ohne die Leistung zu beeinträchtigen? Sobald wir mit dem Projekt begonnen haben, haben wir das Problem von zwei Seiten angegriffen: 1. Setzen Sie breite Grenzen, um die Worst-Case-Szenarien zu vermeiden (Spoiler: Es ist uns nicht gelungen). 2. Sortieren Sie die verschiedenen Erscheinungsformen extremer Wetterbedingungen und insbesondere Hurrikanwinde. Erstellen Sie ein System, das ein realistisches Verhalten bietet, sich jedoch gut auf die gewünschte Anzahl und Dichte von Objekten skalieren lässt.


Sandsturm in JC4 - Frühe Konzeptkunst (Volta)

Schadensbegrenzung

Der Engpass bei der Echtzeitsimulation und insbesondere bei Spielen in der offenen Welt ist die Anzahl der kollidierenden physischen Körper. Die Hauptkosten entstehen durch die Berechnung von Kollisionen vieler sich bewegender Körper, die miteinander und mit einer statischen Umgebung (Relief, Gebäude) kollidieren. Deshalb trennen physische Motoren wie Havok aktive und inaktive Körper. Aktive Körper werden auf Kollisionen mit anderen Körpern überprüft und erfordern volle Rechenkosten. Wenn sich der aktive Körper mehrere Frames lang nicht bewegt, wird er von der physischen Engine als inaktiv markiert. Von diesem Moment an kann er vollständig ignoriert werden, bis er vom sich nähernden aktiven Körper „aufgeweckt“ wird. Solche inaktiven Körper ruhen normalerweise auf dem Boden und Kollisionskontrollen zwischen ihnen und der Erde werden nicht mehr durchgeführt. Es ist offensichtlich, dass die allgegenwärtige Präsenz von Wind in der offenen Welt eine Bedrohung für dieses System darstellt. Daher war es für uns wichtig sicherzustellen, dass der Wind moderat und rein kosmetisch bleibt, wenn er großen Flächen ausgesetzt wird, oder stark und physisch aktiv, wenn er in kleinen Mengen und an Orten auftritt, an denen die Menge auftritt potenziell aktive Körper sind klein. Ich habe in den frühen Entwicklungsphasen mit unserer Konstruktionsabteilung über diese Einschränkungen gesprochen, damit sie nicht eingeklemmt werden. Zunächst schien es, als hätten die Designer zugehört und beschlossen, die Flugbahnen extremer Wetterereignisse auf vorgegebene Zerstörungsrouten zu beschränken, innerhalb derer strengere Regeln für den Aufbau der Welt gelten sollten. Und sie haben einige dieser Einschränkungen beachtet. Aber die Versuchung war zu groß und der Druck der Kollegen, die das Spiel so gut wie möglich machen wollten, erwies sich als unüberwindbar. Was habe ich gerade gedacht? Unmittelbar danach schufen die Designer einen mehrere Kilometer hohen Tornado, der direkt durch die Hauptstadt des Landes führte - den am dichtesten besiedelten Teil der Insel. Dieser Tornado kühn nicht nur die Hälfte des Kapitals, sondern auch einige der ahnungslosen Programmierer, die sich nicht zu streng an diese Grundfunktion des Spiels hielten.


Blizzard in JC4 - Frühe Konzeptkunst (Volta)

Allgemeiner Ansatz

Im Allgemeinen erforderte die extreme Wetterphysik bei JC4 die folgenden Zutaten:

• Aerodynamisches Widerstandsmodell, das unter Berücksichtigung ihrer Form und Größe auf alle dynamischen Objekte der Welt angewendet wird
• Windquellen, die in Form und Verteilung extremen Wetterbedingungen (Sturm, Tornado) entsprechen, aber auch Muster der Windausbreitung auf der ganzen Welt liefern
• Optimierung der oben genannten Systeme, damit das Spiel in das Budget der Rechenlasten passt

Diese drei Probleme mussten gleichzeitig und so schnell wie möglich gelöst werden. Viele Designentscheidungen hingen von der Möglichkeit ab, alle drei Aspekte umzusetzen, und in den ersten Monaten waren wir mit den Designern unzufrieden, die geduldig auf die Gelegenheit warteten, in großem Umfang mit dem System herumzuspielen.

Zuerst haben wir ein Modell des Luftwiderstands erstellt. Nach seiner Fertigstellung lernte jedes Objekt plötzlich, ziemlich realistisch auf den Wind zu reagieren. Wenn beispielsweise ein Objekt von einer Klippe fällt oder durch eine Explosion abgeworfen wird, verlangsamen sich alle Objekte und drehen sich realistisch in der Luft, was an sich schon die Mühe wert war. Ohne Windquellen war es jedoch schwierig zu sagen, wie sie sich unter extremen Windbedingungen verhalten würden. Obwohl wir stolz auf uns selbst waren und die Erfahrung und Intuition uns geholfen haben, schnell einen Ansatz für die ersten beiden Probleme zu finden, die die Leistungsanforderungen erfüllten, waren wir sehr glücklich, als die erste Version des Tornados genau so lief, wie wir es erwartet hatten. Sie hob alle dynamischen Objekte an und drehte sie auf ziemlich realistische Weise, ohne die gesamte Prozessorzeit in Anspruch zu nehmen. JC4-Regisseur Francesco Antollini, der sehr oft nach der Tornadosituation fragte, erschien direkt neben meinem Arbeitsplatz und drückte seine Erleichterung aus: Ich glaube, ich habe die Gelegenheit verpasst, ihn zu beschämen, weil er an mir gezweifelt hat; aber eigentlich ging es mir genauso.

Aus physischer Sicht war JC4 ein Durchbruch im Vergleich zu JC3: Es ist eine dichtere, gefüllte, lebendige und schöne Welt, deren Zerstörung viel interessanter ist. Und all dies war auf denselben Zielplattformen (XBox One und PlayStation 4) möglich. Es überrascht nicht, dass die Optimierung sehr lange gedauert hat. Unser technischer Direktor Dave Barrett nutzte sofort unseren Vorteil: Wir hatten die erforderlichen Leistungsindikatoren für JC3, sodass der Leiter der Motorenentwicklungsabteilung, Daniel Pieroni, die Aufgabe erhielt, zu bestimmen, welche maximalen Kosten für Leistung und Speicher für jeden technischen Aspekt verwendet werden können. Wir erhielten der Physik großzügige 8,5 ms auf 4 Threads von 33 ms Prozessorzeit, die zugewiesen wurden, um einen Frame mit einer Frequenz von 30 Mal pro Sekunde zu erstellen. Havok nahm einen großen Teil dieses Budgets in Anspruch, um mögliche Kollisionen zwischen Objekten zu erkennen, Kontakte zu berechnen, Einschränkungen zu lösen und die Bewegung aller aktiven Körper zu „integrieren“, um ihre Position nach 33 ms simulierter Zeit zu bestimmen. Ich habe ungefähr berechnet, dass unser Budget für alle Berechnungen in Bezug auf Aerodynamik und Wind ungefähr 1 ms auf 4 Fäden betragen sollte. Grundsätzlich haben wir es geschafft, innerhalb des Budgets zu bleiben, obwohl es höchstwahrscheinlich besser ist, Daniel danach zu fragen. Die unten vorgestellte Lösung ist schnell genug für Echtzeit, wenn mehrere hundert Objekte auf modernen CPUs berechnet werden. Natürlich kann es, wie viel mehr, weiter optimiert werden, indem es an die GPU angepasst wird.

Im Rest des Artikels werde ich kurz darauf eingehen, wie wir jedes der Probleme gelöst haben, und für diejenigen, die interessiert sind, werde ich in den Anwendungsdetails und mathematischen Berechnungen präsentieren.


Wind in JC4 - Frühe Konzeptkunst (Ironklad Studios)

Widerstandsmodell

Unser Ziel bei der Erstellung des Widerstandsmodells war es, die Widerstandskräfte und Drehmomente zu bewerten, die in etwa denen ähneln, die in der realen Welt auf einen Körper beliebiger Form angewendet werden. Beachten Sie, wie ehrgeizig wir hier waren - niemand forderte großen Realismus. Wir hatten jedoch einige Anforderungen. Erstens müssen die Widerstandskräfte der Bewegung des Körpers entgegenwirken. Zweitens muss die Kraft aus der Grundgleichung des Luftwiderstands berechnet werden, d.h. variieren in Übereinstimmung mit der Oberfläche der Figur und dem Quadrat der Bewegungsgeschwindigkeit durch die Luft. Schließlich muss irgendwie die Form und Größe des Körpers berücksichtigt werden, damit sich Objekte mit derselben Oberfläche, aber sehr unterschiedlichen Formen unterschiedlich verhalten. Ich war versucht, die Form jedes Körpers einfach anhand des Parallelogramms zu approximieren, das ihn beschreibt, aber ich dachte, dass etwas mehr benötigt wird, weil es offensichtlich ist - die Form vieler Objekte kann sich erheblich von einer Box oder sogar einer kleinen Anzahl von Boxen unterscheiden. Meine früheren Erfahrungen mit Systemen, die das Volumen von 3D-Objekten mithilfe von Voxeln oder Kugeln ungefähr annähern, haben mich nach einer besseren Lösung gesucht. Mir wurde angeboten, Widerstandskoeffizienten für jedes Objekt manuell auszuwählen, aber ich wollte eine weitere Stufe der manuellen Anpassung in einer bereits komplizierten Pipeline vermeiden. Deshalb suchte ich weiter nach einem automatisierten Weg. Und ich bin froh, dass ich nicht zurückgetreten bin.

Der einfachste Weg, den Winddruck auf jeder Oberfläche der Kollisionsform unserer Objekte zu bewerten, besteht darin, nur den einfallenden Wind zu berücksichtigen und dabei die gesamte Luftzirkulation um die Objekte und die Viskosität der sie umgebenden Luft zu ignorieren. Als ob der Luftwiderstand nur darin besteht, die Luftmasse vor dem Objekt vorwärts zu bewegen oder andererseits zu absorbieren. Ein früher Prototyp zeigte, dass diese Methode für unsere Zwecke gut genug war.

Das „einzige“ Problem war, dass die Summe der Beiträge von Tausenden von Dreiecken für jede einzelne Figur während der Ausführung des Spiels eine Größenordnung höher war als das erforderliche Kostenniveau. In "schweren" Szenen konnten wir leicht mehr als 100.000 Gesichter erreichen. Es wäre großartig, wenn wir die Kräfte im Voraus berechnen könnten. Die erste Methode der „Brute Force“ bestand in einer vorläufigen Berechnung der aerodynamischen Kräfte und Drehmomente, die entstehen, wenn sich ein Körper in ruhender Luft mit unterschiedlichen Geschwindigkeiten in verschiedene Richtungen in verschiedene Richtungen bewegt, wenn er mit unterschiedlichen Winkelgeschwindigkeiten in verschiedene Richtungen gedreht wird. Also haben wir eine Nachschlagetabelle bekommen, aus der wir während der Ausführung des Spiels Werte entnehmen können. Dies kann man sich als einen virtuellen Windkanal vorstellen, der bei der Zusammenstellung unserer Inhalte berücksichtigt wird und in den wir alle Objekte der Reihe nach platzieren und sie unterschiedlichen Bewegungs- oder Rotationsgeschwindigkeiten aussetzen, wobei jedes Objekt in unterschiedlichen Winkeln platziert und jedes Mal Kräfte und Drehmomente gemessen werden.

Wie wird dieser Tisch aussehen? Die bekannten Werte zur Laufzeit sind daher die Linear- und Winkelgeschwindigkeit des Körpers $$$S = 5$Das sind nur etwa 300 KB pro Objekt. Und dennoch ist dies mindestens eine Größenordnung größer als der zulässige Speicherverbrauch.

Um die Anzahl der Proben signifikant zu reduzieren, habe ich zwei Techniken verwendet. Zunächst habe ich die Berechnung in eine lineare Form in eine Summe von Beiträgen umgewandelt, die auf der vorläufigen Berechnung von Kräften und Drehmomenten für nur einen sich bewegenden und nur rotierenden Körper basiert. Zweitens habe ich dies in eine analytische Formel zur Extrapolation von Werten bei beliebigen Geschwindigkeiten basierend auf einer vorberechneten Reaktion und nur bei einer Geschwindigkeit von 1 m / s und einer Geschwindigkeit von 1 rad / s angenähert. Dadurch wurde die vorberechnete Tabelle auf nur 7 KB pro Objekt reduziert. Leider musste ich dafür einige Annäherungen vornehmen. Der Grund für das Problem ist, dass wir selbst mit einem sehr einfachen Widerstandsmodell mit der Tatsache konfrontiert sind, dass die auf den Körper ausgeübten Kräfte, dh Rotation und Verschiebung, nicht nur die Summe der einzeln ausgeübten Kräfte für Rotation und Verschiebung sind. Obwohl ich Annäherungen hinzufügen musste, gelang es mir, einige der Begriffe zu speichern, die durch eine Kombination von Rotation beim Bewegen verursacht wurden, ähnlich wie bei der Coriolis-Komponente. Die Schlussfolgerung des Wortlauts finden Sie in Anhang 1. Anstatt die Kräfte und Drehmomente für jede Probe direkt zu speichern, speichern wir den Begriffsvektor $$$\ mathcal {A} (\ hat {u})$in den linearen Formeln verwendet. Jede Probe entspricht einer Einheitslineargeschwindigkeit relativ zu Luft mit 1 m / s oder einer Einheitswinkelgeschwindigkeit relativ zu Luft mit 1 rad / s in einer bestimmten Richtung. Die Komponenten dieses Vektors werden in der Formel verwendet, die bei der Berechnung der Kräfte und Drehmomente, die auf das Objekt ausgeübt werden müssen, auch die tatsächlichen linearen und Winkelgeschwindigkeiten des Objekts relativ zur Luft berücksichtigt. Anhang 1 beschreibt, wie dies geschieht.

Um die Suchtabelle zu speichern, verwendeten wir eine Würfelkarte, d.h. Ein Würfel, dessen Flächen in Gitter mit einer Größe von beispielsweise 3 x 3 Zellen unterteilt sind, wie ein Zauberwürfel. Wir speichern Werte in den Ecken der Zellen, sodass jede Fläche 4x4-Werte speichern kann. In jeder Ecke der Zelle berechnen wir den Vektor, der von der Mitte des Würfels zur Ecke verläuft, und normalisieren diesen Vektor, um die Einheitsrichtung zu erhalten. Wir verwenden diesen Einheitsrichtungsvektor als $$$\ mathcal {A} (\ hat {u})$für die Ecke der Zelle. Als Ergebnis erhalten wir 6 Tabellen (eine pro Kante) mit 16 Elementen mit jeweils 19 Gleitkommawerten, was etwas mehr als 7 KB entspricht, und dies ist sehr praktisch. Es gibt Möglichkeiten, die Anzahl der Abtastwerte weiter zu reduzieren, aber mit dieser Methode ist es sehr einfach, die Richtung beliebiger Geschwindigkeit zu interpolieren: Da sie immer in die Zelle fällt, ist es immer möglich, die Werte in den vier Ecken dieser Zelle zu verwenden, um eine bilineare Interpolation für diese bestimmte Richtung durchzuführen. Die Technik der kubischen Karten und der bilinearen Interpolation wird beim Rendern sehr häufig verwendet, so dass es sehr einfach ist, Informationen darüber und den entsprechenden Code zu finden.


Abbildung 1. Kubische Karte der Einheitsgeschwindigkeiten relativ zur Luft. In dieser Abbildung habe ich eine separate Zelle einer kubischen Karte rot hervorgehoben, um das Prinzip zu veranschaulichen. Lineare Geschwindigkeit haben $$$\ hat {\ omega}$In Bezug auf Luft nehmen wir erneut dieselbe kubische Karte auf, um die blaue Zelle zu finden, und verwenden die 4 in ihren Ecken gespeicherten Koeffizienten. Dann mischen wir alle Werte gemäß der Formel in Anhang 1.

Obwohl dies in den meisten Fällen funktionierte, hatten wir zur Laufzeit Schwierigkeiten, den Schwerpunkt oder die Größe von Objekten zu ändern. Unsere Lösungen für diese Probleme finden Sie in den Anhängen 2 und 3.

Bei der Entwicklung dieses Modells war ich mir nicht sicher, wie viele Proben ausreichen, um ein gutes Verhalten von Objekten zu erzielen, die sich in der Luft bewegen und drehen. Daher wusste ich nicht genau, ob ich zur Laufzeit genügend Speicher auf der Festplatte hatte. Parallel dazu haben wir begonnen, neue Zerstörungsobjekte für Havok zu erstellen, mit Hunderten von Fragmenten unterschiedlicher Größe, manchmal mehrere hundert Teile für ein Objekt. Mir wurde klar, dass einige dieser Assets dieselbe Menge an Speicher benötigen würden wie viele andere Assets insgesamt, wenn jedes Fragment seine eigene kubische Karte hätte. Das allgemeine Modell vermittelte einige einzigartige Eigenschaften komplexer Objekte, war jedoch für kleine Fragmente zu viel. Außerdem war ich mir über die Kosten zur Laufzeit nicht sicher, und die Möglichkeit, zu einem kostengünstigeren Modell zurückzukehren, war ein guter Weg, um das Risiko zu verringern. Daher fand ich einen sehr kompakten Wortlaut (großzügige Annäherungen), der nur auf Begrenzungsrahmen von Objekten basiert. Es ist in Anhang 4 zu finden.

Windvolumen

Wir haben das Konzept der Windvolumina eingeführt, um die Idee zu unterstützen, dass ein starker, physikalisch aktivierender Objektwind nur in endlichen Räumen auftreten kann, und haben begonnen, sie nach der Form und Verteilung des Windes zu klassifizieren. Wir haben die Windvolumina in folgende Haupttypen unterteilt:

• Zylindrisches Windvolumen für Schneestürme, Sandstürme und tropische Stürme
• Tornado-Windvolumen - ein vertikaler Satz von Zylindern, der relativ zu einem vertikalen Spline zentriert ist, der sich mit der Zeit verformt
• Windkanäle, die aus mehreren miteinander verbundenen kapselförmigen Figuren bestehen (Kapseln mit Radien, die sich an verschiedenen Enden unterscheiden) und so etwas wie ein „Wurmloch“ bilden

Diese Einschränkung des Windes durch das endgültige Volumen wurde mehrmals kritisiert, und im letzten Moment hätten sie ihn fast aufgegeben und durch einen „topografischen Wind“ ersetzt. Der Wind sollte überall der Bewegung der Wolken in der oberen Atmosphäre entsprechen und dem Spieler einen Luftstrom nach oben bieten, wenn er auf eine zunehmende Neigung des Geländes trifft.Wir haben es implementiert, aber das Fehlen einer klaren grafischen Darstellung des Windes hat uns gezwungen, diese Funktion aufzugeben. Die Mitarbeiter der Rendering-Abteilung hatten bereits zu viele Aufgaben für die Implementierung von Wolken, Flüssen, Wasserfällen, das Upgrade auf DirectX 12 und vieles mehr.

Rückblickend stellte sich heraus, dass Stürme sowohl in Bezug auf Form (Zylinder) als auch Windverteilung (für einen Sandsturm fast unidirektional oder für einen Schneesturm um eine Mittelachse rotierend) zu den einfachsten Windmengen wurden. Andererseits erwiesen sich Tornados und Windkanäle als komplexer und verdienen eine detailliertere Erklärung.

Tornado

Wir hatten eine klare und einfache Vorstellung davon, wie sich Objekte um einen Tornado drehen sollten, waren uns jedoch nicht einig über die Verteilung der Winde, die erforderlich sind, um dieses Ergebnis zu erzielen. Anstelle einer endlosen Debatte haben wir die verschiedenen Komponenten des Windfelds zur Laufzeit anpassbar gemacht, damit Hamish mit ihnen experimentieren und schnell eine funktionierende Option finden kann. Ein Tornado ist im Wesentlichen ein Stapel horizontaler Zylinder, deren Zentren sich auf dem zentralen Spline befinden, der sich mit der Zeit verformt. In diesen horizontalen Zylindern haben wir das Tornado-Windfeld in Zylinderkoordinaten mit einer Tangentenkomponente, einer Radialkomponente und einer Vertikalkomponente zerlegt. Jede Komponente kann mithilfe variabler Kurven angepasst werden.


2. — . , , . . , .

Wie bei vielen anderen Funktionen und wie es in unserer Branche häufig der Fall ist, gingen Hamish und ich oft von der Einstellung zum Code über, bis das Ergebnis gut genug war. Hamish passte die Kurven nach seinen Wünschen an und warf Dutzende von 12-Meter-Containern entlang des Tornados, um ihr Verhalten zu untersuchen. Er benutzte die maximal aufgezeichnete Windgeschwindigkeit (ungefähr 230 Meilen pro Stunde) für den Tornado. Nach einiger Zeit stellte Hamish fest, dass sein Aufbau kompliziert war, da der Wind überall einer einfachen Drehbewegung entsprechen musste, gleichzeitig aber Objekte in die Mitte zog. Die Winkelgeschwindigkeit war bereits Teil des Feldes und drückte nicht nur Objekte, sondern drehte sie auch in einem Tornado. Dies stellte sicher, dass sich beispielsweise in der Mitte steckende Objekte wie gewünscht drehen konnten.Daher bat Hamish, mit dem Wind zu beginnen, der überall dieser Winkelgeschwindigkeit in der Mitte entspricht, dh mit dem Geschwindigkeitsfeld eines idealen Rotationsfeldes zu beginnen, zu dem ein benutzerdefiniertes Windfeld hinzugefügt werden kann. Nach diesem letzten Aufbau bestanden die Kurven aus folgenden Komponenten:

• $$$\mathcal{R}(d)$- Faktor der radialen Komponente (radiale Bewegung)
• $$$\mathcal{T}(d)$ist der Faktor der Tangentenkomponente (radiale Bewegung)
• $$$\mathcal{V}(d)$- Faktor der vertikalen Komponente (radiale Bewegung)
• $$$\mathcal{H}(h)$- horizontaler Komponentenmultiplikator (vertikale Bewegung)
• $$$\Phi(h)$- Faktor der vertikalen Komponente (vertikale Bewegung)

Wo $$$h$ist die Höhe über dem Boden des Tornados und$$$d$ ist der Abstand vom Zentrum. Die Tornado-Windgeschwindigkeit ergibt sich aus der Gleichung:

$$

$$\vec{V}(d, h) = [V_t \mathcal{T}(d) \mathcal{H}(h) + \Omega d]\hat{t} + V_r \mathcal{R}(d) \mathcal{H}(h) \hat{r} + V_u \mathcal{V}(d) \Phi(h) \hat{up}$$

Wenn Objekte in einer bestimmten Entfernung auf die Tangentengeschwindigkeit des Tornados beschleunigt werden, ist die Tangentenkomponente der Luftwiderstandskräfte im Wesentlichen Null, da sich sowohl die Luft als auch das Objekt gemeinsam tangential bewegen. Der Rest der Windgeschwindigkeit zieht das Objekt nach innen, da der Planet Satelliten anzieht, um seine Flugbahn so zu biegen, dass es in der Umlaufbahn bleibt. Außerdem werden Objekte nach oben gedrückt, um größere Höhen zu erreichen. Das Hochschieben von Objekten ist die wichtigste Leistungsoptimierung und verhindert kostspielige Berechnungen der Kontakte von Hunderten von Objekten und der Erde. Es hilft auch, dass mit der Höhe des Tornados der Radius vergrößert wird, indem Objekte räumlich verteilt werden, um die Wahrscheinlichkeit ihrer Kollisions- und Kontaktberechnung zu verringern. Ein Tornado in der realen Welt entsteht durch den Austausch von Luft, wenn sich eine Schicht kalter Luft auf einer Schicht warmer Luft befindet.Warme Luft steigt wie ein Whirlpool um die Mitte eines Tornados auf, bei dem es sich um kalte Luft handelt. Daher sollte die Windgeschwindigkeit im Prinzip in der Mitte des Trichters stark nach unten gerichtet sein. Wie Sie sehen, wird dies in unserem Land nicht implementiert, um die Wahrscheinlichkeit zu verringern, dass Objekte zu Boden gedrückt und in einen Tornado gezogen werden. Andernfalls würde dies die kostspielige Berechnung von Kollisionen erhöhen.


3. (), (). $$$\Omega d$das Drehfeld des Windes, mit dem wir begonnen haben, um besser zu verstehen, ob ein zusätzliches Feld für den ordnungsgemäßen Betrieb des Tornados erforderlich ist. In der Version rechts wird ein Drehfeld hinzugefügt. In der Ferne sehen wir einen sehr schnellen Wind an jedem Punkt, der auf ungefähr 45 Grad vom Radius gerichtet ist. Der vertikale Abschnitt links zeigt, wie viel der Tornado in die Mitte ziehen sollte. Dann gibt es ein kleines Übergangsintervall, in dem es fast keinen Wind gibt, und dahinter gibt es ein starkes Drehfeld in der Mitte. Die Stärke des Windfeldes wird in Farbe angezeigt, je röter, desto stärker.


Abbildung 4. Linien der Pfade um das Tornado-Windfeld - der zentrale Spline der Linie.

Ein direkter Tornado scheint langweilig. Um es zu verformen, verwendeten wir 2 kubische Splines, die durch die Enden verbunden sind, von denen sich 3 Kontrollpunkte in der Umlaufbahn befinden und sich mit unterschiedlichen Geschwindigkeiten um eine imaginäre vertikale Linie bewegen. Das resultierende Tornado-Profil ändert sich mit der Zeit, sodass es langsam von der S-Form zur C-Form und umgekehrt wechselt. Anhang 5 beschreibt, wie wir Splines erstellt haben. Interessanterweise funktionierte der Tornado im Warped-Modus nicht so gut. Objekte, die in der Umlaufbahn eines direkten Tornados kreisten, zerstreuten sich jetzt, sobald sich die zentrale Spaltung des Tornados von ihnen entfernte und traurig zu Boden fiel. Um dieses Problem zu beheben, haben wir der Geschwindigkeit aufgrund der Verformung des Tornados selbst einen weiteren Begriff hinzugefügt. Letztendlich sollte diese Verformung hauptsächlich durch die Bewegung der Luft entstehen, und es erschien uns natürlich, diese Komponente hinzuzufügen. Dies löste das Problem wunderbar und gab uns Pfadlinien, die dem Bild unten sehr ähnlich sind.


Abbildung 5. Linien von Pfaden um das Tornado-Windfeld - der zentrale Spline biegt sich mit der Zeit


Abbildung 6. Ein Beispiel für einen Tornado in einem Spiel, der alles auf seinem Weg zerstört und absorbiert. Dies ist der Havok Visual Debugger (VDB), ein äußerst nützliches Tool, mit dem wir simulierte Elemente beobachten können.

Windkanäle

Windkanäle wurden entwickelt, um eine physische Windkontrolle in Teilen der Welt wie Canyons und Höhlen sowie Rauchsäulen vor riesigen Industrieventilatoren und Windkanonen zu ermöglichen. Sie können verwendet werden, um den Spieler in bestimmten Räumen oder Missionen zu führen. Unsere ersten Prototypen verwendeten einen herkömmlichen Zylinder mit einem gleichmäßigen Vektorfeld konstanter Geschwindigkeit parallel zur Rotationsachse des Zylinders. Das Platzieren all dieser Zylinder in der Szene war eine mühsame Aufgabe. Stattdessen verwendeten wir einen kubischen Bezier-Spline, um den ein Kreis mit unterschiedlichem Radius gespannt ist. Diese Form wird angenähert, indem der zentrale Spline in kapselförmige Figuren geteilt wird, d.h. auf Kapseln mit unterschiedlichen Radien an den Rändern. Das Geschwindigkeitsfeld in ihnen hat auch einige Änderungen erfahren. Anfangs war der Wind im Tunnel tangential zum zentralen Spline. Wir haben die Windgeschwindigkeiten an jedem Kontrollpunkt des Splines eingestellt und sie wurden entlang eines Spline-Segments von einem Kontrollpunkt zum anderen interpoliert. Joshua Espinosa (der Designer, der an den Windkanälen und den Bewegungen des Spielers daran arbeitete) stellte jedoch bald fest, dass er zwei weitere Komponenten benötigte. Eine Komponente ist der Upstream, der dem Spieler einen zusätzlichen künstlichen Auftrieb gibt und immer nach oben zeigt. Wir haben die andere Komponente als „Zurückziehen“ bezeichnet. Sie drückt den Spieler in Richtung des mittleren Splines, vor allem aber an den Rändern des Tunnels und fällt in die Mitte auf Null. Schließlich sorgte die Reduktionsgrenze im äußeren Teil des Tunnels für einen reibungslosen Übergang vom äußeren zum äußeren Teil des Tunnels. Die Dicke dieser Grenze wird als Prozentsatz des Radius angegeben. es wirkt entlang des gesamten Windkanals.


Abbildung 7. Windkanal, unterteilt in eine Folge überlappender kapselförmiger Figuren. Die Trennung erfolgt, wenn sich die Richtung des Splines ändert oder wenn keine lineare Längsinterpolation des Radius (A) oder der Windgeschwindigkeit (B) mehr möglich ist. Wir haben die zweite Ableitung dieser Variablen entlang des Splines berechnet, um zu bestimmen, wann geteilt werden soll.


Abbildung 8. In der Apex Engine bearbeitete Windkanäle. Der Windkanal wird je nach Spline, Änderungen des Radius und der Geschwindigkeit des Windes entlang des Splines auf die richtige Weise in Kapseln zerlegt. Wie im nächsten Abschnitt angegeben, können Sie auch die räumliche Trennung sehen, die die kapselförmigen Figuren in Morton-Kurven sortiert. Diese Berechnungen sind schnell genug für Echtzeitaktualisierungen. Darüber hinaus können Sie schnell mit dem Windkanal interagieren, um ihn zu testen. Das Bearbeitungswerkzeug wurde erstellt, indem einige Teile des Flusserstellungswerkzeugs mit zusätzlichem Debugging-Rendering überarbeitet wurden.


Abbildung 9. Ein Beispiel für einen langen Windkanal, in dem sich ein Spieler stromaufwärts zu einem Berg bewegen kann. Die Flussströmung drückt Rick ans Meer, und der Wind kann ihn schnell in das Land auf demselben Fluss zurückbringen. Die Mechanikerabteilung des Spielers bemerkte, dass die Seitenwinde von Rico zu stark waren. Der Haupteinfluss des Windes besteht darin, den Spieler zu beschleunigen (mit Rückenwind) oder zu bremsen (Gegenwind) und ihm einen zusätzlichen Auftrieb zu geben (stromaufwärtige Komponente).


Abbildung 10. Rico im Wingsuit im selben Windkanal. Hier hat der Spieler die Richtung nicht kontrolliert. Zunächst verliert Rico an Höhe, bis er den äußeren Teil des Windkanals erreicht, der seinen Niedergang allmählich verlangsamt. Dann erzeugt der zentrale Teil eine ausreichende Aufwärtsströmung, um die Schwerkraft zu überwinden, und beschleunigt sie schnell den Canyon hinauf. Der JC3 Wingsuit-Code für die richtige Interaktion mit dem Wind wurde von Joshua Espinosa, Hamish Young und Rickard Granfeld entwickelt.

Windanforderungsoptimierung

Mit dem Potenzial für Hunderte von aktiven Körpern sollte die Berechnung des lokalen Windes in ihrer Position ein schneller Prozess sein. Wir haben begonnen, die Abfragen zu optimieren, indem wir den AABB (achsenausgerichteter Begrenzungsrahmen) für jedes Windvolumen berechnet und in einem dicht gepackten Array gespeichert haben. Dies ermöglicht eine Brute-Force-Zurückweisung, da es möglich ist, die Position in Bezug auf jeden AABB schnell zu überprüfen, ohne dass Cache-Fehler auftreten. In jedem AABB-Frame werden die Windvolumina im Array aktualisiert, um die Anforderung vorzubereiten.

Wenn sich die Position innerhalb des Volumens des Sturms befindet, berechnen wir die Wirkung des Windes direkt anhand einer zylindrischen Form. Für einen Tornado müssen Sie mehr Berechnungen durchführen, da er oben viel breiter als unten ist, während die höchste Objektdichte unten liegt. Die AABB-Lösung schneidet Objekte in der Nähe des Tornados nicht sehr gut, daher haben wir übereinander gestapelte Zylinder verwendet. Sie übertragen die Tornado-Form viel näher und werden zum Abschneiden von Objekten verwendet, bevor der Wind berechnet wird. Die neueste Tornado-Optimierung bestand darin, zu vermeiden, dass die Abfrageposition auf den zentralen Spline projiziert wird. Dies war möglich, weil, obwohl der Spline-Tornado in 3D-Punkten interpoliert ist und es sich daher um eine parametrische 3D-Kurve handelt, die von ihm interpolierten Kontrollpunkte in der Praxis gleichmäßig und nacheinander entlang der Vertikalen verteilt sind, was eine ziemlich einfache Kurve ergibt. Im Allgemeinen erfordert das Projizieren eines Punkts auf einen 3D-Spline oder das Finden eines Punkts auf diesem Spline mit derselben Höhe eine Suche entlang dieses Splines. Stattdessen haben wir beschlossen, die Art und Weise, in der der Spline abgetastet wird, zu ändern, indem wir die Höhe über dem Boden des Tornados als Abtastparameter für den Spline selbst verwenden. Dadurch wird die Form des Splines geringfügig geändert, der Spline durchläuft jedoch weiterhin die Interpolationspunkte. Um jedoch einen Punkt auf dem Spline auf derselben Höhe zu finden, müssen Sie die Höhe der Anforderungsposition darauf übertragen und anschließend die Höhe des Punkts in der Höhe der Anforderung festlegen. Bei Kontrollpunkten, die ungleichmäßig entlang der vertikalen Achse angeordnet sind, ist der Unterschied spürbar, aber wenn sie gleichmäßig angeordnet sind, ist er kaum sichtbar. Wir könnten auch die Art und Weise ändern, wie die zentrale Kurve mithilfe der Funktion für die kubische Höhe anstelle der parametrischen Kurve erstellt wird, aber wie viele andere Optimierungen erschien diese zu spät.

Windkanäle mussten ebenfalls optimiert werden, da die Projektion jedes Abfragepunkts auf den zentralen Spline jedes Windkanals nicht einmal berücksichtigt wurde. Glücklicherweise ist es uns gelungen, die von Engin Silasun gleichzeitig für die Flüsse implementierte Technologie zu nutzen: eine spärliche räumliche Datenbank. Wir teilen den Raum in 32 $$$O (\ log (n))$. Befindet sich die Zelle nicht in der räumlichen Datenbank, gibt es am Abfragepunkt keinen Wind, der durch Windkanäle verursacht wird. Wenn die Zelle gefunden wird, müssen Sie eine teurere Überprüfung durchführen. Außerdem sollte diese Überprüfung ziemlich schnell erfolgen, und so schneiden wir die Windkanäle in kapselförmige Figuren. Im allgemeinen Fall werden Kapseln verwendet, da der Abstand zu ihrem zentralen Segment kostengünstig berechnet werden kann. Kapselförmige Figuren sind etwas teurer, aber immer noch schneller als der kürzeste Abstand zu einem kubischen Spline. Eine weitere Eigenschaft eines räumlich ganzheitlichen Systems von Windkanälen besteht darin, dass wir uns den Zellenindex eines bestimmten Objekts im vorherigen Frame merken und ihn als Hinweis verwenden können, um die Abfrage im nächsten Frame zu beschleunigen, da es sich höchstwahrscheinlich bereits in diesem oder einem benachbarten Frame befindet Zelle.


Abbildung 11. Kapselförmige Figuren von Windkanälen werden entsprechend den Zellen, die sie durchqueren, in eine spärliche räumliche Datenbank eingegeben. Das Ergebnis ist eine Anordnung von 9 Zellen, von denen jede nur wenige kapselförmige Figuren aufweist.

Abschließend

Die Kombination der von uns verwendeten Techniken hat sich als äußerst effektiv erwiesen. Diese Techniken werden an sich aktiv in der Programmierung eingesetzt. Der größte Teil der Arbeit liegt in ihrer Auswahl und der Sicherstellung ihrer ordnungsgemäßen Zusammenarbeit zur Lösung des aktuellen Problems. Dies ist typisch für die Programmierung von Videospielen: Es gibt viele kleine Probleme, die einfache, aber zuverlässige Lösungen erfordern.

Das Modell des Luftwiderstands ist extrem vereinfacht und spiegelt einige wichtige Eigenschaften des realen Flüssigkeitsstroms nicht wider. Beispielsweise erzeugt ein Blatt in einem Winkel von 45 Grad mehr Auftrieb als in unserem groben Modell. Das Gute daran ist jedoch, dass Kräfte und Drehmomente zur Laufzeit nicht berechnet werden und eine Lösung mit einer kubischen Karte eine detailliertere Simulation vermeidet. Tatsächlich überprüften wir die Berechnungen der Kräfte und Drehmomente, die auf der gesamten kubischen Karte des Testobjekts (eines Oldtimers von JC4) erzeugt wurden, unter Verwendung einer Open-Source-Software für die rechnergestützte Fluiddynamik (OpenFOAM). Der Vergleich ergab, dass wir nicht zu weit von den korrekten Ergebnissen entfernt waren, aber die „Form“ der kubischen Karten war unterschiedlich, und ich gehe davon aus, dass sie sich bei Objekten in Form eines Flügels noch stärker unterscheiden wird. Die Berechnung der Software dauerte jedoch mehrere Stunden, sodass es offensichtlich ist, dass eine solche Lösung nicht für alle Objekte geeignet ist. Unsere Methode dauerte weniger als eine Sekunde pro Objekt. Aber ich denke, es wäre sehr interessant für physikbasierte Spiele, schnelle, aber realistische aerodynamische Koeffizienten für alle Objekte zu haben. Angenommen, Rico könnte Objekte in riesigen Bumerangs sammeln. Ich spielte kurz mit dieser Idee herum, beobachtete den schnellen Fall und die Rotation von Ahornhubschraubersamen und erstellte in Maya ein Modell, um zu sehen, was passiert. Das Ergebnis erwies sich als besser als erwartet, und das Objekt drehte sich beim Fallen sehr langsam. Mir scheint jedoch, dass für eine schnellere Rotation das Modell des Luftwiderstands erheblich verbessert werden muss. Wie so oft hatten wir einfach nicht genug Zeit.


Abbildung 12. Links: Alle Ausrichtungen eines Oldtimer-Ölwagens aus Just Cause 4, platziert in einem virtuellen Windkanal, um eine kubische Karte mit einem 5x5-Raster auf jeder Seite zu füllen. Rechts: Paraview visualisierte Ergebnisse für zwei Ausrichtungen - in einem Winkel über (oben) und hinter (unten). Rot zeigt hohen Druck an, Blau zeigt niedrigen Druck an, Linien zeigen Flüsse an.

Tornados und Stürme arbeiteten sehr effektiv. Die Tornado-Verformung kann noch verbessert werden. Wenn wir mehr Zeit damit verbringen würden, könnten wir wahrscheinlich Wassertornados (natürlich mit Haien anstelle von Kühen), Whirlpools oder feurige Tornados herstellen. Wir hatten eine andere Idee - eine Kanone zu entwickeln, die einen Mini-Tornado erzeugt.

Windkanäle wurden in verschiedenen Teilen der Welt verwendet, um den Wind auf einer Insel wie Canyons, Missionen und um einige Militärbasen herum zu kontrollieren. Sie helfen dem Spieler, die weiten Weiten unserer offenen Welt mit strategisch lokalisierten aufsteigenden Winden zu überqueren. Aber ich denke, es wäre besser, die Idee des topografischen Windes zu verwenden, für deren Umsetzung wir keine Zeit hatten. Es wäre rationaler, es zuerst umzusetzen, es würde uns einen systematischen, allgegenwärtigen Wind geben, der fast keine Anpassung erfordert, und Windkanäle würden eine lokale Kontrolle über Abweichungen von ihm bieten.

Und schließlich war es eine logische Idee, Windbarrieren als Spielmechanik zu verwenden. Wir haben einen spielbaren Prototyp von Hindernissen implementiert, der im Team gezeigt wurde, ihn jedoch aufgrund von Zeitmangel für die korrekte Implementierung aufgegeben hat. Seine Physik war nur ein Teil der Gesamtkosten dieser Funktion, die von den meisten Entwicklerteams unterstützt werden sollte.

Aber nichts kann mich davon ablenken, wie stolz ich auf das bin, was wir in JC4 geschafft haben. Unsere Visualisierung extremer Wetterbedingungen und insbesondere von Tornados in Kombination mit Ricos Fähigkeit, sich im Weltraum zu bewegen, ermöglichte es, ein absolut einzigartiges und herausragendes Gameplay zu schaffen. Ich hoffe, Sie haben JC4 genauso genossen wie wir, als wir es erstellt haben.

Anhang 1: Luftwiderstandsmodell

Wir sehen den Körper $$$\ mathcal {B}$definiert durch das Netz $$$T_i, i \ in [0, N-1]$.


Abbildung 13. Der Körper $$$i \ in [0, N-1]$.

Betrachten Sie ein Dreieck $$$\ vec {V} _i$::

$$

$$\ vec {V} _i = \ vec {V} + \ vec {\ Omega} \ times \ vec {OC_i} = V_i \ \ hat {v_i}$$

Abbildung 14. Dreieck und Geschwindigkeit in der Mitte.

Jetzt müssen wir die Elementarkraft schreiben $$$\ vec {F} _i$auf dieses Dreieck einwirken. Hier müssen wir unsere Anforderungen berücksichtigen:

$$

$$\ vec {F} _i = - A_i \ V_i \ (\ vec {V} _i \ cdot \ hat {n} _i) \ \ hat {n} _i$$

Dies entspricht gut den Anforderungen, da die Kraft fast immer gegen die Bewegungsrichtung zur Seite gerichtet ist, proportional zur Oberfläche des Dreiecks und proportional zum Quadrat der Geschwindigkeit des Dreiecks relativ zur Luft ist. Um die Kraft auf den ganzen Körper wirken zu lassen, reicht es aus, diese Kräfte zusammenzufassen:

$$

$$\ vec {F} = \ sum {\ vec {F} _i} = \ sum {- A_i \ V_i \ (\ vec {V} _i \ cdot \ hat {n} _i) \ \ hat {n} _i}$$

Da wir uns bemühen, alles auf 1 m / s und 1 rad / s zu reduzieren, schreiben wir mit $$$\ hat {\ omega}$::

$$

$$\ vec {F} = \ sum {- A_i \ \ | V \ hat {v} + \ Omega \ hat {\ omega} \ times \ vec {OC_i} \ | (V \ hat {v} + \ Omega \ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ \ hat {n} _i}$$

Und jetzt die erste große Annäherung:

$$

$$\ | V \ hat {v} + \ Omega \ hat {\ omega} \ times \ vec {OC_i} \ | \ ca. V + \ Omega \ | \ hat {\ omega} \ times \ vec {OC_i} \ |$$

Dies entspricht der Annäherung der Länge der Hypotenuse eines Dreiecks an die Summe der Längen seiner beiden Seiten. Diese Annäherung wird auch als "Stadtblockentfernung" (Manhattanentfernung) bezeichnet. Als ich an dieser Aufgabe arbeitete, war ich nur in Manhattan, also wäre es dumm, sie nicht zu benutzen. Wir haben also folgendes:

$$

$$\ vec {F} = \ sum {- A_i \ (V + \ Omega \ | \ hat {\ omega} \ times \ vec {OC_i} \ |) (V \ hat {v} + \ Omega \ hat {\ Omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ \ hat {n} _i}$$

Wir zersetzen:

$$

$$\ vec {F} = V ^ 2 \ sum {-A_i \ hat {v} \ cdot \ hat {n} _i \ hat {n} _i} + \ Omega ^ 2 \ sum {-A_i \ | \ hat { \ omega} \ times \ vec {OC_i} \ | (\ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ hat {n} _i} \\ + V \ Omega \ sum {-A_i (\ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ hat {n} _i} + \ Omega V \ sum {-A_i \ | \ hat {\ omega} \ times \ vec {OC_i} \ | (\ hat {v} \ cdot \ hat {n} _i) \ hat {n} _i}$$

Dies mag zunächst einschüchternd erscheinen. Aber dann merkt man, dass wir danach gesucht haben. Beachten Sie, dass nur Beträge gefunden werden $$$\ | \ hat {\ omega} \ times \ vec {OC_i} \ |$mit seinem Durchschnittswert unter allen Dreiecken:

$$

$$\ | \ hat {\ omega} \ times \ vec {OC_i} \ | \ approx Avg (\ | \ hat {\ omega} \ times \ vec {OC_i} \ |) _ {i \ in [0, N-1]}$$

Bezeichnen wir es mit $$$\ hat {\ omega}$. Jetzt können wir endlich schreiben:

$$

$$\ vec {F} = V (V + \ Omega \ \ overline {v_r} (\ hat {\ omega})) \ vec {F} _t (\ hat {v}) + \ Omega ^ 2 \ vec {F} _r (\ hat {\ omega}) + V \ Omega \ vec {F} _c (\ hat {\ omega})$$

wo:

$$

$$\ begin {align *} \ vec {F} _t (\ hat {v}) & = \ sum {-A_i \ hat {v} \ cdot \ hat {n} _i \ \ hat {n} _i} \\ \ vec {F} _r (\ hat {\ omega}) & = \ sum {-A_i \ | \ hat {\ omega} \ times \ vec {OC_i} \ | (\ hat {\ omega} \ times \ vec { OC_i}) \ cdot \ hat {n} _i \ \ hat {n} _i} \\ \ vec {F} _c (\ hat {\ omega}) & = \ sum {-A_i (\ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ \ hat {n} _i} \\ \ overline {v_r} (\ hat {\ omega}) & = {1 \ over N} \ sum {\ | \ hat {\ omega} \ times \ vec {OC_i} \ | } \ end {align *}$$

Moment dieser Kräfte relativ zum Punkt $$$Oo$kann auf ähnliche Weise erhalten werden. Als Ergebnis erhalten wir Folgendes:

$$

$$\ left. \ vec {M} \ right | _O (\ hat {v}, \ hat {w}) = V (V + \ Omega \ \ overline {v_r} (\ hat {\ omega})) \ vec { M} _t (\ hat {v}) + \ Omega ^ 2 \ vec {M} _r (\ hat {\ omega}) + V \ Omega \ vec {M} _c (\ hat {\ omega})$$

wo:

$$

$$\ begin {align *} \ vec {M} _t (\ hat {v}) & = \ sum {-A_i \ hat {v} \ cdot \ hat {n} _i \ (\ vec {OC_i} \ times \ hat {n} _i)} \\ \ vec {M} _r (\ hat {\ omega}) & = \ sum {-A_i \ | \ hat {\ omega} \ times \ vec {OC_i} \ | (\ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ (\ vec {OC_i} \ times \ hat {n} _i)} \\ \ vec {M} _c (\ hat {\ Omega}) & = \ sum {-A_i (\ hat {\ omega} \ times \ vec {OC_i}) \ cdot \ hat {n} _i \ (\ vec {OC_i} \ times \ hat {n} _i)} \ end {align *}$$

Mit den obigen Definitionen können wir nun einen Vektor bilden $$$\ mathcal {A} (\ hat {u})$::

$$

$$\ mathcal {A} (\ hat {u}) = \ begin {bmatrix} \ vec {F} _t (\ hat {u}) \\ \ vec {F} _r (\ hat {u}) \\ \ vec {F} _c (\ hat {u}) \\ \ vec {M} _t (\ hat {u}) \\ \ vec {M} _r (\ hat {u}) \\ \ vec {M} _c (\ hat {u}) \\ \ overline {v_r} (\ hat {u}) \ end {bmatrix}$$

Dies ist ein Vektor mit 19 Werten und wir beziehen uns auf die Beispieltabelle $$$\ hat {w}$, aber wir können ziemlich nahe Werte finden und sie dann entweder direkt verwenden oder sie zum Interpolieren der Ausgabe verwenden. Und zu diesem Zeitpunkt kommt die im Artikel beschriebene kubische Karte ins Spiel.

Anhang 2: Schwerpunkt

Möglicherweise stellen Sie fest, dass die oben gezeigten Werte relativ zu einem beliebigen Punkt berechnet werden $$$P_i$. Die auf den Körper wirkende Gesamtkraft ist einfach die Summe aller Kräfte:

$$

$$\ vec {F} = \ sum {\ vec {f} _i}$$

Momente $$$O$sind eingestellt als:

$$

$$\ left. \ vec {m} _i \ right | _O = \ vec {OP_i} \ times \ vec {f} _i$$

und das Gesamtmoment dieser Kräfte relativ zum Punkt $$$O$ist gleich:

$$

$$\left.\vec{M}\right|_O = \sum{\left.\vec{m}_i\right|_O} = \sum{\vec{OP_i} \times \vec{f}_i}$$

Jetzt ist es nur eine mathematische Definition, eine Formel, die aufgrund des Schwerpunkts nicht direkt verwendet werden kann, um die Bewegung des Körpers zu ändern $$$G$in dieser Formel ist nach dem Schall-Theorem gleich:

$$

$$\left.\vec{M}\right|_O = \sum{(\vec{OG} + \vec{GP_i}) \times \vec{f}_i} = \sum{\vec{OG} \times \vec{f}_i} + \sum{\vec{GP_i} \times \vec{f}_i}$$

Wir erkennen den Moment der Kräfte in Bezug auf $$$\vec{F}$, deshalb:

$$

$$\left.\vec{M}\right|_O = \vec{OG} \times \vec{F} + \left.\vec{M}\right|_G$$

Und es ist sehr nützlich für uns, wenn wir die Gesamtfestigkeit berechnet haben $$$\vec{F}$unverändert und das folgende Drehmoment auf den Schwerpunkt aufbringen:

$$

$$\left.\vec{M}\right|_G = \left.\vec{M}\right|_O + \vec{GO} \times \vec{F}$$

Zuerst habe ich beschlossen, nur den Ursprung des Körpers als Punkt zu nehmen $$$O$in der Mitte des Begrenzungsparallelogramms des Körpers, das sich noch in der Nähe des Massenschwerpunkts befinden sollte, und lokalisierte Windprobenahme an der logischsten Stelle relativ zum Körper.

Anhang 3: Skalierung

Ein weiterer Fehler trat auf, als Luftballons in das Spiel eingeführt wurden. Diese Kugeln sind kugelförmige Körper, deren Größe um den Faktor 5 oder 10 variieren kann. Wie im Fall des Massenschwerpunkts war es zu kostspielig, die aerodynamischen Eigenschaften zur Laufzeit neu zu berechnen. Ist es möglich, eine analytische Formel abzuleiten?


Abbildung 15 Körper $$$\vec{O_sC_{si}} = s\ \vec{OC_i}$

Betrachten Sie den Körper noch einmal $$$\vec{F}$aber jetzt zu einem skalierten Objekt. Wir bekommen:

$$

$$\vec{F_s} = V^2 \sum{ -A_i \hat{v} \cdot \hat{n}_i \hat{n}_i } +\Omega^2 \sum{ -A_i \|\hat{\omega}\times\vec{OC_{si}}\|(\hat{\omega}\times\vec{OC_{si}})\cdot \hat{n}_i\hat{n}_i } \\ +V\Omega \sum{ -A_i (\hat{\omega}\times\vec{OC_{si}}) \cdot \hat{n}_i \hat{n}_i } +\Omega V \sum{ -A_i \|\hat{\omega}\times\vec{OC_{si}}\|(\hat{v}\cdot\hat{n}_i)\hat{n}_i }$$

Verwenden Sie die gleichen Näherungswerte wie beim ersten Mal und ersetzen Sie sie $$$s\ \vec{OC_i}$wir bekommen:

$$

$$\vec{F_s} = V(V s^2+\Omega s^3\ \overline{v_r}(\hat{\omega}))\vec{F}_t(\hat{v}) +\Omega^2 s^4 \vec{F}_r(\hat{\omega}) +V\Omega s^3 \vec{F}_c(\hat{\omega})$$

Für den Schwerpunkt des skalierten Körpers $$$G_s$.

Anhang 4: Vereinfachtes Widerstandsmodell für Parallelogramm

Es gibt viele Möglichkeiten, Kräfte und Drehmomente für ein Parallelogramm zu approximieren, und es können verschiedene Formeln erhalten werden. Kompakt genug, einfach in Code und Berechnungen zur Laufzeit zu implementieren, kann daraus geschlossen werden, dass die Auswirkung der Winkelbewegung auf die lineare Kraft und die Auswirkung der linearen Geschwindigkeit auf das Drehmoment ignoriert werden. Begrenzung des Parallelogramms$$$e_z$ können wir zu folgenden kompakten Formeln kommen:

$$

$$\vec{F} = - \rho V^2 \left< e_y e_z, e_x e_z, e_x e_y \right> \cdot \hat{v}$$

$$

$$\vec{M} = - {{\rho}\over{6}} \Omega^2 e_x e_y e_z \hat{w} \cdot \left< e_y^2+e_z^2, e_x^2+e_z^2, e_x^2+e_y^2 \right>$$

Anhang 5: Tornado Center Spline

Der Tornado ist um eine zentrale Kurve zentriert, deren Form sich langsam ändert. Wir haben dies mit zwei aufeinanderfolgenden kubischen Bezier-Splines implementiert:$$$\mathcal{C}_0$ für den Boden und $$$\mathcal{C}_1$für die Spitze. Spline$$$\mathcal{C}_0$ hat Kontrollpunkte $$$P_0$, $$$P_1$, $$$P_2$und $$$P_3$und $$$\mathcal{C}_1$durch Punkte gesteuert $$$P_4$, $$$P_5$, $$$P_6$und $$$P_7$. Die Position des Tornados selbst ist an einem Punkt $$$P_0$auf dem Boden und dem höchsten Punkt $$$P_7$Es beginnt direkt über dem Niveau der Wolkenschicht, ist aber spät in der Zeit und folgt langsam der Position auf der Erde. Da die Kurven an einem Ende verbunden sind,$$$P_3$ und $$$P_4$im Raum zusammenfallen. Wir haben auch 3 horizontale Referenzbahnen für Punkte verwendet$$$P_1$ , $$$P_2$und $$$P_5$. Endlich $$$P_3$befand sich genau in der Mitte zwischen $$$P_2$und $$$P_5$und $$$P_6$in der Mitte zwischen $$$P_5$und $$$P_7$.

Erstellen eines Tornado-Center-Splines	Tornado Center Spline Evolution in der Zeit

Referenzen

1. Nur weil 4
2. Havok
3. Grundlagen mehrdimensionaler und metrischer Datenstrukturen . Hanan Samet
4. Kurve der Z-Ordnung
5. Würfelzuordnung
6. Schaum öffnen
7. Volta
8. Ironklad Studios