3DGS-Rendering-Mechanismus und Verwaltung des Grafikspeichers

Dieses Dokument beschreibt, wie Daten in den Grafikspeicher gelangen und am Rendering teilnehmen, samt der Zuweisungsregeln und Kapazitätsgrenzen des Grafikspeichers. Zur Anpassung der Bildparameter siehe Bildeinstellungen. Zu den Ladevorgängen siehe Schnellstart.

Begriffe: Die kleinste Einheit von Laden und Rendering nach der Aufteilung der Daten heißt Node. Die Genauigkeit jedes Nodes wird über sein Level angegeben: Level 0 hat die höchste Genauigkeit, ein größeres Level bedeutet geringere Genauigkeit. Diese Definitionen entsprechen denen in Leistungsparameter.

Chunk-Rendering und Rendering mit vollständigem Laden

Nach dem Laden der Daten gibt es zwei Wege, sie zu rendern: sichtbare Nodes bei Bedarf laden (Chunk-Rendering) oder den gesamten Datensatz auf einmal laden (Rendering mit vollständigem Laden). Das Standardverhalten unterscheidet sich je Pipeline:

Hinweis: „Chunk“ bedeutet in diesem Dokument, dass die Daten in räumliche Nodes aufgeteilt und bei Bedarf geladen werden, was sich von der Tiled-Rasterisierung unterscheidet, wo die Tiles Tiles aus Bildschirmpixeln sind. Das eine entscheidet, wie Daten in den Grafikspeicher gelangen, das andere, wie bereits dort liegende Daten gezeichnet werden. Beide sind unabhängig.

Chunk-Rendering

Die Daten werden in räumliche Nodes aufgeteilt, und jeder Node enthält mehrere Levels. Jedes Bild wird folgendermaßen verarbeitet:

Traversierung (sichtbare Nodes nach Kameraposition und -ausrichtung filtern, je Node ein Level wählen)
      │
      ▼
Laden (Daten der gewählten Nodes in den Arbeitsspeicher lesen)
      │
      ▼
Upload (Daten in den Grafikspeicher übergeben)
      │
      ▼
Rendering

Nahe Nodes verwenden ein niedriges Level, ferne Nodes ein hohes Level, und unsichtbare Nodes werden nicht geladen. Ein Node, der das Blickfeld verlässt, wird nicht sofort freigegeben; er bleibt im Cache und kann direkt wiederverwendet werden, wenn er erneut ins Blickfeld kommt. Erst wenn der Grafikspeicher knapp wird, werden die am längsten nicht genutzten Nodes verdrängt, anhand von Kriterien wie dem letzten Rendering-Zeitpunkt. Der Grafikspeicherbedarf hängt vor allem vom aktuell sichtbaren Bereich ab, weshalb große Szenen unterstützt werden können.

Die beiden Pipelines übergeben Draws unterschiedlich:

Inhärente Kosten des Chunk-Renderings:

• Benachbarte Nodes können unterschiedliche Levels erhalten, dadurch unterscheiden sich Dichte und Schärfe an der Grenze und Node-Ränder werden sichtbar
• Levels wechseln fortlaufend, während sich die Kamera bewegt, was zu Detail-Popping führen kann

Rendering mit vollständigem Laden

Der Schritt der kamerabasierten Node-Filterung entfällt. Der gesamte Datensatz wird auf einmal geladen und bleibt im Grafikspeicher resident, Kamerabewegungen lösen also keine Traversierung und keine Level-Auswahl mehr aus.

Vorteile:

• Die gesamte Szene nutzt ein einziges Level, es gibt keine Level-Unterschiede zwischen Nodes und keine sichtbaren Node-Ränder
• Die Daten bleiben im Grafikspeicher resident, Kamerabewegungen verursachen also kein Laden, kein Freigeben und kein Detail-Popping
• Der Aufwand für Traversierung und Upload pro Bild entfällt, was die Bildrate stabiler macht

Der Preis: Alle Daten bleiben im Grafikspeicher resident, und der Bedarf wächst linear mit der Szenengröße, was nur für kleine Szenen geeignet ist.

Kriterien für das Rendering mit vollständigem Laden

Ob mit vollständigem Laden gerendert wird, entscheidet sich beim Laden anhand des Schalters Use Full Load und der Splat-Anzahl auf Level 0:

Load(Datendatei)
      │
      ▼
Splat-Anzahl auf Level 0 lesen
      │
      ▼
