Leistungsstarke Physik in Unity 5
Wir verwenden PhysX 2.8.3 nun schon eine Weile. Wir haben nicht nur das einfache Standard-PhysX verwendet, sondern es mit zahlreichen Patches erweitert, die von Unity-Ingenieuren im Laufe der Jahre erstellt wurden. Es ist so lange her, und wir bedanken uns bei PhysX 2 für all den Fisch. Wie auf der GDC'14 angekündigt, bietet Unity 5.0 ein Upgrade auf PhysX 3.3. Schauen wir uns das einmal genauer an.
PhysX SDK 3 ist eine radikale Umgestaltung des guten alten PhysX SDK 2.x. Im Grunde hat das PhysX-Team die besten Ideen und Ansätze von 2.x übernommen und das gesamte SDK von Grund auf neu geschrieben. Das heißt, die gesamte Codebasis ist anders, alle Schnittstellen sind anders und die meisten Funktionen sind anders.
Jetzt wollen wir Ihnen einen Vorgeschmack darauf geben, wie es sich anfühlt, Unity 5.0 Physik zu verwenden.
Um mit etwas Einfachem zu beginnen, haben wir die adaptive Kraft schaltbar gemacht und standardmäßig deaktiviert. Adaptive Force ist eine spezielle Technik in PhysX, um numerische Fehler bei der Simulation von Stapeln zu kompensieren. Die Rückmeldungen der Unity-Entwickler zeigen jedoch, dass die adaptive Kraft in hohem Maße zur allgemeinen Instabilität der Spielinhalte beiträgt. Erwarten Sie, dass sich Ihre stapelartigen Dinge in Zukunft besser verhalten.
Das Verschieben von statischen Collidern wird viel weniger kostspielig sein. Ein Static Collider ist einfach ein Spielobjekt mit einer Collider-Komponente, aber ohne eine Rigidbody-Komponente. Da das SDK bisher davon ausging, dass statische Kollider nicht verschoben werden, führte das Verschieben eines statischen Kolliders zu einem teuren Neuaufbau des AABB-Baums, was die Gesamtleistung stark beeinträchtigte.
In Unity 5 werden wir dieselbe Datenstruktur verwenden, um die Bewegung von dynamischen und statischen Kollidern zu handhaben. Leider geht damit der Vorteil verloren, dass statische Collider weniger Speicherplatz verbrauchen als dynamische Collider. Momentan sind die Kosten für das Verschieben von Static Colliders jedoch eine der 3 Hauptursachen für Leistungsprobleme in Unity-Spielen. Das wollten wir ändern.
Die kontinuierliche Kollisionserkennung wurde um eine Größenordnung verbessert. Die kontinuierliche Kollisionserkennung wird verwendet, um zu verhindern, dass sich schnell bewegende Körper durch andere Körper hindurchgehen, ohne dass eine Kollision erkannt wird. Stellen Sie sich eine Kugel vor, die auf ein Stück Papier geschossen wird, oder ein Billardspiel, bei dem sich einige Kugeln schneller bewegen als andere.
In Unity 5.0 generiert das SDK alle Daten, die für schnelle Bewegungen erforderlich sind. Aktivieren Sie einfach die kontinuierliche Kollisionserkennung und es funktioniert. PhysX3 verfügt über einen Algorithmus, der erkennt, ob die teure CCD-Simulation angesichts der aktuellen Körpergeschwindigkeit tatsächlich erforderlich ist oder ob eine diskrete Standardlösung ausreicht. Sie wird aktiviert, sobald Sie den CCD aktivieren.
PhysX3 unterstützt mehr Rigidbodies auf der Broadphase. Auf Desktop- und Desktop-ähnlichen Plattformen können Sie sogar mehrere hunderttausend Körper auf einem einzigen Bild haben. Zuvor gab es eine feste Grenze von 64k für Körper. Das war keine Konstante, die wir einfach erhöhen konnten - es war eine Folge der Einsparungen an Bits im gesamten SDK. Einige Zielkonsolen, wie die PlayStation 3, haben diese Einschränkung noch. Es gibt auch eine Begrenzung für Physikmaterialien: Zum Zeitpunkt der Erstellung dieses Artikels können Sie nicht mehr als 64k Materialien auf jeder Plattform haben.
In Unity 5.0 haben wir die Kosten für die Skalierung von Mesh Collidern reduziert. Wenn man früher einen Mesh Collider skalieren wollte, musste man ein neues Mesh erstellen, bei dem die Skalierung in die Scheitelpunkte integriert war, was viel Zeit und Speicherplatz kostete. Mit PhysX3 sind wir in der Lage, nicht-negative Skalierung ohne Backing zu unterstützen. Es ist im Grunde kostenlos.
Als Nächstes werfen wir einen Blick auf zwei Subsysteme, die sich so sehr von der Unity 4.x-Version unterscheiden, dass man sie als neu betrachten kann: die Module für Kleidung und Fahrzeuge.
Beginnen wir mit der Kleidung. In Unity 4 wird die Stoffsimulation durch die Komponenten InteractiveCloth und SkinnedCloth unterstützt. InteractiveCloth hat ein stoffähnliches Mesh-Verhalten, d.h. einen "physischen Stoff", der mit anderen physikalischen Körpern interagiert, Kräfte ausüben kann usw. Da InteractiveCloth sehr rechenintensiv ist, gibt es in Unity 4 eine weitere Variante, SkinnedCloth, für die Kleidung von Charakteren.
Da SkinnedCloth von der Hauptsimulationspipeline entkoppelt ist, ist es in der Lage, eine bessere Leistung als InteractiveCloth zu erbringen. Das Hauptproblem bei Stoffen ist, dass beide Komponenten recht instabil sind und viel kosten. Mit der kommenden PhysX3-Integration haben wir uns entschlossen, die Unterstützung für InteractiveCloth aufzugeben und nur noch eine Stoffkomponente, genannt "Simply Cloth", für die Kleidung der Charaktere zu verwenden.
In Unity 5.0 reagiert Cloth nicht mehr auf alle Collider in einer Szene und überträgt auch keine Kräfte mehr auf die Welt. Stattdessen haben wir eine schnellere, stabilere Multithreading-Lösung für Zeichenbekleidung. Wenn Sie sie hinzufügen, reagiert die neue Komponente "Stoff" nicht mehr auf Körper.
Das bedeutet, dass Cloth und die Welt einander nicht erkennen oder sehen können, bis Sie der Cloth-Komponente manuell Kollider aus der Welt hinzufügen. Auch danach ist die Simulation immer noch einseitig: Der Stoff reagiert auf diese Körper, übt aber keine Kräfte auf sie aus. Außerdem können Sie nur drei Arten von Kollidern mit Stoff verwenden: Kugel-, Kapsel- und konische Kapsel-Kollidern, die mit zwei Kugel-Kollidern konstruiert werden. All diese Änderungen wurden eingeführt, um die Leistung zu steigern.
Das Authoring-Interface in Unity 5.0 ähnelt dem von SkinnedCloth, und wir arbeiten hart daran, es in 5.x zu verbessern. Erwarten Sie, dass Dinge wie die Integration mit Mecanim-Avataren im Laufe des 5.x-Zyklus hinzugefügt werden.
Die neue Cloth-Komponente unterstützt intern den Grafikprozessor über CUDA, aber wir haben uns aus mehreren Gründen entschieden, dies erst später im 5.x-Zyklus zu veröffentlichen. Erstens funktioniert CUDA nur unter Windows auf NVIDIA-Hardware, und wir haben eine große Präsenz auf Mac und Linux. Zweitens wollen wir uns bei der Fehlerbehebung zuerst auf die Kernfunktionen konzentrieren und uns erst danach an die Integration ausgefallener Dinge machen.
Nun ein paar Worte zu den Fahrzeugen. PhysX3 hat ein glänzendes neues Fahrzeug-SDK, das wir zur Implementierung unserer WheelCollider-Komponente verwendet haben. Die neue Komponente sorgt für eine wesentlich realistischere Federung und Reifenreibung. Außerdem wird eine Reihe anderer, seit langem bestehender Probleme behoben.
In Unity 5.0 kann die neue Komponente sofort verwendet werden, um ein einfaches Verhalten zu erzeugen. Ich erwarte von den Entwicklern nur dann, dass sie sich für Fahrzeugpakete im Asset Store entscheiden, wenn sie etwas wollen, das bereits fein abgestimmt, realistisch oder fortgeschritten ist, wie Edys Fahrzeugpaket.
Schauen Sie sich an, was ich in ein paar Stunden mit einem kostenlosen Mesh aus dem Internet erstellt habe (die meiste Zeit davon habe ich in Blender verbracht, um das Modell vorzubereiten):
Und hier ist einer der SUVs aus Edy's Vehicle Package:
Edy arbeitet derzeit an der neuen Version seines Pakets, das noch mehr erstaunliche Dinge enthalten wird. Wenden Sie sich für weitere Einzelheiten direkt an ihn .
Es gibt viele fantastische technische Details über die Fahrzeuge, die ich gerne mit Ihnen teilen würde, aber lassen Sie uns erst einmal einen Blick auf die neuen WheelCollider-Geräte werfen. So können Sie sich ein Bild davon machen, wie die Federung funktionieren wird.
In der obigen Abbildung sind der Radkreis und der Raddurchmesser grün, das Segment des Federwegs orange und die Kugel des Kraftangriffspunkts grün markiert. Auf dem Federwegsegment befinden sich Markierungen für die maximale Einfederungsposition, die maximale Ausfederungsposition und die Zielposition.
Wie nicht anders zu erwarten, kann das Rad nur zwischen der maximalen Einfederung und der maximalen Ausfederung bewegt werden. Die Zielposition (in der Fachsprache auch als Ruheposition bezeichnet) befindet sich genau dort, wo das gefederte Gewicht durch die Federkraft ausgeglichen wird, also dort, wo sich das Rad befindet, wenn das Fahrzeug gerade auf einer ebenen Fläche steht. Es mag schwierig erscheinen, die Einstellung vorzunehmen, aber tatsächlich ist die maximale Druckposition die Position, an der sich Ihr Rad ursprünglich im Netz befindet.
Anschließend geben Sie den Aufhängeabstand und die Zielposition als Bruchteil des Aufhängeabstands an. Nur zwei Schwimmer, um sie alle zu beherrschen, keine große Sache! Habe ich Ihnen schon gesagt, dass das neue Rad-Gizmo jetzt die Drehung und Position aus den Simulationsdaten sofort aktualisiert? Sie müssen nicht einmal die tatsächliche Radgeometrie hinzufügen und den Code für die Radpositionierung schreiben, um Ihre Einstellungen in der Vorschau anzuzeigen. Es ist einfach alles eingebaut.
PhysX3 ist nun für den Betrieb auf Multicores vorbereitet, da das interne Berechnungsmodell in Tasks organisiert ist, die auf verschiedenen Kernen ausgeführt werden können. Das SDK übernimmt das gesamte Multithreading, kümmert sich selbst um alle Abhängigkeiten und sorgt für eine optimale Auftragszerlegung.
Nach dem, was wir bisher gesehen haben, kann man davon ausgehen, dass sich die Leistung im Allgemeinen verdoppelt, weil wir eine bessere Codebasis und ein verbessertes Multithreading haben. In einigen Fällen ist die Verbesserung dramatisch, mit bis zu zehnfachen Verbesserungen.
Leistungs-Ninjas, die sich für weitere Daten interessieren, sollten den Blog von Pierre Terdiman besuchen. Er ist der Hauptentwickler hinter dem PhysX SDK.
Die neuen Funktionen sehen aus wie Unity und fühlen sich auch so an, aber es gibt immer noch Fälle, in denen sich das Verhalten unterscheidet, Parameter unterschiedliche Bedeutungen haben oder in einigen Fällen alte Verhaltensweisen nicht mehr unterstützt werden. Daher ist die Unity 5.0-Physik nicht zu 100% mit Unity 4.x kompatibel. Stellen Sie sich darauf ein, Ihre alten Projekte zu überarbeiten und einen Teil Ihres Physik-Codes neu zu schreiben, wenn Sie von früheren Unity-Versionen migrieren.
Es gibt viel mehr Details über die Physik in Unity 5, als ich in diesem Beitrag mitteilen kann. Fragen können Sie gerne in den Kommentaren stellen. Wenn Sie dieses Jahr unsere Entwicklerkonferenz Unite 2014 besuchen, können Sie sich meinen ausführlichen Vortrag über Physik in Unity 5.0 ansehen und sich mit mir unterhalten.