Unreal Engine 5 Nanite-Architektur: Umfassende Technische Analyse, Optimierungsstrategien und PlayStation 5 Entwicklungsleitfaden

Grundlagen der virtualisierten Mikropoligon-Geometrie und der Paradigmenwechsel

Eine der langlebigsten Einschränkungen in der Industrie für Echtzeit-Rendering-Technologien (real-time rendering) und Computergrafik seit Jahrzehnten sind die unvermeidlichen Engpässe bei der Kommunikation zwischen Prozessor (CPU) und Grafikprozessor (GPU) aufgrund von Polygonbudgets und Draw-Call-Zahlen im Interesse einer effizienten Nutzung der Hardware-Ressourcen. 1 In traditionellen Spieleentwicklungs-Workflows war es für 3D-Künstler und technische Direktoren zwingend erforderlich, manuelle Topologie-Optimierungen durchzuführen, Level-of-Detail-Ketten (LOD-Ketten) zu erstellen und hochauflösende Details in Normal Maps zu backen, um hochdetaillierte Modelle (z. B. kinoreife ZBrush-Skulpturen, Laserscans oder Photogrammetriedaten) in Spiel-Engines zu importieren. 1 Dieser Prozess erzeugte nicht nur eine mühsame Arbeitslast, die den Produktionszeitplan verlängerte, sondern schränkte auch den Detailgrad auf dem Bildschirm durch Speicherbeschränkungen künstlich ein. 1 Die Nanite-Technologie, die mit der Unreal Engine 5 (UE5) zum Industriestandard geworden ist, ist ein System für virtualisierte Mikropoligon-Geometrie (virtualized micropolygon geometry), das diese traditionellen Hindernisse grundlegend beseitigt. 1 Nanite befreit Polygonbudgets von ihrer Rolle als technische Einschränkung und ermöglicht es, Quelldateien direkt in Filmqualität, bestehend aus Milliarden von Polygonen, in Echtzeit in die Szene zu übertragen, ohne dass manuelle LOD-Prozesse erforderlich sind. 1 Das System ist so konzipiert, dass es auf dem Bildschirm nur jene Details verarbeitet, die zu diesem Zeitpunkt von der Kamera des Spielers tatsächlich gesehen werden; kein Dreieck und kein Geometrieteil, das kleiner als die Pixelgröße ist, wird unnötig gerendert. 3 Diese Technologie bietet ein kontinuierliches, flüssiges und unterbrechungsfreies automatisches LOD-System und ersetzt die traditionelle Rendering-Pipeline vollständig durch eine GPU-fokussierte Daten-Streaming-Architektur. 1 Die wichtigsten Innovationen von Nanite lassen sich in vier Hauptpunkte unterteilen 1:

1. Virtualisierte Geometrie: Die gesamte Szene wird wie ein einziges, massives statisches Mesh (Static Mesh) behandelt, und nur die Teile, die auf dem Bildschirm sichtbar sind, werden in die Verarbeitung einbezogen.

2. Automatisches Detail Level (LOD): Anstelle von schrittweisen und abrupten LOD-Wechseln (LOD Popping) wird ein nahtloser, flüssiger Detailwechsel in Abhängigkeit von Entfernung und Bildschirmauflösung bereitgestellt.

3. GPU-fokussierte Pipeline: Draw Calls und Culling-Operationen werden von der CPU übernommen und an die parallele Rechenleistung der GPU übergeben.

4. Effizientes Streaming: Durch direktes Daten-Streaming über SSD wird nur die benötigte Geometrie-Data augenblicklich in den Speicher geladen.

Dieser Forschungsbericht untersucht in einem umfassenden analytischen Rahmen die tiefgehenden Funktionsprinzipien des Nanite-Systems, die notwendigen Schritte für die Projektintegration, Optimierungsanforderungen, die Überwindung von Engpässen und insbesondere die Spielentwicklungsdynamik für die PlayStation 5 (PS5)-Plattform, die über eine hardwareseitige, einzigartige Komprimierung und Hochgeschwindigkeits-Daten-Streaming (I/O) verfügt.

Technische Architektur und Datenstrukturen von Nanite

Die Philosophie im Kern des Nanite-Systems besteht darin, Geometriedaten nicht als massive Statische Meshes zu betrachten, die in Speicherlimits gepresst werden müssen, sondern als granulare Datensätze, die wie bei virtuellen Texturen (virtual texturing) dynamisch gestreamt und bei Bedarf verwaltet werden. 3 Während traditionelle Engines versuchen, ein ganzes Objekt in den Speicher zu laden und zu verarbeiten, selbst wenn nur ein kleiner Teil davon im Sichtfeld (Frustum) der Kamera liegt, bewertet Nanite diese Sichtbarkeit mit millimetergenauer Pixelpräzision. 3

Hierarchische Cluster-Struktur (Hierarchical Cluster Structure)

In der Importphase analysieren Nanite-Algorithmen 3D-Modelle und unterteilen sie in hierarchische Cluster-Bäume. 1 Jedes verarbeitete Statische Mesh wird in kleine Datenpakete (Cluster) mit exakt 128 Dreiecken aufgeteilt, um auf Hardware-Ebene die beste Leistung zu erzielen. 1 Diese feste Größe von 128 Dreiecken ist eine speziell gewählte optimale Einheit, die genau zu den Wavefront- oder Warp-Größen moderner GPUs passt und eine maximale Verarbeitungseffizienz aus parallelen Verarbeitungseinheiten und Cache-Grenzen (cache limits) herausholt. 1 Diese Cluster bilden untereinander eine Baumdatenstruktur ähnlich einem gerichteten azyklischen Graphen (Directed Acyclic Graph – DAG), die Bounding-Box-Informationen, geometrische Fehlermetriken für die LOD-Auswahl im Bildschirmraum (screen space) sowie Eltern-Kind-Beziehungen (parent-child) enthält. 1 Wenn sich die Kamera dem jeweiligen Objekt nähert oder sich entfernt, navigiert das System in Echtzeit durch diese Baumstruktur und entscheidet für jeden Bildschirmbereich, welcher Cluster am besten zur PixelDichte auf dem Bildschirm passt. 1 Im Gegensatz zu herkömmlichen Ansätzen ändert sich das Objekt nicht plötzlich als Ganzes. Anstelle eines abrupten LOD-Wechsels können verschiedene Bereiche auf der Objektoberfläche gleichzeitig auf unterschiedlichen Cluster-Detailstufen verarbeitet werden und sich an den Rändern so glatt verbinden, dass bei der Hardware-Rasterisierung keinerlei visuelle Risse oder Spalten (cracks) entstehen. 3

