Abstimmen der Bildrate von 3DGS-Szenen in UE5

Schritt eins: Den Engpass finden

Vor dem Ändern irgendeines Parameters bestätigen, dass der Einbruch der Bildrate von 3DGS verursacht wird. Beleuchtung, Schatten, Nachbearbeitung, reguläre Modelle und Blueprint-Logik in der Szene können alle der eigentliche Engpass sein, und dann hilft kein noch so gründliches Abstimmen der LCC-Parameter.

Bestätigen, dass der Engpass von 3DGS kommt

Alles in der Szene außer 3DGS verbergen oder entfernen und die Bildrate vergleichen:

1. Die aktuelle Bildrate als Basiswert festhalten (stat fps oder stat unit).
2. Den LCC-Actor verbergen, die übrige Szene behalten und die Bildrate festhalten.
3. Umgekehrt vorgehen: nur den LCC-Actor behalten, die anderen Modelle, Lichter, Post-Process-Volumes und die UI verbergen oder entfernen und die Bildrate festhalten.

Wenn die ursprüngliche Szene viele Elemente enthält und ein einzelnes Verbergen unpraktikabel ist, ist ein leeres Level mit einem einzelnen LCC-Actor, der die gleichen Daten lädt, der klarere Weg; dann die Bildrate aus demselben Blickwinkel festhalten. Das entfernt jede Störung durch die ursprüngliche Szene und liefert den Leistungsbasiswert von 3DGS selbst.

Die drei Zahlenreihen vergleichen:

Die Standard-Szenenelemente der Engine ausschließen

Ein neues Level bringt eine Reihe von Standard-Actors mit, und mehrere davon sind nicht günstig, weshalb sie leicht für 3DGS-Kosten gehalten werden. Am typischsten ist VolumetricCloud: Es führt pro Bild ein volumetrisches Ray Marching durch und verbraucht weiter GPU-Zeit, selbst wenn nur ein kleines Stück Himmel sichtbar ist.

Wenn das Projekt keine Himmelseffekte braucht, die folgenden Actors aus dem Level löschen:

3DGS-Daten enthalten meist bereits Umgebungsinformationen, diese Effekte sind daher in den meisten Fällen unnötig. Nach dem Löschen die Bildrate erneut messen und dann beurteilen, ob die LCC-Parameter überhaupt noch abzustimmen sind.

Die Testbedingungen unverändert halten, sonst sind die Zahlen nicht vergleichbar: dieselbe Map und derselbe Startpunkt, dieselbe Kameraposition oder derselbe Kamerapfad, dieselbe Auflösung und dasselbe Screen Percentage sowie derselbe Ein-/Aus-Zustand für Lumen, Virtual Shadow Maps, Nachbearbeitung und SceneCapture. Vor dem Aufzeichnen einen Aufwärmdurchgang laufen lassen, damit die erste Shader-Kompilierung und der erste Datenträgerzugriff sich nicht in die stabile Bildrate mischen. Immer nur eine Kategorie von Einstellungen auf einmal ändern.

Häufige Beobachtungsbefehle:

stat fps         // Frame rate
stat unit        // The four frame times: Frame / Game / Draw / GPU
stat gpu         // GPU Pass breakdown
stat rhi         // Draw calls, primitives, video memory
ProfileGPU       // Per-frame GPU Pass detail

Die LCC-Statistiken nutzen, sobald 3DGS bestätigt ist

Das Statistik-Panel im Actor-Panel über Actions > Stats öffnen oder stat xgrids in der Konsole eingeben.

Die Echtzeit-Leistungsstatistiken von LCC mit stat xgrids ansehen

Zu den Parametern im Einzelnen siehe Leistungsparameter: Statistiken

Auf Current Render Main Splats und Current Render Nodes achten: Die unmittelbare Ursache der meisten Leistungsprobleme sind zu viele gleichzeitig auf dem Bildschirm gerenderte Punkte.

Gleichzeitig die LOD-Visualisierung einschalten

Beim Lesen der Statistiken im Actor-Panel Actions > Debug Node Bound nutzen, um die Node-Levels zu visualisieren und die LOD-Verteilung der aktuellen Ansicht unmittelbar zu bestätigen. Wärmere Farben bedeuten ein niedrigeres Level und mehr Details.

