From the beginning, we developed the SRP architecture to solve several goals:
- Provide the most optimal pathways to take advantage of the fragmented hardware landscape and reach performance on those platforms
- Enable deep customizability of rendering paths in user land
- Enable content scalability across the entire platform reach of Unity
We view the Universal render pipeline as the successor to the default rendering pipeline in Unity (aka the ‘built-in pipeline’). Universal RP is designed to be the default great place for authoring graphics and deploying everywhere, allowing you to achieve beautiful visuals, great performance with maximal platform reach.
At the same time, we positioned the High Definition render pipeline as the primary rendering pipeline for the bleeding edge graphics functionality for GPU-compute-capable, high-end platforms.
We’ve been working on getting Scriptable Render Pipelines ready for production in the recent years. As part of that effort, we’ve been eagerly listening to the feedback we received from you. There has been a lot our community has shared with us - and we’re grateful for that - thank you! Our major goal is to incorporate the feedback that we got from you to improve the quality of the graphics packages and SRPs.
Some of the feedback we’ve received is already being addressed through the work we have in the pipeline - we will share more on that below. Some of the feedback, however, will take longer for us to address as we need to define a solution that addresses the concerns presented, yet has longevity through the evolution of our product and the graphics API ecosystem.
We want to do this right - and the right solutions require deeper thinking and time. We also wish to balance the needs for all of our user groups (Asset store publishers, Developers, Artists, etc.) with the changes we are making.
With that, we wanted to share some of our latest plans on what we are doing right now, and where we will be going next. While this is a somewhat lengthy post, we hope that it helps build clarity and transparency so that you know how we’re approaching this architecture for our product.
What are we going to cover in this post?
- Addressing your questions and feedback about SRP quality and stability improvements, shader API stabilization
- Sharing our plans to distribute verified Graphics and SRP functionality with the core Unity.
- Evolution of the Universal render pipeline to be the default render pipeline for Unity
- Ensuring reliable and predictable upgradability of projects from built-in to URP and HDRP
- HDRP architecture, design considerations, and extensibility approach
- How we are approaching Scriptable Render Pipeline Cross-Compatibility, including Cross-Pipeline Shader Authoring
- Helping the Community to Be Successful with SRP through best practices guides and tutorials for both pipelines
Quality And Stability
Stopping breakage between versions
One of the biggest pain points that you have shared with us is that SRP API often breaks between versions - this is a cause of upgrade anxiety and frustration for you.
The API we have in our systems is a contract that we have with you as consumers of these systems and they should be stable, clearly documented (as internal or external), and, if changed, have auto-upgraders or clearly marked changes in the upgrade notes.
The most vocal feedback has pointed to shader API changes as the major culprit of upgrade pain. To address this, we are improving the automation and tooling for shader API validation for SRP, to ensure that the functionality is not regressed between releases. This will ensure a robust and reliable upgrade path for shaders between versions of the SRP.
We already run extensive automated testing in our build system for supported platforms (Windows, OSX, Android, iOS, consoles) with a focus on functional testing for features for SRP.
The next step of getting SRP robust for productions is to extend automation validation and upgradability testing to projects and asset store packages.
We are injecting nightly tests validating on a number of user projects and asset store packages for both HDRP and URP in our automation process. These tests are intended to validate both the API stability and the data, along with the visual results. These tests are designed to catch shader API breakages as well as the core API breakages and prohibit unintentional changes from landing.
Note that the shader APIs may change as we add new features or improve iteration speed or optimize performance. We strive to make those changes be rare events and as minimal as possible. We also will make sure that they are implemented as early as possible in the product cycle, by the end of alpha. Additionally, we will guarantee that they are clearly documented; that the standard nodes in the shader graph will work for all shader API changes. Yet, there may be still a need for adjusting the custom shaders or custom shader graph nodes.
To improve our product testing coverage, we have also extended testing across the packages combinations (for example, combinations like URP + shader graph + VR) for a cohesive product perspective. This significantly increased testing coverage in the Graphics | SRP codebase. We have also added a large number of additional tests for platforms coverage, especially VR. In addition to that, the team has spent over a year of engineer-months recently addressing large swaths of bugs, buckets of low user pain issues, stability and workflow improvements for both render pipelines to increase the product quality, starting with 19.3 and throughout 2020.2.
Migrating Graphics Packages to Core Unity: One version for each version of the Editor
For productions, you want to know that you’re always working on a recommended (verified) coherent set of Graphics functionality, including SRPs - that the new versions are sync’d to Unity releases, with the packages and the Editor matching versions. You have shared with us the frustration of trying to configure your projects’ packages. It is difficult to get a correct combination of Graphics packages and Unity versions.
Our intent is to change that - to make it easy and seamless for you. With that, we want to share our current thinking - we would love to know what you think about our plans.
Our goal is to ship verified graphics packages as part of core Unity. There will no longer be versions distributed via package manager. This means that each shipped version of Unity will have Universal Render Pipeline (URP), High Definition Render Pipeline (HDRP), Shader Graph, and VFX Graph that have been validated to work well with that release. This removes the headache of figuring out the matching versions - it will just work out of the box.
Now, you may ask - how will this affect where we develop SRPs and graphics functionality? After all, you’ve shared with us how much you enjoy the full visibility of us developing it in the Graphics repo on github.
We will continue to develop in the open on GitHub with the new plan of release. The only thing that is changing is that we are now distributing verified Graphics and SRP functionality with the core Unity.
The pipelines and tools will become a core part of Unity. A big benefit of this approach is that it makes it easier to test the entire product of Unity for SRPs holistically. One version of SRP for one version of Unity. It also makes it easier for you to know what to support. A better integrated experience, with no need for dealing with package confusion; just like with core Unity.
To answer some specific questions that will come up from this:
- You will still be able to override the graphics packages with a custom fork or branch from the git repository - just like you do now
- You will be able to configure your manifest to track a branch from GitHub- allowing for getting latest bug fixes before we ship a version of Unity
We want to hear from you - what are your thoughts on this plan?
Universal Render Pipeline Plans
We view the Universal render pipeline as the successor to the default rendering pipeline in Unity (aka the ‘built-in pipeline’).
One pain point we have heard loud and clear is that URP needs functionality parity with built-in before you will transition across. We agree - in fact, that is also how we are approaching URP evolution.
The goal is to get Universal to full parity with the built-in render pipeline, and offer functionality beyond - improved visual quality, enhanced performance, more features, and rich artist tooling.
That said, the journey of getting there is in progress but hasn’t been completed. We aim to have URP reach functionality parity with built-in (i.e the things you could do in Built-in, you can do in URP) for Unity 2021. To clarify, we will ensure that we provide the same capabilities for the functionality (for example, ability to support camera stacking in URP) but they may have different characteristics in URP versus built-in (due to design considerations such as performance or usability).
Our prioritization is driven based on your feedback. We would love to better understand your priorities for feature needs, to help with our scheduling. So please let us know directly by voting on your most needed features or submitting requests for the ones that are not on our public roadmap yet here: https://portal.productboard.com/unity/1-unity-graphics. We are currently working with Ali Mohebali, our new SRP product manager, to revamp the public-facing roadmap to reflect our goals by the end of Summer 2020 in full details.
Here are some of the features we are shipping for URP in 2020.2:
- SSAO support
- Mixed lighting modes including shadow mask, distance shadow mask and more
- Deferred renderer support
- Improved material inputs (detail normal maps, height maps, parallax mapping, other)
- VR-specific post processing functionality for Hololens, Magic Leap, Windows MR (stability, quality, optimizations)
- Across the board major swaths of bug fixes for stability, quality and performance, addressing key areas for URP
Additionally, here are some of the features that we are currently working on for URP in 2021.1:
- Light cookies support
- Deferred renderer optimization for mobile platforms
- Point light shadows and other shadow improvements for URP, such as shadow distance fade, shadow cascade blending, and more
- Shader tier system for URP platform and tier scalability configurability
- Additional post processing, including per-object motion blur, auto-exposure, and motion vector support
- Virtual texturing URP support
Reaching parity for URP with built-in is one of the top priorities for the Unity graphics team and we’re fully committed to this goal.
Reliable upgrading from built-in to URP
Many of you are interested to learn more about our plans for improving the upgrade experience from built-in render pipeline to URP. This is something we’ve been focusing on deeply and will continue to resource this heavily through 2020.2 to 2021 releases. The goal is to make the upgradability from built-in for standard supported features as smooth as possible.
We are aware that we are not yet at this goal - currently the upgrade story is lacking which is not a happy place for us.
How are we planning to improve this?
-
Reaching functionality parity with built-in to ensure that all standard supported features are smoothly upgraded to URP. See the list above for our parity feature schedule. We aim to ensure that all features will be tested for upgrade as we develop and land them.
-
Upgrader feature coverage: we have just recently completed an audit of the Asset Store by running a wide set of products through the upgrader. This highlighted a number of holes in our upgrader coverage that we are now addressing. For example, we found lack of support for nested prefabs materials upgrading, we found issues with upgrading default materials that we’re working to address, and more.
-
Upgrader testing automation: We are adding automation to ensure we test upgradability for a set of representative projects nightly in our pipeline.
Please help us identify any other holes that we need to address. Note that we will do everything we can to ensure that standard features are upgradable. Still, there will be a set of custom features we currently do not have a plan for an automated upgrade, for example, upgrading existing customer shaders to a URP version will not be automatable.
High Definition Render Pipeline Plans
Universal RP is designed to be the default great place for authoring graphics and deploying everywhere. While you may have felt gaps in URP due to missing functionality, we are closing these gaps. And the intent is for you to use the Universal pipeline to achieve beautiful visuals, great performance with maximal platform reach.
At the same time, we positioned the High Definition render pipeline as the primary rendering pipeline for the bleeding edge graphics functionality for GPU-compute-capable, high-end platforms. HDRP has been designed to take advantage of more advanced GPU features, in order to deliver maximal GPU performance on these platforms (a deep dive on HDRP graphics architecture can be found in the SIGGRAPH 2018 Advances in Real-Time Rendering presentations, for those that may be curious).
Reliable upgrading from built-in to HDRP
We want to ensure you have solid pathways for upgrading your built-in projects to HDRP. Similar to URP, we offer the upgradability from built-in for standard supported features with the goal of making it as smooth as possible. At the same time, due to a fundamental design difference between the built-in pipeline and HDRP, there are elements that are not suitable for automated upgrades such as post processing and lighting. To help you with that, we provide “best practices” guides (for example, this guide).
We’re aware that there are gaps for smooth upgrade from built-to HDRP and we’re committed to improving that experience. Please help us identify any other holes that we need to address. Note that we will do everything we can to ensure that standard features are upgradable. But there will be a set of custom features we currently do not have a plan for an automated upgrade, for example, upgrading existing customer shaders to a HDRP version will not be automatable, similar as for URP.
We are working to ensure that material conversion from standard shaders will work reliably. We are also going to provide clear guidelines for how to author custom shaders or custom nodes for HDRP to help understand the important considerations (such as supporting software dynamic resolution, etc.)
A few areas that are known gaps are support for terrain functionality and Shuriken for HDRP. For terrain, we are committed to providing HDRP support in the 2021 product cycle. Regarding Shuriken, the intent for HDRP is the VFX graph, which has been designed from the get-go to optimally fit the architecture. We are committed to add support for CPU particles to the VFX graph to ensure comparable functionality.
HDRP Architecture Design and Extensibility Goals
You’ve shared some frustrations with us about experiencing constraints for extending HDRP to meet project-specific needs. The main known constraints are limited injection points, lack of ability to customize lighting, and rigid encapsulation of API behind access modifiers.
We want to share some of our thinking to help you understand how we approached the architecture design for HDRP and connect it to the choices for extensibility.
As we mentioned, HDRP is targeted to reach maximal GPU performance on current and next-gen platforms. This is still a work in progress, as we’re maturing the architecture to full-production readiness. During this architecture maturation phase, we are constraining the set of available injection points to minimize synchronization stalls and performance issues. Another important consideration we are committed to is to ensure that any functionality injected to HDRP through these custom injection points will support both forward and deferred paths.
We intend to expand this set once the architecture has reached production-readiness levels.
HDRP was designed to ensure that the pipeline provides physically-based coherent lighting where each lighting feature supports all material permutations. This is a critical element of the HDRP design, necessary to achieve highest visual quality and predictable content behavior. Examples of that are: area lights, screen-space lighting, environment lighting, that work with all material permutations. Due to this consideration, HDRP does not allow modification of lighting inside the existing materials, to avoid creating lighting response inconsistencies and breaking this core design principle.
What we have designed, though, is the ability to extend HDRP to implement custom lighting models by creating new forward materials, effectively allowing you to author entirely new BRDFs. This method ensures that these BRDFs will support all lighting types in a coherent manner. This functionality will be provided in the 2021 product cycle.
Ultimately, we are still maturing HDRP for production-readiness. We would love to hear directly from you more feedback to help clarify which API we need to expose for HDRP customization so that you can achieve your project goals.
Scriptable Render Pipeline Cross-Compatibility
Build Once, Scale to Any Supported Unity Platform
As we mentioned earlier, Universal render pipeline is designed to be the default rendering path for Unity, a replacement for the built-in render pipeline, targeting the widest reach of Unity platforms. The High Definition render pipeline is intended for projects that wish to take advantage of the bleeding-edge graphics functionality, squeezing every capability possible. Yet we aim to create a good flow between these pipelines. This has been started but we still have a lot of ground to cover. Content scaling and cross-pipeline workflows are an area where we are focusing a significant development effort going forward. We acknowledge that, at this point in time, this is not yet a great place in Unity, and we strive to do better in this domain.
What do we want to achieve for cross-pipeline compatibility and content scalability for SRP graphics?
We want to allow URP and HDRP pipelines to live in the same project. You will be able to have pipeline-specific assets such as Materials, Cameras, or Lights in different scenes while successfully building and running a project for a single pipeline. ShaderGraph shaders, for example, ensure that common cross-pipeline features across both pipelines will guarantee to work, while still allowing you to benefit from the per-pipeline functionality if desired. The first stage of this will be rolled out in 2021.1 where you will be able to target both render pipelines from a single Shader Graph.
A well-documented public shader API. During the 2021 product lifecycle, we will separate SRP / Platform implementations into public and private header files so that it is clear what is safe to use and is on the golden path. This will include documentation of the public API points so that it is clear how to use each function and what limitations they have.
Improvements to asset cross compatibility - We want to solve “I change pipelines and things still work.” You can author assets that rely on common cross-pipeline features, and have them work in multiple pipelines. We will have a “Best practices” guide for the set of common cross-pipeline properties that will be guaranteed to work. We will also provide clearly documented pipeline-specific functionality. You will be able to author one asset in the same project, that can target the pipeline-specific functionality, and still have it work. Materials, Lights, Camera, etc. This will be a combination of code and asset improvements as well as a ‘Best practices’ guide in the manual for developing cross pipeline content. This is also planned for the 2021 product life cycle.
Shared asset and API interface for both render pipelines: API and asset improvements to allow features and assets that have alike purposes in both pipelines to have a common interface so as a user you can talk with systems the same way in both pipelines.
We want to be transparent - bringing the two render pipelines into harmony will not be an overnight effort for us and it will take time for us to do this right. We are planning to roll this out in a few phases so that we can start to bring improvements to you as soon as possible, then start iterating on further improvements.
Cross-Pipeline Shader Authoring
With Scriptable Render Pipelines, our goal is to create a cohesive product where content will flow smoothly from one render pipeline to another, in addition to smooth upgradability from built-in, as we mentioned. One large area needing attention for this goal is how we handle shaders and materials. What we want to provide are these elements:
- We want to author shaders once and target both pipelines.
- We want materials to work consistently across both pipelines.
- We want standard shaders that have been written for SRPs to continue to upgrade smoothly.
- We want all standard built-in shaders to upgrade smoothly to either render pipeline.
- We want asset store products to be able to target both SRPs with the same set of assets.
- We want SRP shaders and shader graph assets to be viewed as reliable and have clear documentation.
- We want great authoring experience for non-technical artists through materials and for technical artists through the ShaderGraph.
We acknowledge that not all of the above goals are yet reached. That said, we are focusing strongly on achieving them starting with 2021, with the specific goals of creating a great experience in Unity for materials and shaders.
Note that there are some goals that we currently believe are not easily achievable, namely the automated upgrade of custom shaders to either SRP from built-in. The reason for that is with the built-in renderer shader library there is not a level of abstraction that allows us to rewrite the backend for. That is: it is not possible to automate the translation of intent and correctly translate components and inputs to the new SRP shader API. Even with existing surface shaders there are extensive assumptions that they will execute on the built-in pipeline - They are designed specifically for built-in.
As of recently, you noted that SRP shaders evolved far too much between SRP releases and this lacked upgradability. We have stabilized the shader API and are adding thorough testing - see the note above on “automated upgraded testing for shaders”. Starting with 2020.2, the introduction of shader stacks functionality will help stabilize the shader graph versions and allow easier configurability across multiple pipelines to target both SRPs in one shader graph, with the goal of full stabilization in the 2021 product cycle. In 2021, we are also providing functionality parity for upgraded standard shaders to SRP.
Shader Abstraction and Materials
You have also let us know that rewriting shaders from the ground up for each pipeline is not an acceptable approach. You’ve mentioned that there is no upgrade path from Standard to an SRP, and shaders written for one SRP (URP) won’t work for another (HDRP). You are right that this is a gap. We agree - and, in fact, we want you to know that we’ve dedicated a significant amount of hours discussing possible solutions to this problem. We want to share some of our thinking to help align us on the same page.
For the last few years our big push in Graphics has been about improving artist tooling and workflows. This has come in the form of Shader Graph, VFX Graph, improved editor tooling for graphics and better workflows that focus on content creators. The reason we put so much effort into this space is because this was a known gap for Unity, and we listened to the feedback of many developers that were frustrated with this lack of functionality in the product.
While a lot of work has been done, we are still in the middle of this journey, to deliver awesome feeling artist tooling for shaders and VFX authoring. There is still a fair amount of work remaining to ensure that we have great UX and feature set for both tools, as well as material handling - the latter necessary for non-technical artists.
On the other hand, this has meant that shader programming workflows have not been the main focus of our work. It doesn’t mean that we think these workflows are not important but we had to make choices, and these were the choices we selected.
Right now we are in the planning phase of addressing the following problems:
- Modernization of materials in Unity, including updating the material abstraction in Unity
- Cross-pipeline shader abstraction for programmer workflows (in the spirit of surface shaders)
We believe that providing the functionality above is crucial to make our ecosystem of asset store and custom render path development successful. A solid and flexible shader abstraction is key to enable this ecosystem. We are incorporating the feedback we gathered from you directly and from the previous forum threads (like this) right now and intend to share our design plans by the end of summer 2020. We are committed to solving this by the 2021 product cycle.
In order to design a robust solution with longevity for our product, we need to keep a number of important considerations in mind, such as ensuring that it is extensible for advanced shader types (such as ray tracing, compute, mesh shaders), new shader functionality (such as VRS) and be well suited for future evolutions of shader and graphics API.
Helping the Community to Be Successful with SRP
Many of you shared the frustration of not having good guidance on how to get great results with URP or HDRP due to the lack of best practices guides or coherent tutorials. Without a doubt, this is needed in order to make you be successful with SRP.
We believe this is important and we will be providing far more materials to help guide you to success in the form of blogs, samples and tutorials. There are resources available already, for example, Achieving High Fidelity Graphics with HDRP tutorial or Evolving game graphics with URP tutorial, and more in the Unite Now playlist. We are also working on new content to share with you in the near future. One of the elements we’re going to address is providing you with more real-world example tutorials with complex content and best practices guides rather than just basic functionality overview. We are also committed to improving the quality, coverage, and usability of our documentation.
In closing
We hope this allows you to get a better understanding of how we are approaching developing SRP and getting them production-ready. Our journey is very much still in progress, and we want you to know we truly value your feedback and we are carefully listening. Our success is in your success - only when you are happy to adopt it, we know that we have achieved a great result. And we won’t rest until we do!
Yours truly,
Natasha Tatarchuk
Tim Cooper
Sebastien Lagarde
Felipe Lira
Ali Mohebali