Learn how to leverage High Definition Render Pipeline (HDRP) settings to maximize performance and achieve powerful graphics all at once.
With the release of HDRP version 10 for Unity 2020 LTS and beyond, the HDRP package has continued to prioritize its user-friendly interface, flexible features, stability, and overarching performance. But to set HDRP up for optimal use, it’s crucial to understand all of the main settings, how they work, and what they do. That’s why we’re looking at how HDRP operates from the perspective of CPU/GPU Profiler captures, the Render Pipeline Debug view, and HDRP’s shader framework.
From graphics debugging to profiling and optimization, this blog unpacks tips to help you customize HDRP for your project using the Custom Pass API, or another local part of the package.
Before we start analyzing frames, it’s important to get to know the HDRP features at hand. We recommend watching our Unite Now presentation, Achieving high-fidelity graphics for games with HDRP, the Ray tracing with Unity’s High Definition Render Pipeline webinar, and the Volumetric Clouds, Lens Flare, and Light Anchor talk, which are all great guides to HDRP.
Users moving from the Built-in Render Pipeline to HDRP often find that the migration takes some adjustment time. This is because:
To get familiar with these HDRP capabilities, we’ll begin by looking at its Global settings.
For the Built-in Render Pipeline, the Graphics settings cover most per-project graphics settings. There are also Player settings, which contain some general graphics settings under the context of a particular target platform, such as Windows, Linux, Mac, or Xbox.
HDRP projects similarly use Graphics and Player settings, with the addition of three more sets of settings that provide access to advanced default configurations of the render pipeline.
With the Built-in Render Pipeline, you can define a number of quality levels in the Quality Settings tab. For each quality level, some graphics settings, such as anisotropic texture usage, can be specified so that less hardware resources are used on low-end platforms.
For HDRP projects, specifically, an override HD Render Pipeline Asset can be selected for each quality level. This offers more configurability compared to the Built-in Render Pipeline, since the HD Render Pipeline Asset stores several parameters, such as maximum number of directional, punctual, and area lights onscreen, the color-grading LUT size, and the light cookie atlas size, among others.
Some properties in the Quality Settings tab for a Built-in Render Pipeline project only apply to the Built-in Render Pipeline. In an HDRP project, these settings might disappear from their original locations and reappear elsewhere as “replacement settings.”
In a Built-in Render Pipeline project, for instance, the Quality Settings tab controls the Shadow Resolution property. In an HDRP project, however, the Lighting > Shadows section of a HD Render Pipeline Asset controls the resolution of shadow maps.
To render your scene in HDRP, you need to add Cameras just like in the Built-in Render Pipeline. HDRP also makes use of an extra HD Additional Camera Data component (attached to the same Game Object), to store extra per-camera parameters.
Indeed, HDRP offers many more per-camera parameters for customization. There are several Physical Camera settings, and if you tick the Custom Frame Settings property of a camera, you can decide how the camera draws the frame through the Frame Settings system.
The Frame Settings system is a stack of camera property overrides. You can specify default values for Frame settings in the HDRP Default Settings tab. On top of that, each camera can override the default Frame settings.
The Camera panels of the Render Pipeline Debug window help visualize the Frame Settings override stack.
The following example demonstrates how the Camera panel of the Render Pipeline Debug window works:
There is a camera called Main Camera in the Scene. Main Camera only draws static objects. The HDRP Default Settings tab enables drawing motion vectors, whereas the Frame Settings override from Main Camera disables this function to improve overall performance.
The Motion Vectors override stack displays the state of the Overridden Frame settings on the left of the Default Frame settings. See Figure 4, Highlight A:
Additionally, the Render Pipeline Debug window shows the state of the Sanitized Frame settings on the left of the Overridden Frame settings. Sanitization ensures that the Overridden Frame settings stay consistent. Looking at the same example, Opaque Object Motion and Transparent Object Motion have not been explicitly disabled in the Main Camera’s Frame Settings override. But since Motion Vector is disabled, these dependent features are also turned off by the sanitization system, as shown in Figure 4, Highlight B.
As discussed in our Unite Now talk, HDRP supports a Volume system. Similar to the Post-processing stack in the Built-in Render Pipeline, the HDRP Volume system controls post-processing. Even more, however, it determines the way the sky is rendered, the strength of indirect light, and some shadow settings, among other features.
Simply put, the HDRP Volume system is an abstract framework that can be used to alter rendering settings as the Camera moves across the Scene. There is a hard-coded Default Value for each Volume property. To see these values, use the Volume panel in the Render Pipeline Debug window. See the rightmost column in Figure 5, where the Default Intensity of Lens Distortion is 0.
These hard-coded default properties can be overridden by property overrides in the Volume Components section of the HDRP Default Settings tab. Note that these property overrides can similarly be overridden by Volumes in the Scene.
Conversely, the Camera picks up a blend of property values from Volumes in the Scene. If there are none, it then picks up property values from the HDRP Default Settings tab. Otherwise, it picks up the hard-coded default property values.
As shown in Figure 5, the Volume panel of the Render Pipeline Debug window is useful for visualizing the current Volume property override stack. It’s particularly effective when debugging, as it displays the Volume properties currently in use.
Just like in the Built-in Render Pipeline, geometries to be rendered are usually specified by Mesh Renderers or Skinned Mesh Renderers in the Scene. HDRP-specific data is predominantly stored in the Materials so that they can use the appropriate Renderers or Shader Graphs.
Like in the Built-in Render Pipeline, HDRP projects have Lights with data storage specific to HDRP for each light. The HD Additional Light Data components are attached alongside the regular Light components.
Consider that there are many settings for lighting that derive from places other than Game Objects with Light components. Here are just a few examples:
Now that we’ve taken a tour of the HDRP UX, let’s turn to some less familiar graphic properties for your next HDRP project. Figure 7 illustrates a possible approach, starting with general settings at the top and override settings at the bottom. As you can see, the scope widens as we go from top to bottom.
HDRP’s Graphics settings must adapt to the following:
Note that HDRP settings are particularly attune to the settings’ dimensions.
There are often conflicts between the following settings’ dimensions:
To address these conflicts, the HD Render Pipeline Asset supports tiered settings. Instead of indicating just one value for a property, a number of values can be attributed to a number of tiers – Low, Medium, High, and in some cases, an Ultra tier.
For cameras that render the picture-in-picture effect, you can specify a tier for both the volumes that control the post-processing effects and the spotlights that request the shadow maps:
HDRP can then look up the property from the appropriate tier in the active HD Render Pipeline Asset. It’s this property that will be used.
Of course, it’s also possible for cameras, volumes, and lights to ignore the tiered settings system, and directly determine their desired behaviors.
Let’s look at another example where the settings’ dimensions overlap.
Imagine that there are some Mesh Renderers in the Scene using a Shader Graph with complex vertex animations. It might be too expensive to perform vertex animation on low-end devices. There’s also extra camera rendering to consider for the Render Texture when it comes to picture-in-picture effects, so you don’t need that extra camera to render with any vertex animation.
In this case, there are three settings’ dimensions overlapping:
To address cases like this, there is a special Material Quality keyword available in Shader Graph:
Unlike regular Shader Graph keywords that are controlled by users per Material, this is a global keyword, set up internally by HDRP. In the HD Render Pipeline Asset, you can control the Material Quality Levels available, as well as the default Material Quality Level.
For each camera, you can override the default Frame settings and specify a Material Quality Level, overriding the active HD Render Pipeline Asset.
The HDRP has a systematic approach to handling settings from artists. After all, maintaining a great UX for artists is the key to inspiring high-quality content.
When starting an HDRP project with a simple setup, the project might cost a surprising amount of performance. This is because HDRP determines many of the used features by default. Best practice is to control the HDRP settings so you only pay for what you intend to use.
To represent a minimalistic rendering workload, let’s create a scene of 225 cubes using the default material, illuminated by a spotlight, a point light, a directional light, and ambient lighting.
How does this simple setup perform? Let’s build a standalone player with a resolution of 2880x1620, on the IL2CPP scripting backend, with VSync turned off. Running the player on a Windows machine with Intel i9-10980HK GPU and NVIDIA RTX2080 GPU, the Profiler shows that the mean frame time is 4.6 ms.
Looking at the Timeline view of the Profiler, a significant amount of time is spent on the DXGI.WaitOnSwapChain marker, indicating that it is GPU bound.
Taking a GPU capture using Nsight Graphics shows that this occurs because the HDRP has several features active by default:
As you can see here, you can control the HDRP Asset, override the Camera’s Frame settings, and add Volume overrides, so that only the absolute minimum features are enabled. In other words:
After the modification, the result has a mean frame time of just 2.45 ms, which is significant compared to rendering the same scene in a Built-in Render Pipeline.
In practice, you do not need to turn off so many features in an actual game for the Main Camera, although some extra cameras do require this treatment.
If you’re interested in even cheaper cameras, the HDRP UI Camera Stacking package in 2021.2 allows you to stack multiple camera rendering UI at only a fraction of the cost of a standard camera.
This example not only highlights the extent of control you have over HDRP’s performance characteristics, but the importance of tuning your HDRP project’s setup.
The HDRP in Unity 2020 LTS brings you improved tools for creating evocative, high-end lighting in your games. Get this new, in-depth guide, to learn how to harness the power of physically based lighting in HDRP.