Use Full Load aktiviert? ── Nein ──▶ Chunk-Rendering
      │ Ja
      ▼
Splat-Anzahl ≤ Full Load Splat Number? ── Nein ──▶ Chunk-Rendering
      │ Ja
      ▼
   Rendering mit vollständigem Laden

Beide Eigenschaften liegen im Details-Panel des Actors unter der Kategorie Performance:

Die Standardwerte unterscheiden sich je Actor-Typ:

Wann bei LCC2 vollständiges Laden manuell aktiviert wird

In der LCC2-Pipeline ist das Rendering mit vollständigem Laden standardmäßig deaktiviert. In diesen Fällen manuell aktivieren:

• Die Szene ist begrenzt groß, der Grafikspeicher reicht aus, und Bildqualität sowie Bildrate müssen stabil bleiben
• Die Kamera bewegt sich schnell oder springt häufig, das Laden der Nodes kommt nicht mit, und es treten Löcher oder Detail-Popping auf
• Produktpräsentationen, Bildschirmaufnahmen, Sequenz-Rendering und andere Fälle, in denen Bildänderungen während des Ladens nicht akzeptabel sind
• Dichteunterschiede an Node-Grenzen sind weiterhin sichtbar

Wenn nach der Aktivierung der Grafikspeicher knapp wird oder die Bildrate sinkt, hat die Szene den für vollständiges Laden geeigneten Rahmen überschritten; dann zurück zum Chunk-Rendering wechseln.

Hinweis: Auch beim Rendering mit vollständigem Laden gilt die maximale Renderdistanz. Überschreitet der Abstand zwischen Kamera und Daten diesen Wert, wird nichts dargestellt.

Grafikspeicher-Budget und Kapazitätsgrenzen

Die LCC2-Pipeline fasst die residenten Splat-Daten für das Rendering in einem einzigen Buffer zusammen; wie viele Daten ein einzelnes Modell laden kann, hängt daher von den Kapazitätsgrenzen dieser Buffer ab.

Buffer-Struktur und Bedarf pro Splat

Die Daten liegen in zwei Buffern:

Der Buffer der Kugelflächenfunktionen wird nach dem Band belegt, das die Daten tatsächlich mitbringen: 12 Byte bei Band 1, 27 Byte bei Band 2 und 48 Byte bei Band 3. Daten mit niedrigerem Band reservieren keinen Platz für das höchste Band, sodass derselbe Grafikspeicher mehr Splats aufnimmt.

Harte Grenze eines einzelnen Buffers

Unreal erfasst Buffer-Größen als 32-Bit-Ganzzahlen, was eine theoretische Grenze von 4 GB ergibt. Das Plugin nutzt tatsächlich 4095 MB (1 MB weniger als 4 GB), und der reservierte Rest verhindert einen Überlauf bei der Byte-Berechnung während des Uploads. Diese Grenze gilt je Buffer separat und lässt sich nicht über Einstellungen erhöhen.

Einstellung des Grafikspeicher-Budgets

Der Grafikspeicher, den ein einzelnes .lcc2-Modell resident halten kann, wird über LCC2 GPU Memory Budget (MB) unter ProjectSettings > Plugins > LCC4Unreal gesteuert:

Das Budget ist die Summe für beide Buffer, nicht die Grenze eines einzelnen. Daten mit Kugelflächenfunktionen von Band 3 zählen daher mit 88 Byte pro Splat (40 + 48), Daten ohne sie mit 40 Byte.

Dieses Budget begrenzt das Residenzfenster des Streaming-Ladens und gilt damit nur für .lcc2, wo Nodes ein- und ausgelagert werden können. Einzeldateiformate (.ply / .spz / .sog) müssen vollständig resident bleiben und haben eigene Kapazitätsregeln, siehe Ladegrenzen von Einzeldateiformaten.

Zusätzlicher Aufwand des Sortier-Buffers

Bevor 3DGS gerendert wird, werden die Splats nach ihrem Abstand zur Kamera sortiert. Das Sortierergebnis hängt von der Ansicht ab, jede Ansicht benötigt daher eigene Sortier-Buffer. Dieser Teil zählt nicht in das obige Budget: Jeder residente Splat kostet zusätzlich 16 Byte pro Ansicht (je zwei Kopien von Sortierschlüssel und Index, für abwechselndes Lesen und Schreiben während der Sortierung).