Sichtbarkeitspuffer (Visibility Buffer) und entkoppeltes Shading

Die kritischste Struktur, die es Nanite ermöglicht, CPU-Engpässe zu überwinden und moderne Rendering-Architekturen zu revolutionieren, besteht darin, einen großen Teil der Rendering-Pipeline direkt auf die GPU zu verlegen und die traditionelle Forward- oder Deferred-Shading-Logik durch einen „Visibility Buffer“ (Sichtbarkeitspuffer) zu ersetzen. 1 Das Konzept des Sichtbarkeitspuffers in der Rendering-Schleife von Nanite funktioniert wie folgt: In traditionellen G-Buffer-Strukturen werden bei der Pixelberechnung riesige Datenmengen wie Farbe, Normale und Rauheit (roughness) für jedes Pixel in den Speicher geschrieben. Nanite hingegen speichert für jedes Pixel auf dem Bildschirm lediglich eine Identifikationsnummer (Primitive ID und Cluster ID) in einer Größe von 32-Bit oder 64-Bit. 1 Dieser Puffer-Speicher enthält keine Farb- oder Shading-Daten, sondern ist lediglich eine Referenzkarte, die anzeigt, welches Dreieck und welcher Cluster in diesem spezifischen Pixel auf dem Bildschirm sichtbar ist. 1 Nach vollständiger Füllung des Sichtbarkeitspuffers werden die Materialdaten für jedes Pixel im Bildschirmbereich nur einmal aufgerufen und der Shading-Vorgang wird durchgeführt. Dank dieser „entkoppelten“ (decoupled) Architektur werden keine unnötigen Materialberechnungen für Millionen von Dreiecken durchgeführt, die sich hinter der Kamera befinden, hinter einem anderen Objekt versteckt sind oder keinen Beitrag zum finalen Bild leisten. Dieser Umstand eliminiert das Problem des „Overdraw“ (Überzeichnung), einem der größten Feinde der GPU, auf Basis der Materialberechnung vollständig. 9

GPU-fokussierte Culling-Mechanismen

In der Nanite-Architektur erfolgt das Culling (Aussortieren) nicht wie in traditionellen Engines auf Basis von Objekten (Actors) auf der CPU. Traditionelle Draw-Call-Vorbereitungen auf der CPU-Seite werden vollständig umgangen, und der Culling-Prozess wird direkt an Compute Shader innerhalb der GPU übergeben. 10 In der Phase des Okklusions-Cullings (Occlusion Culling) verwendet Nanite eine Struktur namens HZB (Hierarchical Z-Buffer), in der verschiedene Tiefenstufen (Mipmaps) im Bildschirmraum logarithmisch gespeichert sind. 9 Der HZB vergleicht die Bounding Box jedes 128-Dreiecke-Clusters mit den Tiefendaten im Bildschirmraum. 9 Wenn sich ein Cluster hinter einem anderen Objekt in der Szene befindet, wird er sofort aus dem Renderprozess entfernt. Dieses Culling ist so präzise, dass – da es clusterbasiert und nicht objektbasiert erfolgt – bei Bäumen in einem riesigen Wald hinter einem riesigen Berg nur die Cluster aussortiert werden, die sich hinter dem Berg befinden, während die Blättercluster, die über die Bergspitze hinausragen, weiterhin verarbeitet werden. 8

Rasterisierungspfade: Software- und Hardware-Verarbeitungsdynamiken

Anstatt eine einzige Verarbeitungseinheit zur Umwandlung von Dreiecken in Bildschirmpixel (Rasterisierung) zu verwenden, nutzt Nanite zwei separate Rasterisierungspfade (raster paths), über die dynamisch basierend auf der Bildschirmgröße des Dreiecks und den Materialeigenschaften entschieden wird. 9 Die Leistungsoptimierung beruht darauf, ein perfektes Gleichgewicht zwischen diesen beiden Pfaden herzustellen.

Software-Rasterisierung (Software Raster Path)

Die Software-Rasterisierung ist der effizienteste, schnellste und innovativste Kernverarbeitungspfad von Nanite. 9 Dieser Pfad greift, wenn Dreiecke auf dem Bildschirm kleiner als ein Pixel (Sub-Pixel) oder exakt so groß wie ein Pixel sind. 9 In diesem Szenario umgeht Nanite die Hardware-Dreieckszeichnungseinheiten der GPU vollständig und führt den Prozess über „Compute Shader“ aus. Unter Verwendung von 64-Bit-atomaren Operationen (atomic interlocks) wird sichergestellt, dass Pixel mit außergewöhnlicher Geschwindigkeit in den Sichtbarkeitspuffer geschrieben werden. Wenn der Visualisierungsmodus für Raster-Bins über die Entwicklerkonsole mit dem Befehl r.Nanite.Visualize.Advanced 1 oder r.nanite.showmeshdrawevents 1 aktiviert wird, werden Cluster, die die Software-Rasterisierung durchlaufen, in Blau dargestellt. 9 In einer gut optimierten Szene sollte angestrebt werden, dass die überwältigende Mehrheit der Geometrie blau ist. 9

Hardware-Rasterisierung (Hardware Raster Path)

