URP oder HDRP: die richtige Unity Render Pipeline wählen

Die Demo sah super aus, der Switch-Build nicht

Im November 2024 haben wir zu dritt an einem Vertical Slice gearbeitet. Die Unity Render Pipeline war in fünf Minuten gewählt: HDRP, weil der volumetrische Nebel in der Scene View gut aussah. Die Liste der Zielplattformen lag in einer Tabelle, die an dem Tag niemand geöffnet hat — Steam, Nintendo Switch und ein möglicher Quest-Port. Niemand im Team hatte je etwas mit HDRP veröffentlicht; die Entscheidung hing an einem Screenshot.

In Woche fünf haben wir den Switch-Build versucht. HDRP baut für diese Plattform überhaupt nicht; HDRenderPipelineAsset erwartet Compute Shader und eine API der Klasse DX11/Vulkan/Metal. Quest lief gegen dieselbe Wand. Das war also keine übersehene Einstellung, sondern die allererste Entscheidung.

Der Rückbau kostete 11 Arbeitstage: 190 Materialien, 60 Lichter, zwei VolumeProfile-Assets und vier eigene Shader. Die Frage URP oder HDRP wäre an Tag eins mit einer fünfminütigen Plattformtabelle beantwortet gewesen. Ich habe aus diesen fünf Minuten 11 Tage gemacht, deshalb dieser Text. Seitdem liegt in jedem Projekt eine Plattformtabelle im ersten Commit, mit der Pipeline-Zeile darin.

Deine Plattformliste hat längst entschieden

Ich beginne die Pipeline-Entscheidung heute mit einer Geräte-Tabelle, nicht mit der Art Direction. HDRP wird auf OpenGL ES, Nintendo Switch, Quest und WebGL nicht unterstützt. Steht auch nur eine dieser vier Zeilen im Projekt, ist die Diskussion beendet. Das ist kein Geschmack, das ist Unitys offizielle Support-Matrix, und die Release Notes sagen dasselbe.

Die Universal Render Pipeline kennt keine solche Grenze. Vom Mittelklasse-Smartphone mit GLES3.0 bis zur Xbox Series X shippst du mit derselben UniversalRenderPipelineAsset-Struktur, definierst pro Geräteklasse ein Asset und hängst es über QualitySettings ein. Renderer-Assets nach Geräteklasse zu trennen macht es unkompliziert, ein niedriges und ein hohes Profil in einem Projekt zu führen. HDRP lässt sich genauso aufteilen, nur bleibt der Boden der Boden von HDRP.

Für die Basiskosten habe ich einen simplen Test gefahren: RTX 3060, 1080p, leere Szene mit einem einzigen Directional Light. URP brauchte 0,9 ms GPU-Zeit, HDRP 4,3 ms. Diese 3,4 ms zahlst du, bevor ein einziges Mesh oder Material in der Szene liegt; Depth Prepass, Motion Vectors, GBuffer und das bereitstehende volumetrische Froxel-Grid sind nicht umsonst. Die Zahlen habe ich in RenderDoc genommen und nicht über FrameTimingManager, weil die Werte im Editor irreführend freundlich zu HDRP ausfielen.

Beim Speicher dasselbe Bild. In derselben Szene mit 1440p hielten HDRPs RTHandle-Pools rund 640 MB, URP kam mit 180 MB aus. Auf einer 8-GB-Karte geht diese Lücke direkt vom Texturbudget ab, und kein Herunterdrehen der Unity Grafik-Einstellungen holt sie zurück. Im selben Test brachte HDRPs Shader-Variant-Cache beim ersten Start zusätzlich 40 Sekunden Kompilierpause.

Wo URP auf Mobile und Mittelklasse-PC gewinnt

Ich habe dieselbe Szene in beiden Pipelines aufgebaut und gemessen: 420.000 Dreiecke, 38 Lichter, SSAO an. Auf einer GTX 1650 bei 1080p lag URP bei 7,1 ms, HDRP bei 15,6 ms. Wer eine Mittelklasse-Karte anvisiert, hat damit den Unterschied zwischen 60 fps und 45 fps. Beide Durchläufe nutzten identische Assets, dieselbe Schattenauflösung und dieselbe Schattendistanz — die Lücke ist kein Artefakt der Einstellungen.

