Render Pipelines in Unity: Built-in, URP and HDRP

Every frame a game shows is the end of a long procession of decisions. Which objects are visible, in what order they should be drawn, how each light touches each surface, where shadows fall, how the final image is blurred, brightened or tinted before it reaches the screen: all of this is the work of a render pipeline. For most of Unity's history there was only one such pipeline, and most developers never had to think about it, in the way a traveller seldom thinks about the road beneath the carriage until it becomes rough.

That simplicity ended when Unity introduced the Scriptable Render Pipeline and, built upon it, two very different ready made pipelines: the Universal Render Pipeline, known as URP, and the High Definition Render Pipeline, known as HDRP. Today a new project must choose among these and the older Built-in Render Pipeline, and the choice has consequences that reach into every material, every shader, every lighting setup and every plugin bought from the Asset Store.

The difference between them is often described in terms of quality, as if HDRP were simply the beautiful one and URP the efficient one. That summary contains some truth but hides the more important point, which is that each pipeline is a separate renderer with its own architecture, assumptions and tools. Understanding what they share and where they part ways is the best defence against discovering, months into a project, that the pipeline chosen on the first day was the wrong one.

The Built-in renderer

The Built-in Render Pipeline is the renderer Unity shipped for most of its life, and it remains available. Its behaviour is fixed in the engine's C++ core and can be adjusted only through the hooks Unity provides: command buffers inserted at certain points, replacement shaders, and a choice between forward and deferred rendering paths. It is a general purpose renderer that tries to do a reasonable job on every platform, and its long history means that a vast body of tutorials, assets and community knowledge has grown up around it.

Its characteristic shader format is the surface shader, a convenient abstraction in which the author describes the properties of a surface, such as albedo, normal and smoothness, and Unity generates the lighting code automatically. Surface shaders made custom materials accessible to a generation of developers, and many older assets depend on them. They are also, and this weighs on any later decision, a Built-in feature: neither URP nor HDRP supports surface shaders, so materials built on them must be rewritten or converted when a project changes pipelines.

The Built-in renderer's weakness is that it is closed. If a project needs a rendering approach that the fixed pipeline was not designed for, the only routes are workarounds layered on top of it, and these grow fragile and costly. Unity has made clear that its future development lies with the scriptable pipelines; new rendering features arrive there rather than in the Built-in renderer, which is why it is now best regarded as a legacy option for existing projects rather than a starting point for new ones.

The scriptable foundation

The Scriptable Render Pipeline, introduced in Unity 2018.1, turns rendering from a fixed engine behaviour into something controlled from C#. The engine still performs the heavy lifting, culling objects, sorting them, and submitting draw calls to the graphics card, but the order and structure of that work are decided by a pipeline written in script. A pipeline is selected by assigning a Render Pipeline Asset in the project's Graphics settings, and quality levels can override that asset, so different hardware tiers can use different configurations of the same pipeline.

In principle anyone can write a pipeline from scratch on this foundation, and some studios with unusual needs do. In practice nearly everyone uses one of the two pipelines Unity provides, both of which are distributed as packages with their source code visible. That openness matters: when a developer wants to know why a shadow behaves oddly, the answer can be found by reading the pipeline's code rather than guessing at the behaviour of a black box.

The two pipelines also share important infrastructure. Both use the Volume framework for post-processing, in which effects such as bloom, colour grading, tonemapping and vignettes are configured in profiles and blended according to the camera's position within volumes placed in the scene. Both support the SRP Batcher, which reduces the CPU cost of draw calls for objects using compatible shaders by keeping material data persistently on the GPU. These shared ideas make moving between URP and HDRP easier than moving from Built-in to either.

Universal and High Definition

URP, which was called the Lightweight Render Pipeline until its renaming in Unity 2019.3, aims to run everywhere Unity runs: phones, tablets, consoles, desktop computers, virtual reality headsets and the web. It is designed to scale, with options that can be turned down for modest hardware and up for capable machines. It offers forward, Forward+ and deferred rendering paths, the Forward+ path allowing many more real time lights per object than the classic forward path's per object limit, which matters for scenes lit by numerous small sources.