Die Hardware-Rasterisierung ist die klassische GPU-Zeichnungsmethode, die dann aktiviert wird, wenn Dreiecke größer als ein Pixel auf dem Bildschirm sind oder wenn spezielle Materialeigenschaften verwendet werden, die von der Compute-basierten Software-Rasterisierung von Nanite nicht verarbeitet werden können. 9 Dieser Pfad wird in den Visualisierungsmodi in Rot angezeigt. 9 Es ist normal, dass das System zur Hardware-Rasterisierung wechselt, insbesondere wenn sich die Kamera einer riesigen Wand nähert, da Dreiecke dadurch größer als Pixel werden. 9 Wenn jedoch weit von der Kamera entfernte Objekte oder Mikropoligon-Geometrien weiterhin in Rot angezeigt werden, weist dies auf einen „Hardware Fallback“ (Hardware-Rückfall) hin, was ein schwerwiegendes Optimierungsproblem darstellt. 9 Der Hauptgrund für unerwünschte Rückfälle zur Hardware-Rasterisierung ist die Verwendung von maskierten (masked), transparenten oder komplexen Verformungs-Offsets zugehörigen Materialien. 9

Raster-Bins und Materialverwaltung

Das Herzstück der Nanite-Leistung hängt weniger von der Geometrie selbst ab, sondern vielmehr davon, wie die auf die Geometrie angewendeten Materialien auf virtuelle Boxen namens „Raster Bins“ verteilt werden. 9 Nanite fasst alle Materialien, die standardmäßig opak sind und keinen Pixel-Depth-Offset (PDO) oder World-Position-Offset (WPO) enthalten, in einem einzigen riesigen Raster-Bin zusammen, und das System verarbeitet diesen Bin blitzschnell in einem einzigen Durchgang (Pass). 9 Wenn jedoch Materialien verwendet werden, die eine Verschiebung (Displacement), Maskierung (Masked/Alpha Test) oder intensive WPOs für Windeffekte aufweisen, führt dies dazu, dass diese Objekte aus dem schnellen Durchgangspfad von Nanite herausgenommen und für jeden Materialtyp ein eigener, unabhängiger Raster-Bin erstellt wird. 9

LeistungsklasseMaterialtyp und -eigenschaftNanite-Auswirkung und VerarbeitungsstatusStrategische EntwicklerempfehlungBeste (Best)Opaque (Opak), reine Materialien ohne WPO, PDO oder Displacement-Offset.Wird in einem einzigen Raster-Bin gemischt. Die Software-Rasterisierung arbeitet aktiv, die Draw-Call-Kosten gehen gegen Null.9Mehr als 90 % des Umgebungsdesigns, der Gebäude und der harten Oberflächen (Hard Surfaces) im Projekt sollten definitiv aus diesem Typ bestehen.9Gute (Good)Opaque (Opak), aber mit minimalem WPO (World Position Offset).Da WPO verwendet wird, beginnen statische Cluster, separat auf der GPU berechnet zu werden. Da sich Bounding Boxes aufgrund von Bewegungen verändern, wird das Culling erschwert.Um eine Beschädigung der Bounding Box und fehlerhaftes Culling zu verhindern, muss die WPO-Bewegungsdistanz unbedingt limitiert werden (Clamp).3 Statische Verformungen sollten gebacken (baked) werden.9Mittlere (Okay)Masked (Maskiert/Transparente Kanten, Alpha Cutout).Fällt zwangsläufig auf den Hardware-Rasterisierungspfad (Hardware Raster Path) zurück. Erzeugt einen heftigen „Overdraw“ (Überzeichnung) durch die kontinuierliche Auswertung leerer Pixel.Wird für klassische Blatt- oder Zaunmodellierungen verwendet, sollte jedoch sehr sparsam eingesetzt werden, da es die Leistung stark beeinträchtigt.8Schlechteste (Worst)Komplex verformte Materialien (Intensive WPO + PDO).Jede Variation erstellt einen eigenen Raster-Bin. Erhöht State-Änderungen und treibt Frame-Zeiten sofort über die Budgetgrenzen.Sollte bei Objekten in großen Entfernungen unbedingt sofort abgebrochen (LOD Fallback) oder auf modernere Alternativen wie Nanite Skinning, eingeführt mit UE 5.7, ausgewichen werden.9

Die Entstehung zu vieler Raster-Bins bedeutet auf der GPU ansteigende State-Änderungen (Zustandsänderungen) und erhöhte Draw-Call-Variationen, was die GPU erheblich verlangsamt.9 In einem Projekt, das mit 60 FPS anvisiert wird (16,66 ms pro Frame), ist es zwingend erforderlich, dass die VisBuffer-Operation unter 4 ms und die BasePass-Operation unter 3 ms gehalten wird; andernfalls bleibt keine Zeit für andere Systeme wie Post-Processing, Lumen und Künstliche Intelligenz.7

Nanite-Integration: Verwendung in Projekten

Die Nanite-Integration ist so konzipiert, dass sie sich mit minimalem Aufwand in bestehende Unreal Engine-Spielentwicklungsworkflows einfügt. Dieses System, das manuelle LOD-Erstellungsprozesse der alten Generation oder das Normal Map-Baking überflüssig macht, optimiert bei korrekter Konfiguration die Leistung automatisch.1

Geometrietypen und unterstützte Komponenten

Damit eine Geometrie von den Nanite-Funktionen profitieren kann, muss diese Funktion während der Importphase oder nachträglich über den Static Mesh Editor aktiviert werden.3 In aktuellen Versionen von Unreal Engine 5 wurden die von Nanite unterstützten Component-Typen stark erweitert:

● Statische Meshes (Static Meshes): Jedes in das Projekt integrierte Static Mesh kann im Editor durch das Markieren der Option „Enable Nanite Support“ konvertiert werden. In riesigen Szenen mit Tausenden von Objekten kann die gesamte Bibliothek über den Content Browser durch eine Mehrfachauswahl (Batch-Enable) gleichzeitig in das Nanite-Format überführt werden.3 Statische Meshes sind die primäre Zielgruppe des Nanite-Systems.

● Skelett-Meshes (Skeletal Meshes): Während in frühen UE5-Versionen nur statische Objekte unterstützt wurden, können dank der Skeletal Mesh API-Unterstützung in Version 5.3 und späteren Versionen nun auch dynamisch deformierte (animierte) Charaktere, Kreaturen und Fahrzeuge mit Nanite verwendet werden.3 Die größte Neuerung für Skelett-Meshes ist, dass für das gesamte Mesh nur ein einziger Draw Call (One Draw Call) erzeugt wird. Nanite Skeletal Meshes arbeiten mit Animations-LODs anstelle von klassischen Geometrie-LODs.3