Mit dem Budget von 2048 MB und Daten mit Kugelflächenfunktionen können rund 24,4 Millionen Splats resident bleiben, und der Sortier-Buffer einer einzelnen Ansicht liegt bei etwa 372 MB.

Linkes und rechtes Auge beim Stereo-Rendering, jeder Spieler im Splitscreen und jedes SceneCapture zählen jeweils als eine Ansicht. Sortier-Buffer wachsen mit der Anzahl der Ansichten und schrumpfen nicht wieder, wenn die Anzahl sinkt; daher Grafikspeicher für die höchste aufgetretene Anzahl an Ansichten einplanen.

Ladegrenzen von Einzeldateiformaten

Einzeldateiformate sind .ply / .spz / .sog, also Formate, die den gesamten Datensatz in einer Datei halten, ohne Node-Aufteilung und ohne Level-Informationen. Solche Daten lassen sich nicht in Teilen laden: Das Plugin kann sie nur als einen einzigen Node in einem Durchgang dekodieren und muss sie vollständig im Grafikspeicher resident halten, es gibt daher eine feste Grenze für die Splat-Anzahl. .lcc und .lcc2 schließen die Node-Aufteilung bereits beim Export ab und sind keine Einzeldateiformate.

Wie die Grenze berechnet wird

Die Grenze der Einzeldateiformate ist nicht an LCC2 GPU Memory Budget gebunden. Dieses Budget bemisst das Residenzfenster des Streaming-Ladens, was nur für .lcc2 sinnvoll ist, wo Nodes ein- und ausgelagert werden können. Eine Einzeldatei ist ein Node, der vollständig resident sein muss; dieselbe Zahl darauf anzuwenden würde daraus eine künstliche Kapazitätsgrenze machen, die Modelle abweist, welche die Grafikkarte bequem halten könnte. Die Kapazität einer Einzeldatei wird deshalb direkt von der Hardware bestimmt, und eine Änderung des Budgets ändert daran nichts.

Das Plugin berechnet die Grenze vor dem Laden und weist Daten ab, die sie überschreiten. Die Grenze ist der kleinere der beiden folgenden Werte:

Der Grafikspeicher wird mit den physischen Kosten pro Splat gerechnet, einschließlich der 16 Byte des Sortier-Buffers. Auf Plattformen, auf denen der Grafikspeicher der Karte nicht abgefragt werden kann, wird nur die Grenze des einzelnen Buffers verwendet, statt eine Zahl zu schätzen.

Das Band der Kugelflächenfunktionen verändert die Kapazität direkt: Bei Band-1-Daten beträgt der Stride der Kugelflächenfunktionen 12 Byte, ein Viertel von Band 3 (48 Byte), sodass dieselbe Karte deutlich mehr Splats hält. Das Plugin rechnet mit dem Band, das die Daten tatsächlich mitbringen, statt immer die breitesten 48 Byte anzunehmen.

Was jenseits der Grenze passiert

Überschreiten Einzeldateidaten die Grenze, wird das Laden abgewiesen, und das Output Log gibt die tatsächliche Splat-Anzahl und die aktuelle Grenze aus, dazu die Angabe, ob die Grenze von der Beschränkung des einzelnen Buffers oder vom verfügbaren Grafikspeicher kommt. Behandlung in dieser Vorzugsreihenfolge:

1. Nach .lcc2 konvertieren, damit das Plugin bedarfsgesteuert lädt statt alles resident zu halten; die Gesamtmenge der Daten unterliegt dieser Grenze dann nicht mehr.
2. Auf Daten mit niedrigerem Band der Kugelflächenfunktionen oder ganz ohne sie wechseln, wodurch die Grafikspeicherkosten pro Splat sinken.
3. Auf eine Karte mit mehr Grafikspeicher wechseln. Ist der verfügbare Grafikspeicher der Engpass, ist dies die einzige Hardwaremaßnahme, die die Grenze erhöht.

Ein Wechsel nach .sog oder .spz hilft nicht, die Grenze zu überschreiten: Die Kompression dieser Formate betrifft nur die Datei auf dem Datenträger, und jeder Splat belegt nach dem Dekodieren exakt gleich viel Grafikspeicher.

Das LCC2-Format unterliegt dieser Grenze nicht

.lcc2 teilt Daten in mehrere Nodes auf, und jeder Node wird separat dekodiert und hochgeladen. Ein einzelner Node bleibt weit unter den oben genannten Grenzen, die Gesamtmenge der Daten hat daher keine harte Grenze und kann das Grafikspeicher-Budget deutlich überschreiten. Begrenzt sind zwei Laufzeitgrößen:

Die pro Bild gerenderte Menge ist außerdem durch Max Splat Num am Actor begrenzt, der kleinere der beiden Werte greift.

Verwaltung und Optimierung des Grafikspeichers

Automatische Freigabe bei knappem Grafikspeicher

Zur Laufzeit überwacht das Plugin fortlaufend den tatsächlichen Grafikspeicherbedarf der Grafikkarte. Übersteigt der Bedarf den durch Max GPU Usage Percentage For Release in den ProjectSettings gesetzten Prozentwert, werden Nodes anhand einer Kombination aus letztem Rendering-Zeitpunkt, Zugriffshäufigkeit, Datengröße und Level bewertet, und die am längsten nicht genutzten werden zuerst freigegeben. Nodes mit hohem Level werden geschützt, damit beim schnellen Drehen der Ansicht keine großen Löcher entstehen.

Zugehörige Einstellungen:

Ein zu kleines Budget erkennen und anpassen

Ein zu kleines Budget führt nicht zu einem Ladefehler, stattdessen werden die Daten fortlaufend ein- und ausgelagert. Häufige Symptome:

• Löcher treten auf, während sich die Kamera bewegt oder dreht, und füllen sich nach dem Anhalten allmählich
• Derselbe Bereich wird beim Hin- und Herschwenken der Ansicht wiederholt scharf und unscharf
• Ein lokaler Bereich bleibt unscharf und wird auch beim Annähern nicht scharf
• Die Bildrate schwankt mit der Menge des sichtbaren Inhalts und sinkt in offenen Ansichten deutlich
• Das Verhalten ist bei statischer Szene normal, ruckelt aber bei Bewegung

Lokale Unschärfe wird leicht für schlechte Datenqualität gehalten. Wenn Daten mit niedrigem Level nicht rechtzeitig geladen werden können, füllt das Plugin die Lücke mit den bereits im Grafikspeicher liegenden Daten hohen Levels, damit kein Bildteil fehlt, und ersetzt sie, sobald die Daten niedrigen Levels bereit sind. Wenn wegen zu wenig Grafikspeicher die Daten niedrigen Levels wiederholt verdrängt werden, bleibt dieser Bereich auf einem hohen Level. Der Test ist, ob er beim Annähern scharf wird: normalerweise genügen eine bis zwei Sekunden zum Auffüllen, und wenn sich nichts ändert, gelangen die Daten niedrigen Levels nicht in den Grafikspeicher.

Bestätigung: Den beim Laden im Output Log ausgegebenen prognostizierten Bedarf des Modells prüfen und mit dem aktuellen Budget vergleichen. Nähert sich der prognostizierte Bedarf eines einzelnen Modells dem Budget oder übersteigt es, reicht der residente Platz nicht aus. Die Anzahl der Freigaben lässt sich außerdem mit stat LCC beobachten; ein fortlaufend steigender Wert deutet auf häufiges Verdrängen hin.

Das Budget zu erhöhen wirkt nur, wenn die Grafikkarte Reserven hat. Das Budget ist lediglich die Obergrenze, die das Plugin anfordert; überschreitet es den tatsächlich auf der Karte verfügbaren Grafikspeicher, lagert der Treiber Daten in den Systemspeicher aus, und der Bildraten-Einbruch ist schlimmer als das Ein- und Auslagern. Folgende Reihenfolge abarbeiten:

1. Den verfügbaren Grafikspeicher der Karte prüfen. Nach Hinzurechnen des Aufwands für den Sortier-Buffer sollte das Budget Reserven für die Engine selbst und weitere Ressourcen lassen.
2. Das Budget schrittweise erhöhen (2048 → 4096 → 8192) und nach jedem Neustart prüfen, ob sich Löcher und Bildrate verbessern.
3. Fällt die Verbesserung gering aus, ist das Budget nicht der Engpass; dann stattdessen die Datenmenge senken: Max Splat Num verringern, die Begrenzung Max Distance aktivieren oder auf Daten ohne Kugelflächenfunktionen wechseln.

Hinweis: Das Budget wird je Modell unabhängig berechnet. Sind mehrere LCC-Actors in einer Szene platziert, summiert sich der Grafikspeicherbedarf mit der Anzahl der Modelle; das Budget pro Modell entsprechend senken.