Der Gedanke der Optimierung ist, die Punkte auf dem Bildschirm so weit zu reduzieren, wie die Anmutung es erlaubt, mit dem Blick darauf, wie weit Level 0 reicht:

• Wie weit reichen die warmfarbigen Bereiche im Bild? Werden die Daten der höchsten Genauigkeit auf dieser Distanz wirklich gebraucht?
• Wenn der Wechsel auf gröbere Levels früher erfolgt, ist der Verlust in der Anmutung wahrnehmbar?

In den meisten Szenen reicht Level 0 weiter als tatsächlich nötig, und ein früherer Wechsel auf gröbere Levels senkt die Punktzahl unmittelbar, was von allen Möglichkeiten die wirksamste ist. Sobald Reserven bestätigt sind, weiter zu Schritt zwei und Level Factor abstimmen.

Schritt zwei: LOD anpassen

Das ist der Schritt mit dem deutlichsten Nutzen. In den meisten Szenen reicht Level 0 weit über das tatsächlich Nötige hinaus, und ein früherer Wechsel auf gröbere Levels senkt die Punktzahl auf dem Bildschirm unmittelbar, meist ohne wahrnehmbare Änderung der Anmutung. Diesen Schritt zuerst durchführen und erst danach die späteren Möglichkeiten erwägen.

LOD hat drei unabhängige Stellschrauben (Level Factor, Start Level, End Level)

Level Factor, Start Level und End Level konfigurieren

2.1 Zuerst bestimmen, wie Level Factor wirkt

Die beiden Pipelines wählen Levels über unterschiedliche Mechanismen, Level Factor wirkt daher ebenfalls unterschiedlich, aber die Richtung ist dieselbe: Je größer der Wert, desto früher wechseln Nodes auf Levels mit geringerer Genauigkeit.

LCC2-Pipeline: Screen-Space-Fehler

LCC2 nutzt RangeForLevel nicht, sondern berechnet für jeden Node einen Screen-Space-Fehler: wie viele Pixel der geometrische Fehler des Nodes selbst bedeckt, wenn er auf den Bildschirm projiziert wird. Übersteigt der Fehler den Schwellwert, wird zu feineren Kind-Nodes verfeinert, andernfalls bleibt es beim aktuellen Level.

Dieser Fehler wird gleichzeitig von Node-Distanz, Blickwinkel und Bildschirmauflösung beeinflusst, derselbe Level Factor ergibt daher bei unterschiedlichen Auflösungen oder FOVs nicht dieselbe tatsächliche Wechseldistanz. Das bedeutet auch, dass sich die LOD-Verteilung von LCC2 nicht im Vorfeld aus einer Distanztabelle berechnen lässt und nur praktisch mit dem Debug Node Bound aus 2.5 beobachtet werden kann.

Das Abstimmen funktioniert wie bei der LCC-Pipeline, daher direkt zur Testleiter in 2.2.

LCC-Pipeline: Distanztabelle

Level Factor teilt das globale Array RangeForLevel durch seinen Wert. Je größer der Wert, desto kürzer die wirksame Distanz jedes Levels und desto früher treten Nodes in ein Level mit geringerer Genauigkeit ein.

Standardwerte von RangeForLevel (11 Einträge, ProjectSettings > Plugins > LCC4Unreal > Level):

Level:  0    1    2    3    4    5    6    7    8    9    10
meters: 15   50   80  110  140  170  190  220  250  280   350

Wirksame Distanzen nach der Division durch Level Factor (in Metern, nicht ganzzahlige Werte gerundet dargestellt):

Wie diese Tabelle zu lesen ist: Bei Level Factor = 2 galt die höchste Genauigkeit bisher innerhalb von 15 Metern und gilt nun nur noch innerhalb von 7,5 Metern. Das ist weit genauer als die Aussage „halbe Detailmenge“: Was sich ändert, ist die wirksame Distanz jedes Levels, nicht das Punkteverhältnis.