● Spline-Meshes (Spline Meshes) und Landschaft (Landscape): Nanite unterstützt nativ Spline-Meshes, die ihre Form entlang von Kurven wie Straßen, Pipelines und Wänden verändern, sowie die Topologie von großen Open-World-Landscapes (über Nanite Tessellation).3 Kleine Displacement-Details auf Böden können direkt über Materialien erzielt werden, ohne polygonale Dichte zu erzeugen und ohne die Leistung zu beeinträchtigen.3

● Instanziierte Meshes (Instanced Static Meshes - ISM / HISM): Objekte mit Millionen von Kopien (zum Beispiel Steine in einem riesigen Wald oder Ziegelsteine von Gebäuden) werden dank des Sichtbarkeitspuffers von Nanite mit einem einzigen Speicherfootprint gerendert. Es ist jedoch zu beachten, dass die maximale Anzahl an Nanite-Instanzen in einer Szene hardwarebedingt auf 16 Millionen begrenzt ist.3

Erstellung und Rolle des Fallback Mesh (Ersatz-Mesh)

Wenn beim Erstellen von Nanite-Daten das Kontrollkästchen „Build Nanite“ aktiviert wird, generiert die Engine neben dem hochdetaillierten Mesh automatisch eine vereinfachte Geometrie mit traditioneller Polygonanzahl, das sogenannte „Fallback Mesh“ (Ersatz-Mesh).13

Die Existenz dieses Ersatz-Meshes ist von vitaler Bedeutung: Das GPU-zentrierte Rasterisierungssystem von Nanite kann nicht direkt für komplexe physikalische Kollisionsberechnungen, mit Lightmass vorab berechnete Lichtkarten (Baked Lighting) und vor allem für Hardware-Raytracing-Reflektionen (Hardware Raytracing / Lumen HWRT) verwendet werden.13 Die logischen Systeme der Spielart auf der CPU-Seite benötigen diese traditionellen Dreiecksdaten. Der Detaillierungsgrad des Ersatz-Meshes kann durch Ändern des Parameters „Fallback Relative Error“ (Fallback-relativer Fehler) gesteuert werden.3 Je geringer die Fehlerrate ist, desto höher ist die Polygonanzahl des Ersatz-Meshes, was eine präzisere Berechnung der Hardware-Raytracing-Reflektionen (Lumen Hit Lighting) ermöglicht, aber auch den Speicherverbrauch (VRAM) im gleichen Maße erhöht.14

Nanite Foliage: Voxel- und Montage-Systeme (Assembly) mit UE 5.6/5.7

In Spiel-Engines galten bewaldete Gebiete und dichte Vegetation aufgrund der vielen übereinanderliegenden, transparenten (masked) Blattoberflächen seit Jahren als der schwächste Punkt von Nanite.15 Die traditionelle Modellierung von Gras oder Blättern (Alpha Cards) führte zu dem Problem des „Overdraw“, bei dem Pixel wiederholt übereinander ausgewertet werden und das auf den HW Raster fällt.8

Die Versionen Unreal Engine 5.6 und insbesondere 5.7 haben dieses Problem mit dem „Nanite Foliage“-System grundlegend und durch eine architektonische Änderung gelöst 12:

1. Nanite Voxels (Voxel): Die komplexen und Overdraw erzeugenden Blattdreiecke von Bäumen oder Vegetation, die sich von der Kamera entfernen, werden durch Einstellen der Option „Voxelize“ im Menü „Shape Preservation“ in der Ferne in Voxel umgewandelt.17 Ähnlich wie Minecraft-Blöcke werden diese Voxel im Gegensatz zu Dreiecken als volumetrische Pixel verarbeitet, wodurch die Notwendigkeit von Transparenz (Alpha) vollständig entfällt und das Overdraw-Problem auf Hardwareebene verhindert wird.15 Hunderttausende von Bäumen in der Ferne werden äußerst kostengünstig als volumetrische Voxel in der Größe von Bildschirmpixeln verarbeitet, während sie beim Näherkommen nahtlos in Mikropoligone mit vollen Details übergehen.15

2. Nanite Assemblies (Baugruppen): Wenn riesige Bäume in hoher Auflösung modelliert werden, erreichen sie unglaublich große Datenmengen auf der Festplatte und im Arbeitsspeicher. Dank der Nanite Assemblies-Funktion wird jeder Ast, jedes Blatt und jeder Stamm eines Baumes nicht als separates, riesiges Static Mesh eingelesen, sondern als hierarchisches Ganze (Assembly) über den USD-Importer (Universal Scene Description).12 Dank der NaniteAssemblyRootAPI-Schemata, die in Programmen wie Houdini Solaris vorbereitet wurden, handelt es sich bei Tausenden von Blättern im Grunde um instanzierte Versionen desselben kleinen Blatt-Meshes.19 Diese Struktur reduziert den Speicherbedarf unglaublich stark.

3. Nanite Skinning: Herkömmliche WPO-basierte (World Position Offset) Windanimationen erforderten eine kontinuierliche Neuberechnung auf CPU/GPU (Culling Invalidation) in jedem Frame, da sich die Bounding Box jedes Clusters in jedem Frame änderte.15 Mit dem in UE 5.7 eingeführten Nanite Skinning werden Bäume als Skeletal Mesh importiert; physikalische und prozedurale Windeffekte werden über Knochen (Bones) mithilfe des „Dynamic Wind“-Plugins berechnet.12 Dadurch bietet Nanite weitaus organischere und konsistentere Windinteraktionen, ohne Kompromisse bei der Raster Bins-Leistung einzugehen. Die neue Quixel Megaplants-Bibliothek und der Procedural Vegetation Editor (PVE) nutzen diese Technologien vollständig integriert, um das Erreichen von 60 FPS-Zielen problemlos zu ermöglichen.15

Optimierungsprozesse: Was ist zu beachten?

