Unity Technologies plant für Unity 5 einen Wechsel auf PhysX 3.3. Der offizielle Beitrag vom 8. Juli 2014 beschreibt Verbesserungen bei Kollisionen, Mehrkernverarbeitung, Kleidungssimulation und Fahrzeugen.
PhysX 3.3 für mehr Körper und bessere Kollisionen
Unity ersetzt die bisher angepasste PhysX-Version 2.8.3 durch die neu aufgebaute Version 3.3. Bewegte statische Collider sollen dadurch weniger Leistung kosten, weil Unity für statische und dynamische Collider dieselbe Datenstruktur verwendet. Die bisherige Speicherersparnis statischer Collider fällt dabei teilweise weg.
Auch die kontinuierliche Kollisionsabfrage wird überarbeitet. PhysX 3 erzeugt die erforderlichen Daten für schnelle Bewegungen und entscheidet abhängig von der Geschwindigkeit, wann die aufwendigere Berechnung benötigt wird. Unity nennt als Beispiele schnelle Geschosse und Billardkugeln. Auf Desktop-Plattformen sollen außerdem mehrere hunderttausend Rigidbodies in einer Bildberechnung möglich werden. Die frühere Grenze lag bei 64.000 Körpern.
Cloth und Fahrzeuge mit neuen Komponenten
Für Kleidung ersetzt Unity die bisherigen InteractiveCloth- und SkinnedCloth-Komponenten durch eine neue Cloth-Komponente. Die Simulation läuft mehrfädig und reagiert nur auf Collider, die ein Entwickler ausdrücklich zuweist. Die Komponente kann mit Kugel-, Kapsel- und konischen Kapsel-Collidern arbeiten. Eine GPU-Unterstützung über CUDA ist laut Unity vorgesehen, soll aber erst später in der Unity-5-Reihe folgen.
Das neue Vehicle SDK von PhysX 3 bildet die Grundlage für den überarbeiteten WheelCollider. Unity verspricht eine realistischere Federung und Reifenreibung. Die Einstellungen für Federweg und Zielposition lassen sich im Editor mit einem aktualisierten Gizmo prüfen. Die Berechnung von PhysX 3 ist außerdem auf mehrere Prozessorkerne ausgelegt. Unity erwartet je nach Szenario eine Verdopplung der Leistung, in einzelnen Fällen auch deutlich größere Zugewinne.
Alte Projekte müssen geprüft werden
Die neue Physik ist nicht vollständig kompatibel zu Unity 4.x. Parameter und Verhaltensweisen können sich ändern, deshalb müssen bestehende Projekte nach dem Umstieg erneut abgestimmt werden. Frühere Unity-Artikel zur Testbarkeit von MonoBehaviours zeigen, wie stark technische Änderungen an der Engine auch den Entwicklungsprozess berühren.