Unity-URP-Render-Graph-Passes: Abhängigkeiten deklarieren, bevor gezeichnet wird

Mit dem Ressourcenvertrag beginnen

Ein eigener Screen-Effekt ist mehr als der Aufruf eines Shaders. Er liest bestimmte Daten, erzeugt ein Ergebnis und hängt davon ab, wann diese Daten verfügbar werden. Dieser Vertrag sollte schriftlich festgehalten werden, bevor Rendering-Code zwischen Unity-Versionen verschoben wird. Dieser Artikel folgt der Unity-6.0-URP-Dokumentation; er beschreibt einen Migrationsansatz und behauptet nicht, dass eine einzige API-Signatur für jede URP-Version passt.

Aufzeichnen und Ausführen trennen

RecordRenderGraph registriert Passes und ihre Abhängigkeiten. Die Render-Funktion, die über SetRenderFunc übergeben wird, zeichnet die Zeichenbefehle auf, sobald der Pass ausgeführt wird. Die für diese Ausführung benötigten Daten gehören in die Pass-Datenstruktur. [1] Die Korrektheit eines Effekts sollte nicht von unabhängigen, veränderbaren Feldern abhängen, die zufällig noch Werte einer vorherigen Kamera enthalten.

Tatsächlichen Texturzugriff deklarieren

Bei einem Raster-Pass deklariert UseTexture eine gesampelte Eingabe und SetRenderAttachment ein Render-Target. Laut dem dokumentierten Ablauf darf dieselbe Textur in einem Raster-Pass nicht mit beiden Aufrufen verwendet werden; bei Bedarf sind getrennte Texturen und Passes einzusetzen. [2] Die Ressourcennamen dienen als Hilfe bei der Prüfung: Ein Reviewer sollte jede Eingabe bis zu ihrem Erzeuger und jede Ausgabe bis zu ihrem Verbraucher zurückverfolgen können.

Beispiel: eine Überwachungskamera mit Farbstich

Angenommen, eine Überwachungskamera zeigt einen grünen Warnfarbstich, solange ein Alarm aktiv ist. Der erste eigene Pass liest den Farbpuffer der gewählten Kamera und schreibt eine separate eingefärbte Textur. Ein nachfolgender Pass nimmt diese Textur entgegen und erzeugt daraus die vorgesehene Kameraausgabe. Festzulegen ist, welche Kameratypen infrage kommen, ob der Effekt vor oder nach anderem Post-Processing läuft und was bei inaktivem Alarm geschieht. Für die Migration empfiehlt sich, mit einem einfachen konstanten Farbstich zu beginnen, die Abhängigkeitskette zu prüfen und erst danach das animierte Alarmmuster wiederherzustellen. Verglichen wird eine Szene mit einer Kamera mit einer Szene, die sowohl eine Spielkamera als auch eine Vorschaukamera enthält. Das Beispiel legt einen Entwurf und eine Prüfreihenfolge fest, keinen produktionsreifen Code.

Grenzen der Migration und Prüfungen

Der Compatibility Mode deaktiviert den Render Graph, und laut der referenzierten Unity-Dokumentation fliesst der Entwicklungsaufwand in den Graph-Pfad. [3] Die Versionen von Editor und URP-Paket sollten festgehalten und die dazu passenden Beispiele befolgt werden. Texturgrösse, Format, Sample-Anzahl und Kamera-Eignung sind zu prüfen, bevor alter Allokationscode übernommen wird. Im Graph ist zu kontrollieren, dass Ausgaben verbraucht werden und die erwarteten Passes das Culling überstehen. Zu testen sind Grössenänderungen, deaktivierte Effekte und die Ziel-Grafik-API. Eine erfolgreiche Kompilierung belegt weder visuelle Korrektheit noch eine bessere Performance; Captures und Zeitmessungen sind mit dem ursprünglichen Effekt zu vergleichen.

Quellen

1. Write a render pass using the render graph system — Unity Technologies.
2. Use a texture in a render pass — Unity Technologies.
3. Compatibility Mode in URP — Unity Technologies.