Obwohl Nanite zur Leistungssteigerung entwickelt wurde, ist das Versprechen von „unendlichen Polygonen“ kein Wundermittel. Bei falscher Anwendung und Nichteinhaltung der Hardware-Grenzen handelt es sich um ein komplexes System, das die Frame-Zeiten ernsthaft gefährden kann.11

Transparenz (Translucency), Maskierung und Overdraw-Problem

Bei der herkömmlichen Spieloptimierung (UE4 und früher) war es ein Standardansatz, ein detailliertes Objekt durch das Überziehen von transparenten Masken (Alpha Texture / Masked Material) auf Oberflächen mit niedriger Polygonsignatur zu simulieren.8 In der Nanite-Architektur ist dieser Ansatz jedoch völlig falsch und führt zu katastrophalen Ergebnissen.8

Nanite benötigt zusätzliche Hardwareschritte, um transparente (leere) Pixel beim Berechnen des Sichtbarkeitspuffers zu überspringen. Wenn maskierte Materialien hintereinander angeordnet sind (zum Beispiel ein Maschendrahtzaun oder Baumblätter), muss das System die Tiefe und Transparenz desselben Pixels Dutzende Male lesen und verarbeiten, was als „Overdraw“ bezeichnet wird.10

Kritische Regel: Im Nanite-System ist „Geometrie sehr günstig, aber Transparenz sehr teuer“. Anstatt ein maskiertes Material (Masked Material) zu verwenden, wenn perforierte Objekte wie Blätter, Zäune oder Netze erstellt werden, sollte die Form bei Bedarf mit Hunderttausenden von zusätzlichen Polygonen vollständig modelliert (Fully Modeled) und das Material unbedingt auf „Opaque“ eingestellt werden.8 Ein vollständig modellierter Baum wird viel schneller gerendert als eine maskierte flache Ebene (Plane).

Integration von Virtual Shadow Maps (VSM)

Herkömmliche Shadow Maps (Cascaded Shadow Maps - CSM) können sich nicht an das enorme Detaillierungsgrad auf Mikropoligonebene anpassen, das Nanite-Objekte bieten. Virtual Shadow Maps (VSM), die speziell für die Verwendung mit Nanite entwickelt wurden, bieten messerscharfe Schatten, indem sie die Schattenauflösung dynamisch an die Bildschirmpixel anpassen.23

VSM erfordern natbedingt einen hohen VRAM-Speicherbedarf. Wenn sich ein Schatten werfendes Objekt ständig bewegt (zum Beispiel Blätter, die sich durch WPO bewegen), wird der VSM-Schatten-Cache (Shadow Cache) in jedem Frame ungültig gemacht (Invalidated) und die Shadow Map von Grund auf neu berechnet, was zu einem erheblichen FPS-Einbruch führt.22 Daher arbeiten statische Szenen oder Gebäude perfekt mit der Kombination aus Nanite und VSM, während in stark bewegten waldigen Gebieten WPO-Einschränkungen eingeführt oder basierend auf Leistungstests der Übergang zu klassischen Shadow Maps in Betracht gezogen werden sollte.25

Profiling und Befehle zum Auslesen der Leistung

Um die Grundursache von Optimierungsproblemen zu finden und festzustellen, ob ein Flaschenhals auf die CPU oder die GPU zurückzuführen ist, ist es unerlässlich, die in UE5 bereitgestellten internen Profile-Befehle (Stat) regelmäßig und von Projektbeginn an auszulesen (Prinzip „Optimize Early“).26

Die Profile-Befehle und Visualisierungswerkzeuge, die Entwickler regelmäßig verwenden sollten, sind folgende 28:

Profile-Befehl / ModusBeschreibung und VerwendungszweckEntwickleraktionstat unitGrundlegende Engpasserkennung. Zeigt die Gesamtzeit auf dem Bildschirm als Aufschlüsselung in Millisekunden (ms) für „Frame“ (Gesamtzeit), „Game“ (CPU-Spielschleife), „Draw“ (CPU-Render-Vorbereitung) oder „GPU“ an.28Wenn die GPU-Zeit 16,66 ms überschreitet, sollten grafische Einschränkungen vorgenommen werden; wenn die Game-Zeit überschritten wird, sollte die Optimierung von Künstlicher Intelligenz oder Blueprint-Ticks erfolgen.

Befehl / WerkzeugFunktion und BeschreibungOptimierungsaktionstat gpu oder stat scenerenderingListet spezifische Render-Lasten innerhalb der GPU auf. Detailliert, wie viel Zeit Nanite BasePass, Lumen, Schatten (Shadow Depths) und Post-Process-Lasten beanspruchen.Wenn Nanite VisBuffer 4 ms oder BasePass 3 ms überschreitet, sollten Raster Bins oder Overdraw überprüft werden.r.nanite.showmeshdrawevents 1Untersucht im GPU Profiler (Ctrl+Shift+,) hierarchisch, wie viel Zeit welches spezifische Nanite-Material und Objekt benötigt.Wird verwendet, um kostspielige WPO-Materialien oder transparente Objekte zu erkennen und zu isolieren.NaniteStatsZeichnet eine Benutzeroberfläche direkt in der Ecke des Bildschirms mit der „ShaderPrint“-Technologie. Filtert live, ob virtuelle Schatten oder das primäre Sichtfeld (Primary View) die Zeichenlast auf Nanite verursachen.Durch Eingabe von Parametern (primary, VirtualShadowMaps) in die Konsole wird die Last aktiver Übergänge ermittelt.View Mode > Nanite Visualization > OverdrawFärbt dichte Bereiche auf dem Bildschirm, in denen sich Pixel überlappen, im Spektrum Blau (gut), Orange und Rot (schlecht) ein.Bereiche mit intensiven transparenten Materialien werden identifiziert und einer vollständigen Modellierungsrevision (Opaque) unterzogen.

PlayStation 5 (PS5) I/O-Architektur und Nanite-Streaming-Beziehung

Bei der Spieleentwicklung für PlayStation 5 ist der einzige Faktor, der das Potenzial von Nanite von theoretischen Grenzen auf den Gipfel der Echtweltleistung hebt, die revolutionäre SSD-Speicher- und Hardwaredekomprimierungsarchitektur der Konsole. Nanite ist nach dem Prinzip des Ladens von 128-Dreiecks-Clustern bei Bedarf (on-demand streaming pages) konzipiert, und die I/O-Hierarchie (Eingabe/Ausgabe) der PS5 befindet sich in perfekter Harmonie mit diesem Design.