HDRP aims instead at high end hardware, chiefly desktop computers and current generation consoles that support compute shaders. It is built around physically based rendering in a strict sense: lights are specified in physical units such as lux and lumens, cameras can be configured with physical exposure settings, and materials follow a physically based model throughout. It provides volumetric fog and lighting, advanced material types for skin, hair and fabric, screen space and ray traced effects on supported hardware, and a lighting model capable of photographic realism.

The two are not simply higher and lower settings of one renderer. HDRP's richer feature set brings heavier baseline costs and a more demanding workflow, since physically correct lighting requires artists to think in exposure values and real light intensities. URP's lighter architecture makes it far cheaper on modest hardware, but it does not attempt many of HDRP's advanced effects. A stylized game targeting many platforms belongs comfortably in URP; a realistic, cinematic project aimed at powerful machines is HDRP's natural territory.

Shaders and materials

The most painful consequence of choosing a pipeline is that shaders are not interchangeable. A hand written shader for the Built-in renderer will render as bright magenta, Unity's signal for an unsupported shader, when the project switches to URP or HDRP, because the scriptable pipelines expect different passes, lighting functions and data layouts. A shader written for URP will not work in HDRP, nor the reverse. Every shader in a project, including those inside third party assets, is tied to the pipeline it was written for.

Shader Graph, Unity's node based shader editor, softens this problem considerably. A graph describes a shader in terms of nodes and connections, and the pipeline generates the actual code. The same graph can target both URP and HDRP through its target settings, and since Unity 2021.2 it can target the Built-in renderer too, although pipeline specific nodes and features will not carry across. For a team that expects to keep its options open, building materials in Shader Graph is a sensible precaution.

For projects moving from Built-in to URP, Unity provides the Render Pipeline Converter, which upgrades materials using standard Built-in shaders to their URP equivalents. It handles the common cases well, but custom shaders and surface shaders still need manual work, and that work can be extensive in a mature project. The cost of a late migration is the main reason why the choice of pipeline is best made, deliberately, at the very start.

Extending the frame

Most games eventually need something the pipeline does not do out of the box: an outline around selected units, a distortion effect, a custom fog, objects drawn through walls. In URP the standard extension point is the renderer feature. By subclassing ScriptableRendererFeature and adding the result to the Universal Renderer asset, a developer can inject custom render passes at chosen moments in the frame, before or after opaque geometry, before or after transparents, or after post-processing, without modifying the pipeline itself.

HDRP offers an equivalent through Custom Passes, which are configured on a Custom Pass Volume in the scene and can draw objects with special materials, run full screen effects, or write into the pipeline's buffers at defined injection points. Both mechanisms reflect the same philosophy: the pipeline remains intact and upgradeable, while the project's peculiarities live in small, separate pieces of code attached at well defined seams.

Lighting decisions interact with these extensions in ways that are worth thinking through early. A night scene in Crown & Ashes, lit by torches and fires scattered around a palisade, is the kind of situation where the number of real time lights matters a great deal, and where rendering paths such as URP's Forward+ or deferred become relevant. Asking how many lights a typical scene will contain, and how many shadows those lights must cast, often narrows the choice of pipeline and path more than any abstract comparison of features.

Choosing a pipeline

For a new project, the decision usually begins with platforms. If the game must run on phones, on the web, or on standalone virtual reality headsets, URP is the practical choice, because HDRP does not target those platforms. If the game is aimed only at powerful desktop machines and current consoles, and its art direction calls for physically based realism, HDRP becomes a strong candidate. If the game is stylized and aimed at desktop computers, URP is often still preferable, simply because it is lighter and easier to work with.

The team matters as much as the target. HDRP rewards artists who understand physically based lighting and punishes those who do not, with scenes that appear too dark or too bright until exposure and light units are set correctly. URP's simpler model is friendlier to small teams and to developers coming from the Built-in renderer. The Asset Store matters too, since a package that supports only one pipeline can quietly make the decision for you if it is central to the project.

What should be avoided is drifting into a pipeline by default and discovering its limits only after hundreds of materials exist. The choice deserves an afternoon of prototyping: a representative scene built in the candidate pipeline, lit as the final game will be lit, and run on the weakest target hardware. That small experiment will reveal more than any comparison table, and it allows the project to begin on a road chosen with open eyes rather than one stumbled upon in the dark.