URP ou HDRP : bien choisir son render pipeline Unity

La démo était superbe, le build Switch beaucoup moins

En novembre 2024, nous étions trois sur une vertical slice. Le choix de la render pipeline Unity a pris cinq minutes : HDRP, parce que le brouillard volumétrique rendait bien dans la Scene view. La liste des plateformes visées dormait dans un tableau que personne n'a ouvert ce jour-là — Steam, Nintendo Switch et un portage Quest éventuel. Personne dans l'équipe n'avait jamais sorti de jeu sous HDRP ; la décision tenait à une capture d'écran.

En semaine cinq, nous avons tenté le build Switch. HDRP ne compile tout simplement pas pour cette plateforme ; HDRenderPipelineAsset attend des compute shaders et une API de la classe DX11/Vulkan/Metal. Quest se heurtait au même mur. Ce n'était donc pas un réglage oublié, mais la toute première décision.

Le retour en arrière a coûté 11 jours ouvrés : 190 matériaux, 60 lumières, deux assets VolumeProfile et quatre shaders maison. La question URP ou HDRP aurait pu être tranchée le premier jour avec un tableau de plateformes de cinq minutes. J'ai transformé ces cinq minutes en 11 jours, d'où ce texte. Depuis, chaque projet commence par un tableau de plateformes dans le premier commit, avec la ligne pipeline écrite dedans.

Votre liste de plateformes a déjà tranché

Aujourd'hui, je commence le choix de pipeline par un tableau d'appareils, pas par la direction artistique. HDRP n'est pas supporté sur OpenGL ES, Nintendo Switch, Quest ni WebGL. Si l'une de ces quatre lignes figure dans le projet, la discussion s'arrête là. Ce n'est pas une question de goût, c'est la matrice de support officielle d'Unity, et les release notes disent la même chose.

L'Universal Render Pipeline n'a pas ce genre de couperet. Vous sortez du téléphone milieu de gamme en GLES3.0 jusqu'à la Xbox Series X avec la même structure d'UniversalRenderPipelineAsset, en définissant un asset par classe d'appareil et en le branchant via QualitySettings. Séparer les assets de renderer par palier matériel rend simple le fait de porter un profil bas et un profil haut dans le même projet. On peut découper HDRP de la même façon, mais son plancher reste le plancher de HDRP.

Pour mesurer le coût de base, j'ai fait un test simple : RTX 3060, 1080p, scène vide avec une seule directional light. URP a pris 0,9 ms de temps GPU, HDRP 4,3 ms. Ces 3,4 ms, vous les payez avant d'avoir posé le moindre mesh ou matériau ; le depth prepass, les motion vectors, le GBuffer et la grille de froxels volumétriques qui attend ne sont pas gratuits. J'ai relevé les chiffres dans RenderDoc plutôt qu'avec FrameTimingManager, parce que les valeurs de l'éditeur se montraient trompeusement clémentes avec HDRP.

Côté mémoire, même histoire. Dans cette scène en 1440p, les pools RTHandle de HDRP occupaient environ 640 Mo contre 180 Mo pour URP. Sur une carte de 8 Go, cet écart sort directement de votre budget de textures, et baisser les réglages graphiques Unity ne le récupère pas. Dans le même test, le cache de variantes de shaders de HDRP a aussi ajouté 40 secondes de compilation au premier lancement.

Ce que URP gagne sur mobile et PC milieu de gamme

J'ai monté la même scène dans les deux pipelines et mesuré : 420 000 triangles, 38 lumières, SSAO activé. Sur une GTX 1650 en 1080p, URP est sorti à 7,1 ms et HDRP à 15,6 ms. Si vous visez une carte milieu de gamme, cet écart, c'est la différence entre 60 fps et 45 fps. Les deux passages utilisaient les mêmes assets, la même résolution et la même distance d'ombres : l'écart n'est pas un artefact de réglages.

Le chemin Forward+ arrivé avec URP 14 a supprimé la limite de huit lumières par objet. Je peux désormais éclairer plus de 200 point lights en une seule passe sans basculer en deferred ni découper les lumières en groupes à la main. Cette limite était l'un des arguments honnêtes en faveur de HDRP ; elle ne l'est plus. Le coût grimpe avec la surface couverte à l'écran plutôt qu'avec le nombre de lumières, donc les spots étroits sont quasiment gratuits.

Sur mobile, le vrai gain est la bande passante. Sur un Adreno 730, mon budget pour 60 fps était de 16,6 ms ; le chemin forward en une passe d'URP garde le MSAA 4x en tile memory et replie le post-processing dans une unique passe UberPost. Dans un essai où j'avais séparé le bloom et le tonemapping en deux passes, 2,4 ms sont revenues rien que par la bande passante. Chaque milliseconde gagnée sur un téléphone est aussi du budget thermique ; sur une session de dix minutes, le temps de frame a dérivé 15 % de moins.

Ce qui manque, je l'ajoute avec ScriptableRendererFeature : réflexions planaires, passe d'outline, decals maison. Récupérer quelques-unes des choses que HDRP fournit d'origine représente deux à trois jours de travail. Récupérer le coût de base de HDRP, en revanche, est tout simplement impossible. Je garde ces features dans une assembly à part, pour qu'elles ne se chargent jamais dans l'asset destiné aux appareils d'entrée de gamme.

La facture HDRP : volumétrique, SSR et path tracing