Kraken-Hardwarekomprimierung und Oodle-Texture-Integration

In traditionellen PC-Systemen und Konsolen der vorherigen Generation (PS4, Xbox One) müssen komprimierte Daten, die von der Festplatte gelesen werden (mit Allzweckalgorithmen wie ZLIB), zuerst in den RAM geladen und dann vom Hauptprozessor (CPU) dekomprimiert werden. Wenn die gigantischen Größen von Nanite-Clustern aus Milliarden von Polygonen bei jeder Bewegung der Kamera Gigabytes an neuen Daten pro Sekunde (GB/s) anfordern, führt diese Methode der softwarebasierten Dekomprimierung (software decompression) dazu, dass auf PCs und älteren Konsolen die CPU blockiert und Spielmechaniken (KI, Physik usw.) nicht mehr verarbeitet werden können.

Bei der Entwicklung der PS5-Hardware hielt sich Sony nicht an Standards, sondern integrierte einen speziellen Hardwaredekomprimierer-Chip (hardware decompressor block) auf Siliziumebene in den I/O-Komplex, um den von RAD Game Tools entwickelten Oodle-Kraken-Komprimierungsalgorithmus zu dekodieren. Im Vergleich zum ZLIB-Format der vorherigen Generation kann Kraken Daten verlustfrei (lossless) um 29 % kleiner machen, während es bei der Dekomprimierungsgeschwindigkeit 3- bis 4-mal effektiver ist.

Wenn das verlustfreie Format „Oodle Texture“ (zusammen mit Texturkomprimierungsoptimierungen wie BC7Prep) verwendet wird, vergrößert der Kraken-Chip der PS5 die rohe Lesegeschwindigkeit der SSD von 5.5 GB/s durch einen Multiplikatoreffekt und liefert eine Datenübertragung mit unglaublich hohen Bandbreitengeschwindigkeiten von durchschnittlich 8-9 GB pro Sekunde und in der Spitze (Peak) zwischen 17 und 22 GB pro Sekunde.

Überwindung des CPU-Engpasses und des Bandbreitenmultiplikators

Die Bedeutung dieser I/O-Architektur für Nanite ist sehr tiefgreifend. Die folgende Tabelle fasst zusammen, wie viel CPU-Einsparung die Komprimierungstechnologie der PS5 im Vergleich zu Mitbewerbern und älteren Generationen bietet:

Komprimierungshardware und AlgorithmusmetrikPS4 / Vorherige GenerationXbox Series XPlayStation 5Grundlegender KomprimierungsalgorithmusZLIB (Software-fokussiert)BCPack (ZLIB-HW-Variante)Oodle Kraken + Oodle Texture (Benutzerdefinierte HW)Maximale Ausgabegeschwindigkeit (Peak Bandwidth)~100-200 MB/s~6 GB/s (effektiv mit SFS)~22 GB/sDurchschnittliche Ausgabegeschwindigkeit (Average Bandwidth)< 100 MB/s~4.8 GB/s8-9 GB/s (17 GB/s mit Oodle)Prozessor-Äquivalent (CPU) LeistungsersparnisBelastet die CPU vollständigÄquivalent zu ~5 Zen-2-KernenÄquivalent zu ~9 Zen-2-Kernen

Diese Tabelle zeigt deutlich: Der I/O-Komplex der PS5 übernimmt allein den Aufwand, den exakt 9 unabhängige Zen-2-Prozessorkerne auf einem herkömmlichen Computer aufwenden würden, um Daten von einer SSD zu entpacken.

Wenn Nanite in jedem Frame (innerhalb von 16 ms) Zehntausende neuer Cluster (streaming pages) von der Festplatte gemäß dem neuen Blickwinkel der Kamera anfordert, werden diese von der SSD gelesenen Daten über den Hardware-Kraken-Chip unter vollständiger Umgehung der CPU direkt in die RAM- und GPU-Pools eingespeist. Spieleentwickler können die „Virtual Texturing for Geometry“-Philosophie von Nanite voll ausschöpfen, ohne Angst vor „Pop-ins“ (rechtzeitigem Nicht-Erscheinen von Daten) haben zu müssen. Da die Ingenieure von Epic Games dieses massive Potenzial erkannten, haben sie die Kern-Lade-Subsysteme (core I/O subsystems) der Unreal Engine 5 speziell für diese einzigartige I/O-Struktur der PS5 von Grund auf neu geschrieben.

VRAM-Verwaltung und Streaming-Pool-Optimierung

Die PlayStation 5 verfügt über einen ultraschnellen, vereinheitlichten (unified) GDDR6-Speicher mit einer Kapazität von 16 GB. Im Gegensatz zu PC-Architectures sind die Speichergrenzen auf Konsolen jedoch starr und unflexibel (fixed memory); virtuelle Speicherauslagerungen können nicht toleriert werden und führen zum direkten Absturz des Systems (OOM - Out of Memory).

Die von Nanite verwendeten Speicher-Pools (streaming pool) wachsen geometrisch in Abhängigkeit von der Bildschirmauflösung. Nanite verwendet einen Sichtbarkeitspuffer (Visibility Buffer), dessen Größe proportional zur Bildschirmgröße ist, um Dreiecksidentitäten zu speichern. Wenn die Auflösung von 1080p auf 4K steigt (da sich die Anzahl der Pixel vervierfacht), vervierfacht sich auch der VRAM-Bedarf des Visibility Buffers direkt.

Um die Optimierung in PS5-Projekten sicherzustellen und den VRAM zu verwalten, muss die Größe des „Nanite Streaming Pool“ vom Entwickler begrenzt werden. Während die Standard-Pool-Größe in leeren Projekten bei etwa 512 MB liegt, sollte in einem Nanite-lastigen AAA-Projekt über die Befehlszeile oder in .ini-Dateien (z. B. in DefaultEngine.ini unter ``) folgender Parameter konfiguriert werden:

r.Nanite.Streaming.StreamingPoolSize = 2048

(Je nach Schwere der Szene und anderen Systemen etwa 2000-3000 MB). Wenn dieses Pool-Budget zu knapp gehalten wird, können die hochdetaillierten Cluster von Objekten in der Ferne nicht rechtzeitig geladen werden und Nanite fällt auf Fallback-Modelle zurück; wird es zu groß gehalten, bleibt kein RAM für Lumen-Oberflächen-Caches (Surface Cache), hochauflösende Texturen und das Betriebssystem übrig. Entwickler werden sehen, dass ab UE 5.7 ein Warnsystem aktiviert wird, wenn StreamingPoolSize-Zustände die Konsolengrenzen (in der Regel eine Überschreitung von 2-4 GB) überschreiten.

PlayStation 5-Entwicklungsanforderungen und Konsolenkonfigurationen

Obwohl der Entwicklungsprozess für die PS5-Plattform mit der Unreal Engine 5 dank der engen Zusammenarbeit zwischen Epic Games und Sony stark verfeinert wurde, ist die Einhaltung spezifischer Software Development Kits (SDKs) und Systemkonfigurationen zwingend erforderlich, damit das Projekt kompiliert werden kann und mit optimaler Geschwindigkeit läuft.

SDK-Versionen und Compiler-Flags

Die Hardware- und Softwarebibliotheksanforderungen, die beim Erstellen (Build) auf der PS5-Hardware mit den aktuellen UE-Versionen 5.6 und 5.7 zu beachten sind, lauten wie folgt:

• Unterstützte SDK- und Systemversionen: Die Grundvoraussetzung für die PS5-Entwicklungsumgebung ist als „Prospero SDK 11.00.00.40“ (oder SDK 12 für fortgeschrittene Speichersysteme) und „System Software 11.00.00.43“ festgelegt. Versionsinkompatibilitäten in der Projektkonfiguration (bei der Arbeit mit Plugins von Drittanbietern wie IntlNetwork SDK oder Interhaptics) sind eine Absturzursache.

• Compiler-Konfiguration: Während des Kompilierungsprozesses wird neben Sonys eigener Toolchain clang-cl verwendet. Um ein undefiniertes Verhalten (undefined behavior) und NaN-Fehler (Not a Number) über Clang 19 zu verhindern, wird Quellcode nun obligatorisch mit dem Flag -fhonor-nans kompiliert. Darüber hinaus wurde der Parameter -ffp-contract=off, der in der Vergangenheit plattformübergreifende Probleme verursachte, da er mit -ffast-math kollidiert, aus dem PS5-Compiler entfernt.

• Wechsel zur Standardbibliothek (Stdlib): Mit UE 5.7 wurde die Unterstützung für die C++20-Standardbibliothek (stdlib v2) für die PS5 hinzugefügt. Entwicklern wird dringend empfohlen, die Zuweisung StandardLibVersion = 'v2' über die Konfigurationsdateien UEBuildPS5.cs oder BuildConfiguration.xml für zukünftige Kompatibilität und Leistungssteigerungen vorzunehmen.

• Systemoptimierungseinstellungen: Um die Ansammlung von Sampler-Zuständen auf der GPU zu verhindern, wurde in der AgcRHI-Architektur ein neues LRU-Cache-System (Least Recently Used) eingeführt. Dieses Limit ist standardmäßig als r.Agc.MaxSamplerStates 4096 konfiguriert.

Skalierbarkeitsprofile für das 60-FPS-Ziel

UE5 ist auf PS5- und Xbox Series X-Konsolen mit der standardmäßigen Qualitätsstufe „Epic“ auf ein 30-FPS-Ziel (33.3 ms pro Frame) konfiguriert. In modernen Spielen unter dem Einfluss von Raytracing und massiver Polygonlast erfordert das Anvisieren von 60 FPS (16.6 ms pro Frame) bewusste Kompromisse bei Renderauflösung und -qualität von Nanite und Lumen.

Studios, die ein Spiel auf der PS5 mit einem flüssigen 60-FPS-Erlebnis veröffentlichen möchten, müssen die Qualität der Lumen Global Illumination (GI) und der Reflexionssysteme in den hardwareseitigen DeviceProfiles.ini-Einstellungen der Engine auf das „High“-Skalierungsniveau senken, um sie an das 60-FPS-Budget anzupassen. In diesem Profil wird das Spiel intern (internal resolution) vor dem Upscaling mit Temporal Super Resolution (TSR) mit etwa 1080p oder 1440p gerendert.