Der Forward+-Pfad aus URP 14 hat das Limit von acht Lichtern pro Objekt abgeschafft. Ich schattiere heute über 200 Point Lights in einem einzigen Pass, ohne auf Deferred zu wechseln oder Lichter von Hand in Gruppen zu schneiden. Genau diese Einschränkung war früher eines der ehrlichen Argumente für HDRP; das ist sie nicht mehr. Die Kosten wachsen mit der Bildschirmabdeckung statt mit der Lichtanzahl, deshalb sind schmale Spot Lights fast geschenkt.

Auf Mobile ist der eigentliche Gewinn die Bandbreite. Auf einem Adreno 730 hatte ich für 60 fps ein Budget von 16,6 ms; URPs Single-Pass-Forward-Pfad hält MSAA 4x im Tile Memory und faltet das Post-Processing in einen einzigen UberPost-Pass. In einem Versuch, bei dem ich Bloom und Tonemapping in getrennte Passes gelegt habe, kamen allein über die Bandbreite 2,4 ms zurück. Jede auf dem Telefon gesparte Millisekunde ist außerdem thermisches Budget; über eine Sitzung von zehn Minuten driftete die Frame-Zeit 15 % weniger.

Was fehlt, ergänze ich über ScriptableRendererFeature: planare Reflexionen, ein Outline-Pass, eigene Decals. Ein paar der Dinge zurückzuholen, die HDRP ab Werk mitbringt, sind zwei bis drei Tage Arbeit. HDRPs Basiskosten zurückzuholen ist dagegen überhaupt nicht möglich. Diese Features liegen bei mir in einer eigenen Assembly, damit sie im Asset für schwache Geräte nie geladen werden.

Die HDRP-Rechnung: Volumetrics, SSR und Path Tracing

Die Features, die HDRP rechtfertigen, sind echt — sie sind nur nicht umsonst. Volumetrischer Nebel arbeitet froxelbasiert und liefert korrekte Streuung pro Licht; im Fog-Override habe ich 1,3 ms bei Medium und 3,6 ms bei High gemessen (3060, 1440p). Für einen einzelnen Effekt ist das ein ernstes Stück. Sein sichtbarer Beitrag bricht außerdem ein, sobald die halbe Szene Innenraum ist — die Rechnung kommt trotzdem in jedem Frame.

ScreenSpaceReflection pendelte bei 1440p zwischen 1,8 und 2,4 ms und kann noch immer nichts spiegeln, was außerhalb des Bildes liegt. Die Ray-Traced-Variante verlangt DXR-Hardware und kletterte in derselben Szene auf einer 3060 auf 5,9 ms. Die Diskussion um HDRP Performance verknotet sich meistens genau hier, am Preisschild einzelner Effekte. In Innenräumen habe ich 60 % derselben Wirkung mit planaren Reflection Probes für 0,4 ms bekommen.

Path Tracing ist nicht echtzeitfähig. Es akkumuliert Samples über mehrere Frames; ein sauberer Frame mit 512 Samples dauert bei mir 20 bis 40 Sekunden. Für Cinematics, Key Art und Marketing-Renderings ist das ein hervorragendes Werkzeug, für Gameplay keine Option. Deshalb halte ich es komplett aus der Pipeline-Entscheidung heraus und fahre es in einer separaten Render-Szene.

Diese drei sind die richtige Antwort für ein innenraumlastiges, visuell getriebenes Projekt mit kontrollierter Kamera, das auf PC und Konsole erscheint. Sobald du HDRP aber auf die niedrigsten Einstellungen drückst, um eine breite Hardware-Spanne abzudecken, sieht das Ergebnis sehr nach URP aus. Wenn du dann nicht erklären kannst, wofür du die Basiskosten noch bezahlst, war die Wahl falsch. Und wenn im Team niemand HDRPs Volume-Layer und die Exposure-Kette kennt, steigt die Rechnung noch eine Stufe.