Les fonctionnalités qui justifient HDRP existent bel et bien, elles ne sont simplement pas gratuites. Le brouillard volumétrique repose sur des froxels et donne une diffusion correcte par lumière ; dans l'override Fog, j'ai mesuré 1,3 ms en qualité Medium et 3,6 ms en High (3060, 1440p). Pour un seul effet, c'est une part sérieuse. Sa contribution visible s'effondre dès que la moitié de la scène est en intérieur, alors que la facture tombe à chaque frame.

ScreenSpaceReflection oscillait entre 1,8 et 2,4 ms en 1440p et reste incapable de refléter quoi que ce soit hors champ. La variante en ray tracing exige du matériel DXR et est montée à 5,9 ms dans la même scène sur une 3060. Le débat sur les performances HDRP se noue presque toujours ici, sur l'étiquette de prix de chaque effet. En intérieur, j'ai obtenu 60 % du même rendu avec des planar reflection probes pour 0,4 ms.

Le path tracing, lui, n'est pas temps réel. Il accumule des échantillons sur plusieurs frames ; une image propre à 512 échantillons me demande 20 à 40 secondes. C'est un excellent outil pour les cinématiques, la key art et les rendus marketing, mais ce n'est pas une option pour le gameplay. Je le sors donc entièrement du choix de pipeline et je le fais tourner dans une scène de rendu séparée.

Ces trois-là sont la bonne réponse pour un projet visuel à caméra maîtrisée, dominé par les intérieurs et destiné au PC et aux consoles. Mais dès que vous poussez HDRP à ses réglages les plus bas pour couvrir un large éventail de matériel, ce qu'il reste ressemble beaucoup à URP. Si à ce moment-là vous ne savez plus expliquer pourquoi vous payez encore le coût de base, le choix était mauvais. Et si personne dans l'équipe ne maîtrise les volume layers et la chaîne d'exposure de HDRP, la facture monte encore d'un cran.

Shader Graph ou HLSL écrit à la main ?

Shader Graph a l'air portable d'une pipeline à l'autre, mais ce n'est vrai qu'au niveau du master stack. Dès l'instant où vous posez un nœud Custom Function dans le graphe et où vous incluez le Lighting.hlsl d'URP, ce graphe ne compile plus sous HDRP. La portabilité tient exactement tant que vous ne faites rien de particulier. Le code généré n'est pas lisible non plus ; déboguer, c'est faire défiler 900 lignes de Show Generated Code.

Écrire du HLSL à la main, c'est se lier directement à une pipeline. Sous URP, vous vous appuyez sur les fonctions de Packages/com.unity.render-pipelines.universal/ShaderLibrary/, tandis que HDRP vous tend une API d'éclairage totalement différente, bâtie autour de SurfaceData et BSDFData. Porter mon toon shader vers HDRP a signifié réécrire environ 70 % des lignes. Depuis, je sors les calculs d'éclairage dans un fichier .hlsl commun que j'inclus des deux côtés ; le portage n'est toujours pas gratuit, seulement moins cher.

Le nombre de variantes pèse aussi dans la décision. Shader Graph est généreux en multi_compile ; un jeu de quatre graphes a fait grimper la compilation des shaders à 11 minutes. En basculant les variantes inutiles vers shader_feature et en nettoyant avec une ShaderVariantCollection, je suis redescendu à 3. Ma règle est simple : les matériaux que l'équipe artistique va toucher passent par Shader Graph, les shaders du chemin chaud et ceux spécifiques à une plateforme s'écrivent à la main en HLSL.

Changer en cours de projet, et ma recommandation

J'ai tenu la facture d'une migration une fois, et les chiffres ressemblent à ceci. Sur 640 matériaux, le Render Pipeline Converter en a traité 68 % automatiquement ; j'ai repris les 205 restants à la main. La plupart utilisaient des shaders maison ou des detail maps, et le converter leur attribue silencieusement un matériau Lit vide. N'avancez pas sans lire son rapport ; c'est le seul endroit où les échecs silencieux apparaissent.

Les lumières sont la partie la plus sournoise. HDRP raisonne en unités physiques — le soleil tourne autour de 100 000 lux — alors que sous URP la même lumière porte une valeur d'intensité arbitraire. Le converter applique un multiplicateur approximatif, mais dans une scène de 60 lumières j'ai dû en rééquilibrer 20 à l'œil. Ensuite est venu un rebake complet des lightmaps et des reflection probes : six heures de temps machine.

Côté post-processing, les deux pipelines utilisent le système de Volume, mais les jeux d'overrides ne se recouvrent pas. Exposure, Fog et ScreenSpaceReflection n'existent pas sous URP ; ColorAdjustments et des renderer features écrites à la main prennent leur place. S'ajoutent les assets tiers : chaque pack de shaders acheté sur le store apporte son propre problème de pipeline cible. Le total est monté à deux personnes pendant trois semaines, sans qu'une seule nouvelle fonctionnalité de gameplay ne sorte.

Voici mon tableau de décision. Si mobile, Quest, Switch ou WebGL figurent sur votre liste, ou si vous ignorez encore sur quel matériel vous allez sortir, prenez URP et arrêtez le débat. Si vous visez uniquement PC et consoles, que vous pouvez tenir une GTX 1660 comme plancher, que vous construisez un jeu visuel dominé par les intérieurs et que vous avez un programmeur graphique à plein temps dans l'équipe, HDRP mérite son coût. Si vous êtes entre les deux, prenez URP et comblez les manques avec ScriptableRendererFeature — et prenez cette décision le premier jour du prototype, pas en semaine cinq.