Leistungssteigerung der Oculus-VR Fork Game-Engine

Unreal Engine stellt zahlreiche Funktionen für die Leistungsoptimierung⁠ bereit. Einige von ihnen bieten jedoch auf Quest und anderen MR-Geräten nur begrenzte Leistungsvorteile.

Der Oculus-VR-Fork⁠ unterstützt weitere Funktionen zur Leistungsoptimierung, da die Unreal Game-Engine speziell für Quest und andere MR-Geräte verbessert wurde.

Unreal Engine 5 (UE5) verwendet LightGrid, eine forward+-Shading-Technik, für dynamische lokale Lichter. Die aktuelle LightGrid-Implementierung in UE5 ist jedoch auf Mobilgeräten sehr leistungsintensiv, insbesondere auf Quest.

Ab v72 ist LightGrid optimiert, indem alle Beleuchtungsdaten in Uniform Buffer Objects (UBOs) verpackt werden, anstatt Shader Storage Buffer Objects (SSBOs) zu verwenden. Mit dieser Veränderung wurde die Leistung deutlich verbessert.

Die GPU-Hardware bietet nur begrenzten Platz für konstante Puffer zur Speicherung von UBO-Daten. Daher kann der konstante GPU-Puffer nur eine begrenzte Anzahl an dynamischen lokalen Lichtern enthalten. Standardmäßig werden 32 Lichter unterstützt, definiert durch GMaxForwardMovableLights. Mit einem niedrigeren Wert spart die GPU Pufferspeicherplatz für andere Uniform-Pufferdaten, und ein höherer Wert kann die Leistung beeinträchtigen, da der konstante Puffer stärker beansprucht wird.

Hinweis: GMaxForwardMovableLights ist eine hardcodierte Konstante und keine CVar. Wenn du diesen Wert änderst, musst du den UE5-Quellcode neu kompilieren.

Diese Funktion ist standardmäßig aktiviert.

Folgender neuer CVar-Parameter wird eingeführt:

r.Mobile.PackLightGridLightDataToUBO.Enable (Standardwert 1) LightGrid-Beleuchtungsdaten in UBOs verpacken.

Ohne dynamische lokale Lichter und ohne Reflexionserfassung wird der LightGrid-Durchgang auf Mobile Forward+ außerdem automatisch übersprungen, was etwa 0,14 ms an GPU-Zeit einspart. Diese Optimierung ist in die Engine integriert und erfordert keine separate CVar.

Leistungstests haben eine Verbesserung der GPU App Time zwischen 3 und 22,5 % im Vergleich zur standardmäßigen LightGrid-Implementierung in UE5 ergeben.

Wie oben besprochen sind die dynamischen lokalen Lichter im standardmäßigen UE5-LightGrid für Quest problematisch. Selbst mit der oben gezeigten Optimierung kann es vorkommen, dass das LightGrid-Shading zu aufwändig ist, insbesondere, wenn die gesamte Szene nur eine geringe Anzahl an dynamischen lokalen Lichtern enthält.

Der Oculus-VR-Fork umfasst eine alternative Implementierung von dynamischen Punkt- und Spotlichtern für den mobilen Renderer. Diese Implementierung bindet Lichter über Uniforms an einzelne beleuchtete Draw-Aufrufe (klassisches Forward-Shading) und deaktiviert das standardmäßige LightGrid (Forward+-Shading).

Bei Leistungstests wurde in manchen Szenen ein Leistungsunterschied von 10 bis 15 % im Vergleich zu LightGrid auf Quest 3 gemessen.

In bestimmten Fällen kann diese Änderung den Arbeitsaufwand im Draw-Thread erhöhen. Es gibt eine harte Grenze von acht Lichtern pro Draw Call, die mit einem unten aufgeführten CVar-Wert geändert werden kann. Für Fälle mit einer geringen Anzahl von Lichtern können spezielle Shader mit einer entrollten Beleuchtungsschleife verwendet werden, die mit dem unten beschriebenen CVar-Wert angepasst werden kann.

Du findest diese Konfiguration unter System Settings >> Rendering >> Mobile >> Enable uniform local lights support on mobile forward.

Folgende neue CVar-Parameter werden eingeführt:

r.Mobile.UniformLocalLights.Enable (Standard False)

r.Mobile.UniformLocalLights.NumUnrolledLights (Standard 0)

r.Mobile.UniformLocalLights.MaxLights (Standard 8)

Hinweis: Dieser Wert darf nicht größer als 8 sein. Wenn mehr als 8 Lichter vorhanden sind, werden überzählige Lichter in unsortierter Reihenfolge verworfen. Wenn du diese Einstellung änderst, erhöht sich die Anzahl der Shader-Permutationen und PSOs erheblich.

Hinweis: Diese Funktion ist NICHT mit GPUScene kompatibel.

Diese CVar-Parameter sind allesamt schreibgeschützt. Wenn du sie änderst, musst du die mobilen Shader neu erstellen.

