Getting Started with Unity’s Lightweight Render Pipeline (LWRP)

We’re excited to announce that Unity’s Lightweight Render Pipeline (LWRP) is ready for developers to try out in their Oculus apps, namely with the Oculus Quest! In this article we’ll provide an overview of this framework, share a few best practices, and cover key techniques to keep in mind when using the Lightweight Render Pipeline.

The LWRP is a part of Unity’s broader Scriptable Render Pipeline (SRP). The SRP allows developers to customize specific details of their render pipeline, using C# scripts. Many of these details, like the ordering and properties for opaque and transparent render passes, were previously either hidden entirely or exposed via a simple checkbox. Using the SRP, C# code can be used to fine-tune details however you see fit.

The LWRP happens to be a specific example of a render pipeline built using the SRP. It’s built from the ground-up to use rendering techniques that perform well on a wide range of hardware, especially standalone headsets like the Oculus Quest.

The LWRP is a match for developers at all levels of the graphics expertise spectrum. For less experienced developers who don’t see the need for this added flexibility, they can simply use the LWRP with no modifications, and it will suit their needs out of the box. For advanced graphics developers who want to take advantage of the sheer level of customization, they are encouraged to download the LWRP package source code, modify it to their heart’s content, and use in their projects.

We provide a comprehensive overview of the upgrade process in our Unity build documentation for PC and Unity documentation for Android. The quick gist is that if you’re only using Unity built-in shaders, you will likely be able to upgrade to LWRP shaders with ease. The LWRP has a consolidated set of shaders that every built-in shader is associated with. On the other hand, if you’re using custom shaders, you’ll likely have to rewrite them to use with the LWRP.

The LWRP uses a single-pass, forward renderer, in which lights are shaded in a single pass. For Oculus devices, this also entails that each eye is rendered through one shared draw call, which significantly cuts down on CPU cost compared to multi-pass.

After upgrading to the LWRP, provided that your settings are identical to those of your previous built-in RP project, your performance should be about the same as before. In some of our test cases, we’ve even seen an improvement in performance from using the LWRP. If performance is less with the same settings, this is a regression that must be fixed, so file a bug using Unity’s bug reporting tool.

While the LWRP provides a new level of flexibility and customization to your VR development workflow, it also means that there are more ways to go wrong, especially with performance.

When using the LWRP with the Oculus Quest, rendering to intermediate textures uses a very high amount of GPU resources. Keep in mind that intermediate textures are required when using Unity’s post processing stack. For this reason, we caution developers from using the LWRP’s post processing features when developing for the Oculus Quest, unless they verify that they can still attain adequate performance using any given feature. Most developers will not be able to hit frame rate when using a dedicated post-processing pass in their Quest apps.

An easy way to verify that you’re taking the most performant route is to take a Renderdoc capture of your app. The “Render Opaques”, “Render Transparents”, and other associated passes should all have an output of our Oculus runtime-allocated swapchain texture, which is shown in the below images from a Renderdoc capture:

This RTDeviceEyeTextureArray0 is our swapchain texture, and this example illustrates optimal performance, as it signifies that rendering is being performed directly to our swapchain texture, without the use of intermediate textures. As stated earlier, these intermediate textures are extremely costly from a GPU resource standpoint. If an app instead renders to an intermediate texture, and then performs a blit pass from that intermediate to our final swapchain texture, the app is not taking the most performant route. One of the first steps to debugging performance issues with the LWRP should be verifying that such a blit pass is not present.

See below for an example screenshot featuring a number of these best practices, including HDR turned off and 4x MSAA.

Caution: Unity’s default LWRP template currently contains settings that will force the use of intermediate textures and reduce performance greatly as a result. Examples of techniques that could do so are: camera HDR, post-processing, a motion vector pass, and more. If you use this sample, you’ll have to make the appropriate modifications to turn these features off, if you want to hit adequate performance on the Oculus Quest. Using Renderdoc is a great way to verify that you’re not using these intermediates.

Currently, the aforementioned intermediate textures are unfortunately used when selecting the linear color space, or modifying the eye texture resolution scale. These bugs are being addressed and will be fixed very soon, in a newer Unity Engine and LWRP version.

In Unity 2019.3 onwards, the LWRP has a new name: Universal Render Pipeline(URP). The API is unchanged along this transition, so if you’re on 2019.3, onwards, simply use the URP. Everything in this post about the LWRP will apply to the URP as well.

If you’re a visual learner, check out the following OC6 presentation which features an overview of the LWRP and more best practices:

Ultimately, Unity’s Scriptable Render Pipeline comes with a lot of benefits to developers at all skill and experience levels. Its extensibility can prove extremely helpful when trying to gain more lower level access to an app’s render pipeline. And on the other end of the spectrum, the Lightweight Render Pipeline can also be used without modifications, as is, and it works performantly out-of-the-box in such cases. We look forward to seeing what you all produce with the LWRP going forward!