Die genaue Art, wie Levels gegen Distanzen verglichen werden (obere oder untere Grenze, offenes oder geschlossenes Intervall), ist ein internes Implementierungsdetail. Die Tabelle oben dient dem Abschätzen, wie viel anzupassen ist; die tatsächliche Level-Verteilung mit dem Debug Node Bound aus 2.5 bestätigen. Diese Tabelle gilt nur für die LCC-Pipeline.

Jenseits des letzten Eintrags von RangeForLevel nutzt ein Node einfach das gröbste ihm verfügbare Level, es gibt also nie den Fall, dass kein Level gefunden wird. Ein Erhöhen von Max Distance über 350 Meter erfordert daher kein Anpassen dieser Tabelle.

Das Distanzarray Range For Level in den Projekteinstellungen konfigurieren

2.2 Level Factor

Zu Bereich und Standardwert siehe Leistungsparameter: Level Factor

Das ist die bevorzugte LOD-Stellschraube, weil sie graduell wirkt und nicht ein ganzes Detail-Level auf einmal wegschneidet.

Testleiter:

1.0 → 1.25 → 1.5 → 2.0

Zuerst prüfen: Umrisse, dünne Linien, kleine Objekte, Bodendetails und Level-Übergangsbereiche. An diesen Stellen zeigen sich unzureichende Details und LOD-Popping zuerst.

LOD-Änderungen nach dem Anpassen von Level Factor

2.3 Start Level

Zu Bereich und Standardwert siehe Leistungsparameter: Start Level

Ein Erhöhen überspringt die niedrigst nummerierten (feinsten) Levels vollständig:

0 → 1 → 2

Das ist weit aggressiver als eine kleine Änderung von Level Factor: Es verwirft ganze Levels statt Distanzen zu skalieren. Nur nutzen, wenn beide Bedingungen gelten: stat xgrids zeigt, dass Level0 Splats wirklich der Hauptkostenpunkt ist, und eine gröbere Qualität im Nahbereich ist akzeptabel. Zurück auf 0 gehen, sobald der Nahbereich sichtbar unscharf ist.

Überspringen von Levels hoher Genauigkeit nach dem Erhöhen von Start Level

2.4 End Level (normalerweise unverändert)

Zu Bereich und Standardwert siehe Leistungsparameter: End Level

Ein Senken begrenzt das gröbste nutzbare Level: Gröbere Levels in den Daten werden nie genutzt, ferner Inhalt kann nur auf End Level bleiben, und es werden mehr Punkte als nötig gerendert. Es ist keine Schaltfläche zur Beschleunigung, daher beim Standardwert bleiben, solange die Level-Struktur der Daten nicht bereits verstanden ist.

Start Level <= End Level muss gelten; der Setter prüft das nicht.

Begrenzen von Levels geringer Genauigkeit nach dem Anpassen von End Level

2.5 Mit Debug Node Bound prüfen

Actions > Debug Node Bound im Actor-Panel visualisiert Node-Grenzen und Levels. Die Farbfolge ist rot, orange, gelb, grün, blau, violett, wobei rot das niedrigste Level (die höchste Genauigkeit) und weiß das höchste Level (die niedrigste Genauigkeit) darstellt.

Damit nach dem Ändern der LOD-Parameter prüfen: ob der Nahbereich weiterhin rot/orange ist (hohe Genauigkeit), ob die Ferne gleichmäßig in kalte Farben übergeht und ob ein Bereich auf derselben Distanz fortlaufend zwischen Levels umschlägt.

Die LOD-Verteilung mit Debug Node Bound prüfen

Prüfpunkte für LOD

• Ob Node-Anzahl und Splat-Anzahl sinken;
• Ob der Nahbereich zu früh grob wird;
• Ob während der Kamerabewegung deutliches LOD-Popping auftritt;

Schritt drei: Maximale Renderdistanz

Zu Bereich und Standardwert siehe Leistungsparameter: Max Distance(m)

Die maximale Renderdistanz Max Distance setzen

Wie es sich von LOD unterscheidet

Max Distance schneidet Daten jenseits der Distanz vollständig weg und verringert den renderbaren räumlichen Bereich; LOD senkt die Genauigkeit innerhalb des Bereichs. Beide ergänzen sich: Damit den Bereich weiter einengen, wenn nach dem Abstimmen des LOD noch Druck bleibt.