Der folgende Konfigurationsblock sollte direkt zur Datei [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini im Spielverzeichnis hinzugefügt werden:

; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2

Diese Konfiguration zieht die Rechenlast von Lumen an die Grenzen der Konsolen und lässt den Millionen von Polygonen, die mit Nanite verarbeitet werden, eine Atempause von 16.66 ms pro Frame. Zusätzlich ist es wichtig, die Thin Geometry-Erkennungsfunktionen von TSR aktiv zu halten, um die Nanite-Leistung zu steigern.

Spezifische PS5-Verbesserungen für die Lumen- und Nanite-Synchronisation

Das Nanite-System allein ist nur für statisches geometrisches Zeichnen verantwortlich; was jedoch die visuelle Qualität des Spiels bestimmt, ist Lumen – das System für Globale Beleuchtung (Global Illumination), das von Nanite-Oberflächen abprallt und fotorealistische Schatten erzeugt. Wenn beide Systeme kombiniert werden, wird die PS5-Hardware bis an ihre Grenzen gebracht.

Lumen hat zwei Betriebsmodi: Software Ray Tracing (SWRT), das Distanzfelder (Distance Fields) verwendet, und Hardware Ray Tracing (HWRT), das Dreiecke direkt berechnet. Nanite speist seine komplexe Geometrie über die zuvor erwähnten Fallback-Netze (Fallback Meshes) in den HWRT-Mechanismus ein. Während in älteren Engine-Versionen SWRT zwingend für 60 FPS empfohlen wurde, wurden in den Unreal Engine-Versionen 5.6 und 5.7 grundlegende HWRT-Verbesserungen vorgenommen, die die Konsolenhardware (insbesondere die AMD-RDNA2-basierten RT-Kerne der PS5) entlasten:

1. ShortRangeAO-Optimierung: Nahbereichs-Umgebungsverdeckung (Ambient Occlusion) wird mithilfe eines neuen Denoisers nun mit halber Auflösung (half resolution) ausgeführt. Dieser Prozess sorgt dafür, dass dieser Übergang auf Konsolen doppelt so schnell abläuft. 49

2. Far Field Occlusion Only Mode: In großen offenen Welten können Bounce-Berechnungen von sehr weit entfernten Nanite-Objekten, die über das World-Partition-System geladen werden, das System überlasten. Durch die Verwendung des neuen Befehls r.LumenScene.FarField.OcclusionOnly 1 wird die Fernbereichsleistung von Lumen auf der PS5 um 50 % beschleunigt. 49

3. Downsampled Screen Probe Gather: Beim Probe-Gather-Übergang, der die Umgebungsbeleuchtung auf den Bildschirm projiziert, bringt die Reduzierung der Integrationsabtastrate zwischen Pixeln (r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor) einen Zeitgewinn von 0.3-0.5 ms in einem 1080p-Renderszenario auf der PS5. 20 Obwohl in den Details eine leichte Weichheit zu erkennen ist, ist dieser Kompromiss für das 60Hz-Budget äußerst ideal.

4. Shader Execution Reordering (SER): In komplexen Szenen mit HitLighting und Ray-Traced Translucency sowie einer Vielzahl verschiedener Materialien bietet der Befehl r.Lumen.HardwareRayTracing.ShaderExecutionReordering, der die hardwareseitige Neuordnung von Befehlen aktiviert, auf unterstützten RHI-Einheiten Beschleunigungen. 49

Stößt der Entwickler trotz hoher Nanite-Optimierungen in seiner Szene an die Renderlimits der PS5, sollte er die HWRT-Kosten mit dem „stat gpu“-Profil messen und bei Bedarf in einer frühen Phase des Projekts (optimize early) die Rückkehr zu klassischen Shadow Maps anstelle von Virtual Shadow Maps (VSM) für gerichtete Lichter testen, um Schattenberechnungen kostengünstiger zu gestalten. 25

Strategisches Fazit und Entwicklerempfehlungen

Gemäß den durchgeführten Tiefenanalysen stellt die Nanite-Architektur der Unreal Engine 5 durch die Verschmelzung moderner GPU-Compute-Shader-Fähigkeiten, Hardware-Raytracing-Integration und Datenkomprimierungsalgorithmen der nächsten Generation eine echte Revolution in der Computergrafikindustrie dar. Diese Technologie, die Polygonanzahl und Draw-Call-Engpässe eliminiert, bringt gleichzeitig verschiedene Arbeitsabläufe (Assemblies, Voxelization) und strenge Speicherbudgetdisziplinen (Streaming Pools) mit sich.

Die wichtigsten strategischen Erkenntnisse, die technische Künstler (Technical Artists) und Engine-Programmierer (Engine Programmers) bei der Spieleentwicklung für die PlayStation 5-Plattform berücksichtigen müssen, lauten wie folgt:

1. Korrekte und grenzwertige Nutzung des I/O-Vorteils: Der einzigartige Kraken-Hardwaredekompressor der PS5 bietet eine unglaubliche I/O-Bandbreite über die SSD. Es entspricht eher dem natürlichen Fluss des Systems, wenn Entwickler sich von veralteten manuellen LOD-Strategien abwenden, die das Nanite-Streaming einschränken, und stattdessen direkt die Verwendung von Original-Quell-Meshes (source mesh) in Filmqualität anstreben.

2. Vermeidung von Transparenz- und Overdraw-Kosten: WPO-basierte (World Position Offset) Animationen und die Verwendung von Alpha Mask/Cutout, die Achillesferse von Nanite, sind Performance-Killer, insbesondere bei Laub. Die mit UE 5.6 und 5.7 eingeführten Funktionen Nanite Voxels, Nanite Assemblies und Nanite Skinning sollten bei Open-World-Zielen mit 60 FPS auf der PS5 als Kernmethode anstelle der traditionellen Grasmodellierung übernommen werden. Anstelle einer Modelloptimierung ist die Ausrichtung auf hochpolygonale, aber glatte „Opaque“-Geometrien zwingend erforderlich.

3. Durchführung einer präzisen VRAM-Budgetierung: Die feste Speicherstruktur der PS5 kann schnell durch Nanite-Sichtbarkeitsidentitäten (Visibility Buffer) und Lumen-Oberflächen-Caches erschöpft werden. StreamingPoolSize-Grenzen müssen sorgfältig festgelegt werden, und anstelle eines nativen 4K-Render-Scalings sollten interne Auflösungsziele von 1080p bis 1440p in Verbindung mit Temporal Super Resolution (TSR) verwendet werden, um hohe visuelle Qualität mit stabiler Bildrate zu synthetisieren.

4. Regelmäßige und frühe Profilanalyse (Optimize Early): Ohne bis zum Ende des Entwicklungsprozesses zu warten, sollten Profilierungswerkzeuge wie stat gpu, stat unit und NaniteStats aktiv überwacht werden. Materialstrukturen, die problematische Raster Bins erzeugen, müssen identifiziert und zusammengeführt werden, um Zustandsänderungen (State Changes) zwischen CPU und GPU auf ein Minimum zu reduzieren.

Nanite ist kein magischer Leistungssteigerer; im Gegenteil, es ist ein sehr starkes Ökosystem, das bei richtiger Anwendung die Vision nicht einschränkt, bei Nichteinhaltung der Regeln (z. B. durch übermäßige Verwendung maskierter Materialien) jedoch hart auf Hardware-Barrieren stößt. Wenn die spezielle I/O-Architektur der PS5-Hardware und die Render-Innovationen der Unreal Engine 5 synchron arbeiten, erweitern sich die visuellen und volumetrischen Grenzen der interaktiven Medien auf beispiellose Weise.

*Hinweis: Die Bilder wurden von Google Gemini generiert.