Emulierte Uniform-Buffer wurden ursprünglich im OpenGL-Backend eingeführt, um Low-Spec-Mobilgeräte in der Unreal Engine zu unterstützen. Sie fassen Constant-Puffer zu einem einzigen globalen Uniform-Puffer zusammen, um die Shader-Optimierung zu verbessern. In UE5 wurden emulierte Uniform-Puffer aufgrund der Umstellung auf den DXC-Compiler aus der Engine entfernt.

In einigen Szenen bieten emulierte Uniform-Puffer jedoch einen beträchtlichen Geschwindigkeitsvorteil gegenüber „echten“ Uniform-Puffern. Leistungstests haben in einigen Szenen auf Quest 3 einen Unterschied von 5 % ergeben.

Version 65 des Oculus-VR-Fork unterstützt emulierte Uniform-Puffer (EUB).

Um diese zu aktivieren, gehe zu System Settings >> Rendering >> VR >> Enable Emulated Uniform Buffers.

Hinweis: Die zugrunde liegende Einstellung r.Vulkan.UseEmulatedUBs wird während der RHI-Initialisierung auf Basis dieser Projekteinstellung konfiguriert und ist keine Runtime-Konsolenvariable.

Hinweis: EUB ist NICHT mit GPUScene oder LateLatching kompatibel.

Qualcomm Adreno GPUs verfügen über einen schnellen Hardwarepfad für Verdeckungsabfragen, der eine wesentliche Verbesserung darstellt. Diese wurde in den Oculus-VR-Fork integriert und verbessert die Unreal Engine 5.4 Hardware Occlusion Queries⁠ (Unreal Engine 5.4 Hardware-Verdeckungsabfragen) weiter.

Leistungstests haben in einigen Szenen einen Leistungsunterschied von 5 % gegenüber der Standard-Verdeckungsabfrage auf Quest 3 gemessen.

Hinweis:r.NeverOcclusionTestDistance ist für die Android-Plattform auf 2.000 voreingestellt. Das bedeutet, dass Objekte, die näher als 2.000 cm sind, nicht an die Verdeckungsabfrage gesendet werden. Das muss möglicherweise von Fall zu Fall sorgfältig abgestimmt werden.

Folgende neue CVar-Parameter werden eingeführt:

r.Mobile.AdrenoOcclusionMode (Standard 1)

Unreal Engine 4 (UE4) hat in der Vergangenheit Software Occlusion⁠ unterstützt. Diese Funktion wurde in Unreal Engine 5 (UE5) entfernt und mit Occlusion Query⁠, einer GPU-basierten Lösung, ersetzt. Occlusion Query bietet jedoch in GPU-intensiven Spielen möglicherweise keine optimale Performance.

Mit dem Release v77 wurde Software Occlusion wieder in den Oculus-VR-Fork eingeführt. Dieser Abschnitt zeigt die Unterschiede zwischen der aktuellen Implementierung und der ursprünglichen UE4-Funktion. Informationen zum allgemeinen Verhalten von Software Occlusion findest du in der UE4-Dokumentation.

Um die Software Occlusion zu aktivieren, rufe die Systemeinstellungen auf und aktiviere Support Custom Occlusion Culling (CVar: r.Mobile.AllowCustomOcclusion).

Im Gegensatz zu UE4 verwendet diese Implementierung Occluder Mesh Asset-Nutzer*innen-Daten für die Zuweisung von Occluder Meshes an ein übergeordnetes Mesh (Static Mesh, Skeletal Mesh oder Instanced Static Mesh). Zur Festlegung von Occluder Meshes stehen zwei Methoden zur Verfügung, wobei aber nur jeweils eine verwendet werden kann:

Für einfaches Testen kann die Software Occlusion im Editor über die Option Support Testing Custom Occlusion Culling with Deferred Pipeline in den Systemeinstellungen aktiviert werden (CVar: r.TestDeferred.AllowCustomOcclusion). Mit r.SO.VisualizeBuffer 1 kannst du den Software Occlusion-Puffer darstellen.

Hinweis: Diese Einstellung dient nur zu Testzwecken und sollte in Produktions-Builds nicht aktiviert werden.

Die Konfiguration von Occluder Meshes kann eine Herausforderung darstellen, speziell bei der Ermittlung von Skalierungs- und Offset-Werten. Du kannst den Software Occlusion-Visualizer aktivieren, um diesen Prozess signifikant zu vereinfachen.

Es ist zwar möglich, ein Occluder Mesh zu einem Skeletal Mesh hinzuzufügen. Dabei müssen Entwickler*innen aber darauf achten, dass das Occluder Mesh auf nicht-animierte Teile angewendet wird und innerhalb der Mesh-Silhouette verbleibt, da ansonsten möglicherweise inkorrekte Verdeckungen oder flackernde Artefakte auftreten können.