Es kann Kandidaten-Nodes samt der danach folgenden Arbeit für Traversierung, Laden, Upload, Sortierung und Füllung reduzieren, aber wie stark es reduziert, hängt von Implementierung und Daten ab, daher gegen echte Statistiken prüfen statt ein festes Verhältnis des Gewinns anzunehmen.

Zuerst das Kontrollkästchen anhaken, sonst bewirken Änderungen nichts

Jeder Parameter unter der Kategorie Performance hat links ein Kontrollkästchen. Solange das Kästchen nicht angehakt ist, hat der Wert im Textfeld keine Wirkung, und zur Laufzeit wird der eingebaute Standardwert des Plugins genutzt. Hier zuerst prüfen, wenn eine Anpassung nichts bewirkt.

Schritte zum Abstimmen der Distanz

1. An der Position in der Szene stehen, an der die Modelldaten am weitesten entfernt sichtbar sein müssen, und die tatsächlich nötige Distanz messen.
2. Das Kontrollkästchen links des Parameters anhaken.
3. Auf „die tatsächliche maximale Sichtdistanz + die nötige Reserve“ setzen.
4. Schritt für Schritt einengen; nicht unmittelbar auf einen sehr niedrigen Wert fallen:

300 m (default) → 225 m → 150 m → fine-tune to the actual project distance

Das Obige ist eine Testleiter, kein empfohlener Wert. Sinnvolle Werte unterscheiden sich stark zwischen Innenräumen, Stadtblöcken, großen Szenen und Luftaufnahmen, daher je Projekt messen.

Änderungen des Renderbereichs nach dem Anpassen von Max Distance

Prüfpunkte für die Distanz

• Ob Current Render Nodes und Current Render Splats sinken;
• Ob GPU ms oder Traversal Time sinken;
• Ob Inhalt abrupt verschwindet, wenn man zur fernen Grenze läuft;
• Ob nicht geladene Bereiche bei schneller Bewegung leichter zu sehen sind;

Schritt vier: Eine harte Punktgrenze setzen

Zu Bereich und Standardwert siehe Leistungsparameter: Max Splat Num

Max Distance steuert den räumlichen Bereich, aber die Datendichte innerhalb desselben Bereichs kann enorm schwanken. Max Splat Num liefert eine Obergrenze der Last pro Bild, die verhindert, dass die Punktzahl beim Eintritt in einen Bereich hoher Dichte in die Höhe schießt. Es ergänzt LOD und Distanz und kann keines von beiden ersetzen.

Zu beachten: Zu große Werte werden automatisch auf die Menge begrenzt, die die GPU in einem Bild rendern kann; den Wert im Panel an die Grenze zu ziehen übersteigt nicht die Hardwarefähigkeit und macht die Obergrenze lediglich wirkungslos. Damit sie tatsächlich wirkt, sie unter die echte Punktzahl der aktuellen Ansicht setzen.

Die Punktgrenze pro Bild Max Splat Num setzen

Schritte zum Abstimmen der Punktgrenze

1. Das Kontrollkästchen links des Parameters anhaken.
2. Sie ausgehend vom Standardwert verhältnismäßig senken, in Einheiten von 10.000:

3000 → 2250 → 1500 → 1000

3. Nach jeder Senkung in einem Bereich hoher Dichte beobachten, nicht nur in offenen Bereichen.

Änderungen der Punktzahl und des Bildes nach dem Anpassen von Max Splat Num

Prüfpunkte für die Punktgrenze

• Ob GPU ms und Current Render Splats gemeinsam mit der Grenze sinken;
• Ob lokales Ausdünnen, Flackern oder zerbrochene transparente Strukturen auftreten.

Wenn sich nach dem Senken der Grenze weder Punktzahl noch GPU ms ändern, erreicht die aktuelle Ansicht diese Grenze nie und das ist nicht der aktuelle Engpass, daher zurück zu Schritt eins gehen und ihn erneut suchen.

Schritt fünf: Die Pixel-Füllkosten senken

5.1 SplatScale

Zum Parameter im Einzelnen siehe Bildeinstellungen: SplatScale

Ein Senken verringert die Bildschirmfläche, die ein einzelner Splat bedeckt, und reduziert damit die transparente Überlappung.