Shader Graph oder handgeschriebenes HLSL?

Shader Graph wirkt zwischen den Pipelines portabel, aber das stimmt nur auf Ebene des Master Stacks. In dem Moment, in dem du einen Custom Function-Node in den Graph legst und URPs Lighting.hlsl includierst, kompiliert dieser Graph unter HDRP nicht mehr. Die Portabilität hält genau so lange, wie du nichts Besonderes machst. Der erzeugte Code ist außerdem nicht lesbar; Debugging heißt, sich durch 900 Zeilen Show Generated Code zu scrollen.

HLSL von Hand zu schreiben heißt, sich direkt an eine Pipeline zu binden. In URP stützt du dich auf die Funktionen unter Packages/com.unity.render-pipelines.universal/ShaderLibrary/, während HDRP dir eine völlig andere Lighting-API rund um SurfaceData und BSDFData hinstellt. Meinen Toon Shader nach HDRP zu portieren hieß, rund 70 % der Zeilen neu zu schreiben. Heute ziehe ich die Beleuchtungsmathematik in eine gemeinsame .hlsl-Datei und includiere sie von beiden Seiten; das Portieren ist damit nicht umsonst, nur günstiger.

Auch die Zahl der Varianten spielt in die Entscheidung hinein. Shader Graph ist großzügig mit multi_compile; ein Set aus vier Graphs trieb die Shader-Kompilierung auf 11 Minuten. Die unnötigen auf shader_feature umgestellt und mit einer ShaderVariantCollection gestrippt, waren es noch 3. Meine Regel ist simpel: Materialien, die das Art-Team anfasst, kommen in Shader Graph, Shader auf dem heißen Pfad und plattformspezifische Shader schreibe ich von Hand in HLSL.

Wechsel mitten im Projekt und meine Empfehlung

Ich habe die Rechnung für eine Migration einmal mitgeschrieben, und sie sieht so aus. Von 640 Materialien hat der Render Pipeline Converter 68 % automatisch erledigt; die restlichen 205 habe ich von Hand nachgezogen. Die meisten davon nutzten eigene Shader oder Detail Maps, und der Converter weist ihnen stillschweigend ein leeres Lit-Material zu. Geh nicht weiter, ohne seinen Report zu lesen; nur dort tauchen die stillen Fehlschläge auf.

Am hinterhältigsten sind die Lichter. HDRP rechnet in physikalischen Einheiten — die Sonne liegt bei rund 100.000 Lux — während dasselbe Licht in URP einen willkürlichen Intensitätswert trägt. Der Converter legt einen ungefähren Multiplikator an, aber in einer Szene mit 60 Lichtern musste ich 20 davon nach Augenmaß neu ausbalancieren. Danach kam ein vollständiges Rebake von Lightmaps und Reflection Probes: sechs Stunden Maschinenzeit.

Beim Post-Processing nutzen beide Pipelines das Volume-System, nur überschneiden sich die Override-Sets nicht. Exposure, Fog und ScreenSpaceReflection gibt es in URP nicht; ihre Rolle übernehmen ColorAdjustments und handgeschriebene Renderer Features. Dazu kommen die Third-Party-Assets: Jedes Shader-Paket aus dem Store bringt sein eigenes Problem mit der Zielpipeline mit. Unterm Strich waren es zwei Personen über drei Wochen, in denen kein einziges neues Gameplay-Feature entstanden ist.

Meine Entscheidungstabelle sieht so aus. Stehen Mobile, Quest, Switch oder WebGL auf der Liste, oder weißt du noch nicht, auf welche Hardware du shippst, nimm URP und beende die Debatte. Zielst du nur auf PC und Konsole, hältst eine GTX 1660 als Untergrenze, baust ein innenraumlastiges, visuell getriebenes Spiel und hast einen Vollzeit-Grafikprogrammierer im Team, verdient HDRP seine Kosten. Sitzt du dazwischen, nimm URP und schließ die Lücken mit ScriptableRendererFeature — und triff diese Entscheidung an Tag eins des Prototyps, nicht in Woche fünf.