Vorgehen: ihn in kleinen Schritten vom aktuellen Qualitätswert senken und bei hoher Auflösung, im Nahbereich und entlang von Objektumrissen prüfen. Ein zu starkes Senken lässt Flächen Löcher zeigen oder merklich dünn wirken.

SplatScale anpassen, um die von Gauß-Punkten bedeckte Bildschirmfläche zu verringern

5.2 Small Splat Threshold (px) (nur LCC2-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Small Splat Threshold (px)

Ihn live mit einer CVar testen, kein Neustart erforderlich:

r.LCC2.SmallSplatThreshold 0
r.LCC2.SmallSplatThreshold 0.5
r.LCC2.SmallSplatThreshold 1

Je höher der Wert, desto größer der mögliche Gewinn und desto deutlicher die Körnigkeit in der Ferne. Ihn nur weiter erhöhen, wenn GPU oder SH-Berechnung wirklich der Engpass sind; wenn die Daten selbst keine SH haben, ist der Gewinn durch das Überspringen der SH begrenzt.

Den Pixel-Schwellwert Small Splat Threshold setzen

5.3 Quad Extent Threshold (nur LCC2-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Quad Extent Threshold

Ein Erhöhen dieses Werts ergibt engere Quads und senkt Overdraw, kann aber halbtransparente Kanten abschneiden.

r.LCC2.QuadExtentThreshold 0.006 → 0.008 → 0.01

Zurücknehmen, wenn Umrisse härter werden, Kanten fehlen oder Splat-Formen falsch aussehen.

Quad Extent Threshold setzen, um die Ausdehnung des Splat-Quads zu steuern

5.4 Frustum Cull Margin (nur LCC2-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Frustum Cull Margin

Er steuert den Culling-Margin, nicht die Punktgrenze.

Ein Senken in Richtung 1.0 nur in kleinen Schritten versuchen, solange am Bildschirmrand kein Popping auftritt:

r.LCC2.FrustumMargin 1.2 → 1.1 → 1.0

Am Rand ein- und ausblitzender Inhalt beim schnellen Drehen der Kamera bedeutet, dass es zu weit gesenkt wurde.

Den Frustum-Culling-Margin Frustum Cull Margin setzen

5.5 Kantenglättung

Die GPU-Kosten der Kantenglättung sind nicht gering, bei TSR besonders deutlich. Enthält die Szene nur 3DGS ohne reguläre Meshes oder UI, verliert das Setzen der passenden Option auf None meist sehr wenig Bildqualität, während der Gewinn bei der Bildrate erheblich ist.

Zur Standardmethode jeder Pipeline und zu den Abwägungen siehe Leistungsparameter: Anti-aliasing Methods.

Die Methode der Kantenglättung je LCC-Pipeline konfigurieren

Schritt sechs: Nicht benötigte Funktionen abschalten

Die Gewinne dieses Schritts sind klar, aber jeder kommt mit funktionalen Kosten, daher Punkt für Punkt bestätigen, dass das Projekt es wirklich nicht braucht, statt alles abzuschalten.

Zu den Funktionen im Einzelnen siehe Bildeinstellungen und Leistungsparameter.

Schritt sieben: Sortierung und Grafikspeicher

Transluzenz-Sortierung und Grafikspeicherverwaltung werden je Pipeline behandelt: Sort Factor und zusätzliches Vorladen existieren nur bei LCC1, und das GPU-Grafikspeicher-Budget existiert nur bei LCC2.

7.1 Sort Factor (nur LCC-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Sort Factor

Er gilt für die globale Tabelle SortFrequencyForLevel und steuert, wie oft die Nodes jedes Levels neu sortiert werden. Je größer der Wert, desto weniger Sortierungen und desto besser die Leistung, aber die Transparenz-Reihenfolge aktualisiert sich langsamer, nachdem sich Kamera oder Nodes geändert haben, was kurzzeitige Durchdringungsfehler verursachen kann.

Sort Factor setzen, um die Sortierfrequenz des LCCActor anzupassen

Die Sort Frequency jedes LOD-Levels konfigurieren

7.2 Zusätzliche Vorlade-Nodes (nur LCC-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Add Extra Preload Nodes

Ihr Zweck ist, Löcher am Bildschirmrand beim schnellen Drehen zu mildern, um den Preis von mehr Node-Arbeit.

Diese Option hat zwei Zustandsebenen und wird leicht falsch verstanden:

• Solange das Kontrollkästchen links nicht angehakt ist, fällt sie auf den internen Standardwert zurück, das wirksame Ergebnis ist also weiterhin aktiviert;
• Um sie tatsächlich abzuschalten, zuerst das Kästchen anhaken und dann den Wert auf deaktiviert setzen.

Sie nur abschalten, wenn die Statistiken zeigen, dass Node-Anzahl und Vorladen wirklich eine klare Last sind und das Projekt Randlöcher beim schnellen Drehen akzeptieren kann. Sie wiederherstellen, sobald Löcher auftreten; nicht mit zusätzlichen Threads über noch nicht bereite Daten hinwegtäuschen.

Zusätzliche Vorlade-Nodes konfigurieren, um Löcher beim schnellen Drehen zu mildern

7.3 LCC2 GPU Memory Budget (nur LCC2-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: LCC2 GPU Memory Budget (MB)

Das Grafikspeicher-Budget LCC2 GPU Memory Budget setzen

Es zählt nur Positions-, Farb- und Kugelflächenfunktions-Daten eines einzelnen LCC2-Modells. Ein Erhöhen des Budgets kann nur in diesen Fällen helfen:

• Die GPU hat noch genug freien Grafikspeicher;
• Ruckeln tritt vor allem beim Eintritt in einen neuen Bereich oder beim Arbeiten mit mehreren Viewports auf.

Es reduziert nicht Splat-Anzahl, Sortierarbeit oder Pixelabdeckung. Ohne Probleme mit Auslagerung oder Fragmentierung erhöht ein größeres Budget nur den residenten Grafikspeicher, ohne die Bildrate zu verbessern.

Schritte zum Abstimmen:

1. Zuerst die Grafikspeicher-Spitze der gesamten Maschine festhalten, nicht nur das LCC-Budget.
2. Beim Standardwert beginnen und in Schritten von 1024 MB erhöhen.
3. Nach jeder Änderung die Engine neu starten.
4. Die anspruchsvollsten Blickwinkel, alle SceneCapture- / nDisplay-Ansichten und lange Läufe erneut testen.
5. Grafikspeicher für UE-Szenentexturen, Render Targets, Nanite, Lumen, VSM, Sortier-Buffer und das Betriebssystem übrig lassen.

Es ohne vollständige Überwachung des Grafikspeichers nicht auf 8192 MB setzen.

Das Log gibt außerdem eine Aufschlüsselung des Grafikspeicherbedarfs aus, mit der geprüft werden kann, ob das Budget sinnvoll ist:

GPU footprint: %u slots (%s), %.2f MB total - gaussian %.2f, SH %.2f, sort %.2f (1 view), other %.2f MB

Der Eintrag sort ist der Sortier-Buffer. Das Log ist für 1 view berechnet, es daher bei mehreren Viewports mit der Anzahl der Ansichten skalieren.

Schritt acht: Laden, Threads, Arbeitsspeicher

8.1 Nicht zuerst Threads hinzufügen (nur LCC-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Einstellungen des Thread-Pools

Das Hinzufügen von Threads kann die CPU-Parallelität erhöhen, und es kann ebenso Thread-Konkurrenz, Kontextwechsel, kurzzeitigen Datenträgerdruck und Upload-Spitzen erhöhen. Exporter-Threads haben keinen unmittelbaren Bezug zum Rendering zur Laufzeit, ihr Abstimmen verbessert die Bildrate daher nicht.

Kriterium: nur wenn die Statistiken zeigen, dass die zugehörige Warteschlange aufläuft, während die CPU noch freie Kerne hat, jeweils 2~4 Threads hinzufügen und erneut testen. Wenn die CPU bereits gesättigt ist, die Last reduzieren statt weitere Threads hinzuzufügen.

Zeigt der Eintrag Create Thread fortlaufend Zeitkosten, wächst der Thread-Pool wiederholt, daher die Anzahl der vorab erzeugten Threads anpassen statt die Obergrenze.

8.2 Splat Number For Discard Per Node (nur LCC-Pipeline)

Zu Bereich und Standardwert siehe Leistungsparameter: Splat Number For Discard Per Node

Den Verwerfungsschwellwert für dünn besetzte Splats je Node setzen

Die Absicht ist, äußerst dünn besetzte Nodes zu ignorieren: Manche Datensätze enthalten viele Nodes mit nur ein oder zwei Splats, und die Verwaltung dieser Nodes kostet mehr, als sie zum Bild beitragen.

Ein Erhöhen kann die Verwaltungskosten von Nodes geringer Dichte senken, und es kann ebenso isolierte Details entfernen. An dünnen Linien, Baumzweigen, Geländern und kleinen fernen Objekten prüfen statt nur auf die Gesamtbildrate zu schauen. Nach dem Ändern die Daten neu laden, sonst ist das Ergebnis auf dem Bildschirm weiterhin das alte.

8.3 Freigabeschwellwerte für Arbeits- und Grafikspeicher

Bedarf und Freigabeschwellwerte für CPU- und GPU-Speicher konfigurieren

Zu Bereich und Standardwert der vier Schwellwerte siehe Leistungsparameter: Kategorie Usage

Das ist eine Freigabestrategie unter Speicherdruck, keine reguläre Stellschraube für die Bildrate:

• Ein zu niedriger Schwellwert oder ein zu großer Freigabeanteil → kann ein Schwingen aus „freigeben, neu laden, wieder freigeben“ verursachen;
• Ein zu hoher Schwellwert → kann die Freigabe verzögern und den Druck auf System- und Grafikspeicher erhöhen;
• Ihn erst anpassen, nachdem Langzeittests Speicherdruck oder wiederholtes Auslagern bestätigt haben.

Ihn nach dem Verhältnis zwischen CPU Occupy Percentage / GPU Occupy Percentage und den zugehörigen Schwellwerten beurteilen sowie danach, ob Released CPU Node Num / Released GPU Node Num fortlaufend wächst. Im Screenshot übersteigt der Grafikspeicherbedarf von 86 % bereits den Schwellwert von 80 % und die Anzahl der Grafikspeicher-Freigaben erreichte 1943, was ein typisches Signal für Grafikspeicherdruck ist.

Schritt neun: Mehrere Viewports, Kollision, Wasser

9.1 Mehrere Kameras und SceneCapture

Jede zusätzliche Ansicht, die tatsächlich am Rendering teilnimmt, kann Arbeit für Traversierung, Rendering oder Sortierung hinzufügen; LCC2 fügt zudem je Ansicht einen Sortier-Buffer hinzu.

Punkt für Punkt prüfen:

1. Ob irgendein SceneCapture unbenutzt ist, aber weiterhin pro Bild aktualisiert wird;
2. Ob die Auflösung des Render Target zu hoch ist;
3. Ob die Aktualisierungsfrequenz wirklich pro Bild sein muss;
4. Ob ShowOnlyActors nur den benötigten Inhalt enthält;
5. Ob die Minimap auf PointCloud oder eine niedrigere Auflösung wechseln kann;
6. Ob nDisplay, Split Screen oder MRQ gleichzeitig zusätzliche Ansichten erzeugt haben.

Mit Camera Num(Render) in stat xgrids bestätigen, dass die Anzahl der tatsächlich rendernden Ansichten der Erwartung entspricht; Camera Num ist die Anzahl der an Aktualisierungen teilnehmenden Kameras, und beide können voneinander abweichen. Ein höherer Wert als erwartet bedeutet, dass einige Ansichten unbemerkt rendern.

SceneCaptureComponent Support kann abgeschaltet werden, wenn SceneCapture überhaupt nicht genutzt wird, siehe Leistungsparameter.

SceneCaptureComponent Support für mehrere Viewports konfigurieren

9.2 Modus der Traversierung

Zu Bereich und Standardwert siehe Leistungsparameter: Default Traversal Type

Den Standard-Traversierungsmodus Frustum oder Circle wählen

Circle passt zu gekrümmten Bildwänden, nDisplay und 360-Grad-Panoramen, die Daten in jeder umliegenden Richtung brauchen; Frustum ist der Standardbasiswert für einen einzelnen Viewport.

Ein gewöhnliches Projekt mit einer Kamera nicht allein deshalb auf Circle umstellen, um „fehlende Chunks in jeder Richtung zu verhindern“: Es zieht den gesamten kreisförmigen Bereich um die Kamera in die Traversierung, während der Frustum-Modus nur den sichtbaren Teil verarbeitet. Wenn der Arbeitsablauf Circle erfordert, Max Distance, die Punktgrenze und die Auflösung bei mehreren Viewports entsprechend einengen.

Die LCC2-Pipeline braucht kein Anpassen dieser Option; bei Frustum bleiben.

9.3 Kollision und Navigation

Zur Funktionsbeschreibung siehe Kollision und Unterstützung des Navigation System. Dieser Abschnitt behandelt nur die Abwägungen zur Leistung.

Mit abgeschalteter Kollision gibt es keine Kollisionsdistanz abzustimmen. Sobald sie aktiviert ist, können Kollisionslesevorgänge, asynchrones Physik-Backen und NavMesh-Aktualisierungen CPU-Kosten, Arbeitsspeicherbedarf und Ruckeln hinzufügen. Zu beachten: Solche Kosten zeigen sich nicht zwangsläufig in der FPS-Anzeige und erfordern eine gesonderte Prüfung der kollisionsbezogenen Statistiken.

Zu Bereich und Standardwert der Kollisionsdistanz siehe Leistungsparameter: Max Load Collision Distance(m)

1. In Projekten, die nur der Präsentation dienen, die Kollision vollständig abschalten.
2. Wird Kollision gebraucht, das Kontrollkästchen links des Parameters anhaken und Max Load Collision Distance(m) auf den tatsächlichen Interaktionsbereich setzen.

Die Ladedistanz für Kollision Max Load Collision Distance setzen

Änderungen des dynamischen Kollisionsbereichs nach dem Anpassen der Ladedistanz für Kollision

3. Renderdistanz und Kollisionsdistanz nicht mechanisch auf denselben Wert setzen. In der Ferne sichtbar bedeutet nicht, dass dort physische Kollision gebraucht wird.
4. Ein Senken der Kollisionsdistanz begrenzt unmittelbar den Bereich, der Spielerinteraktion und KI zur Verfügung steht, daher nach einer Änderung einen funktionalen Regressionstest fahren statt nur auf die Bildrate zu schauen.

Die Strategie ist umgekehrt, wenn Navigation genutzt wird: Die Kollisionsdistanz sollte den für Spieler erreichbaren Bereich so weit wie möglich abdecken, damit die Kollision dieser Bereiche in einem Durchgang lädt. Kollision wird dynamisch in Chunks geladen, und das Einlagern eines neuen Kollisions-Chunks zur Laufzeit löst einen Neuaufbau der Navigationsdaten aus, was deutliches Ruckeln verursacht.

Unterstützende Punkte:

• NavMeshBoundsVolume den Aktivitätsbereich des Spielers abdecken lassen und bestätigen, dass die Kollision innerhalb dieses Bereichs vollständig geladen ist
• Static-Backen vorziehen und Dynamic-Backen vermeiden, da letzteres bei jeder Änderung der Kollision fortlaufend neu aufbaut

9.4 Single Layer Water (nur LCC2-Pipeline)

Zur Funktionsbeschreibung und zur vollständigen Konfiguration siehe Unterstützung von Single Layer Water. Dieser Abschnitt behandelt nur die Abwägungen zur Leistung.

SingleLayerWater Support ist eine globale Option in den Projekteinstellungen, aber ihre Umsetzung beruht auf der Median-Tiefe von LCC2, sie wird daher an Actors der LCC-Pipeline nicht wirksam.

• Sie abgeschaltet lassen, wenn Single Layer Water nicht genutzt wird;
• Nach dem Aktivieren ist ein Neustart erforderlich;
• Die Kosten sind, dass Wasserpixel Schattenqualität der Virtual Shadow Map verlieren, was eine funktionale und keine rein leistungsbezogene Abwägung ist;
• Sie nur aktivieren, wenn 3DGS von einem Single-Layer-Water-Material fehlerhaft verdeckt wird.