What is next for us at Unity with Scriptable Render Pipelines

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

71 Likes

The idea of a ‘core’ Unity that just works with the specific URP/HDRP seems like a basically good plan. However, thinking of how I tend to work in projects, there is a potential problem. Will it be possible to change a project from one SRP to another without breaking everything?

For example, developing an AR project with AR Foundation, the latest versions of AR Foundation usually include desirable new features, like cross-platform image tracking or face tracking. Many time, when I upgrade to a newer version of AR Foundation, something breaks if I’m trying to use URP. I would imagine that happening with a ‘core’ Unity as well, and thus I’m likely to override the core version using the manifest.

In that scenario, it’s pretty much the same as it is now, trying to match various packages and versions to get the ‘right’ combination. Right now, once I’ve upgraded to a new version of Unity or a new URP, many things get broken and so it’s a scary thing to make switches. If we could reliable switch between versions of render pipelines, that might it a little less scary to try out a new feature.

1 Like

Thank you for sharing the plans, it solved a lot of confusion. But I still have one particular issue, that bugged me the most and it wasn’t mentioned in the post at all: GrabPass.

You’ve mentioned multiple times, that you’re aiming for functionality parity with built-in for URP, but will it have anything to replace GrabPass? I mean not the current solution, where we can inject a custom pass via static config asset, but a dynamic way to store the frame content in a texture and use it in the next shader pass.

11 Likes

I feel like shipping SRP with core will lead to having me switch Unity versions to pickup bug fixes. I think shipping SRP as core is more frightening, for me at least. How will this work with everything else being a package, we have more that just SRP to balance when it comes to packages and unity versions.

2 Likes

They said in the post that you’ll still be able to override SRP with different versions.

I guess I assumed they will roll bug fixes into core and validate them. If im required to override SRP constantly then Im back to where I started if not worst off depending on the complexity of overriding the SRP.

1 Like

Overall this is a great post, however, it remains to be seen how Unity will execute on these promises. I think a lot of people have lost faith in Unity delivering because it always seems like things will be fixed next year.

With that said, it seems like Unity is trying to deliver performance while trying to prevent users from shooting themselves in the foot. That sounds good on paper but it seems like their strategy to achieve this is to limit customizability (see the part about custom lighting in HDRP). I think this will just lead to more complaints and another post like this one next year with fixes promised in 2022.

Just let us mess things up if we want. Sometimes people need to take shortcuts and pick the easier but less performant option in order to ship their games. Or they just aren’t as experienced and just want to get something working. Or their use-case is unique and they need to make a tradeoff to achieve their vision.

26 Likes

I have to side with unity on this one. They’re trying to provide a starting point for many different use cases HDRP is the laser-focused approach for those looking for a very concrete set of features and aesthetic.

URP is the one made of plasticine, meant to be tweaked and adapted to a variety of scenarios without breaking.

And yet we constantly see people asking each one to be the other. We want HDRP to be as flexible as URP and URP to provide high end features out of the box.

If HDRP is founded on the premise of physically correct lighting, I think it’s fair not to ask for something that goes against this.

8 Likes

Thanks for the long and detailed post and best wishes for the task ahead.

In that case there seems to be a major gap. What if I want a system built on gpu-compute but I also want a custom stylized look?

4 Likes

For general use - if you update Unity you will get patches and fixes, no need to worry about updating packages manually, just like any core Unity feature. But if you are an advanced user or have an advanced use case then there are pathways that allow that that are no worse than now.

The flow here will be from the repository into core. So bug fixes will exist publicly before they are available in core. If you want to lock in to a specific SRP version you can force your manifest to use as specific SHA from git (same as now). And if you want to lock into a specific Unity version you can have your manifest track a specific branch from the repository but keep your unity the same (also same as now).

For URP and HDRP we have ways to sample either a created color texture, or inject an additional pass for capturing more textures at specific points. What specifically do you think is lacking with this approach so I can better understand your worry.

3 Likes

Hey everyone, I just wanted to drop a line and introduce myself. As it was mentioned earlier in the thread, I am the Technical Product Manager focusing on SRP. I collaborate with Arisa ( @quixotic ), the other Product Manager on graphics team and we are more than happy to collect your feedback here.

Just wanted to reiterate that we, the Graphics team at Unity, really do appreciate your feedback. Your feedback has been and will be a great resource for us in this journey and helps us shape SRP experience in a way that addresses your needs in the best way possible.

Just as a side note, best way to vote for your priorities and submit requests for features is through our public roadmap here: https://portal.productboard.com/unity/1-unity-graphics.
We actively look at and organise your feedbacks coming through the board. We are working on adding more details to our boards to provide more clarity and visibility to our roadmaps. We will also be adding a dedicated board for HDRP, so watch the space for that.

13 Likes

It’s a huge post, which is great - must have taken a lot of work to put together, and I’m hugely relieved to read most of it. It says many great things - and it was urgently, desperately, needed

(my only complaint is: why wasn’t this post written 2 or 3 years ago [rhetorical question :)]? Many of the items in there should have been requirements from the start, including the stable APIs, the inclusion in nightly testing, URP-at-parity-with-legacy, etc).

As someone who cancelled a render-heavy project specifically because of the nightmare hellscape that is SRP today, this post answers almost all the issues I had (and certainly: answers enough of them that in future I’d consider it possible/feasible to start developing graphics-heavy content in Unity again. There are some things I wish were better, but I can suck them down - what’s here is more than enough to make it viable).

As feedback, highlighting the major items I’m personally affected by:

  • “SRP API often breaks between versions” this has been a deal-breaker for doing any serious work with SRPs.

  • “…VR…” – I do a lot of VR work, and spend a lot of time on the XR forums here. I don’t use SRP on any VR projects, it’s too much extra pain to maintain, but almost everyone is desperate to do it, to squeeze out even small performance wins - most games don’t care about 10% frame-rate, but on VR that can be life-changing.

  • “ship verified packages as part of Unity” – it’s unfortunate but an absolute necessity as far as I can see: the current situation has been killing Asset authors, and without an asset ecosystem then most of Unity dies as a pro platform for game development.

  • “URP needs functionality parity” – if you had done this one thing (made it your v1.0 goal from the start) then I think 90%+ of the major problems with SRP would never have happened. Without functional parity the recurring negative experience of devs is “upgrade to URP … now your entire project is broken and you have no idea why. Do you have the time and manpower to re-verify EVERY line of graphics code everywhere (in both shaders and C#)? … is it even possible, or will you discover that you just wasted months, only to find that some of the features you needed no longer exist? … what happens with all the Assets you bought - are you going to demand their authors do the impossible? Who’s going to pay for that?”

Some thing I think you’ve not achieved enough in the post (which isn’t a criticism, it’s merely to say: I think this is proving very difficult):

  • “HDRP Architecture Design” – I get it, and this confirms what I’ve always understood/believed. But most people do not understand what you’ve written, as you even point out. e.g in the VR forums it’s common for people to ask why HDRP doesn’t scale from nothing up to full graphics? Most developers just don’t understand the point of HDRP and it’s (deliberate) limitations. I get it, but I think you’ve got some tough challenge ahead, even here in this thread, to find ways of better explaining it to those who don’t - and making sure that Unity staff stop writing thigns on the blog, saying thigns in public, etc that undermind that understanding.

And the one strange big that seems to have been glossed over (going to re-read the post now just to check) that leaves me worried we’ll stop using Unity beyond 2020:

  • Shaders. What about shaders? The most important thing to happen to the games industry in the last 30 years: hardware-independent programming languages for programmable pipelines. And they seem to have been glossed over. It is insane to imagine a future where studios aren’t writing shader code. It’s the opposite of what we need. Graph programming languages have never, ever, worked at scale (I’ve been following it since 1998, when we were promised that graph-programming was the future, and we had very expensive IDE’s that did it). ShaderGraph is an awesome toy, a beautiful thing for prototyping ideas, and fantastic for reducing manpower costs at studios by a percentage. It’s in no way a replacement for being able to write shader code as code.
19 Likes

The main aspect that still concerns me is the push to having two separate pipelines. I can kind of understand where it came from back when SRP were conceived years ago, but looking towards the future I’m just not sure how well it is going to pan out.

Mobile devices are constantly improving and to me it looks like Apple are leading the way towards moving away from traditional pc/laptops and embracing mobile tech for everything, pushing the performance they can achieve. What couldn’t be achieved in the mobile space last year, will become a reality a year or two down the line.

With this in mind having two pipelines instead of an extendable single pipeline seems like a folly. I can’t say for certain as I’ve not dived into the internals of URP/HDRP to see just how big a difference the architecture needs to be to make use of cutting edge technology. I just find it strange to throw away what was one of the greatest strengths of the legacy renderer in which you could so easily mold it ( even at runtime ) to fit the performance of the target platform.

One might argue that the legacy renderers ability to do this was hindered by being non-optimal, but when I look at my client projects and the majority of products using Unity I rarely find cutting edge performance to outweigh ease and scalability of development.

Yet it is exactly this ability that has been lost with the two pipeline approach. Being able to switch pipelines does not replace it as it would mean a developer having to likely maintain two different versions of a single project, each using a different RP, unless switching is so automatic and efficient that it can be done at build time between different platforms?

Perhaps if URP and HDRP had feature parity I wouldn’t be so bothered as then the cause of the different architectures is tied with the main difference, that of performance. If that were the case then I’d be happy to start all my projects in URP if that was extensible like the old legacy one was and as feature rich as HDRP, whilst knowing that I could switch to HDRP for maximum performance and power, but less extendable.

10 Likes

Ah, yes. Shaders are glossed over. What you’ve offered is:

“intend to share our design plans by the end of summer 2020”

Based on the lack of positive confirmation, a cynical/fearful reader might assume that shaders (not pretty graphs, I mean real shaders) are being killed. I can’t believe that’s the intent, I can’t imagine how anything would continue to exist without real shaders, so I’d love something more concrete signalling what the range of your expected changes is here?

7 Likes

I’ve got a tab in my browser of this page open ever since I first came across a link to it. Its really useful for tracking what progress Unity are making and getting an understanding of the state of UDP. Looking at it now I thought maybe I should vote for some features, only to remember that I’m pretty sure I already had.

So I tried to find a way to look at the votes and comments ( e.g. on Blob Shadows ) as I was sure I wrote up quite a bit on why that , or more precisely projectors ) were important to me. Alas there appears to be no way to view your or anyone else’s comments on a feature. So now I have no idea if I voted for a feature or commented on it.

Is this something that can be addressed?

2 Likes

Grab pass allowed sampling not only at specific point, but at any time via a shader pass.

Imagine a case, where we need to implement something like a blend mode effect for a layer in Photoshop. The layer in our case is a game object in Unity. If it’s only one such object, it’s fine: we can store screen content at after-transparent point with URP/HDRP to a texture and draw our object using that texture to blend the colors. Now imagine we have multiple such objects stacked on each other, that should blend not only with the after-transparent grab texture, but with each other as well. We need to grab screen content after each such object is rendered. That was very simple with GrabPass, but impossible with URP or HDRP, as we can’t dynamically insert custom passes at runtime.

There is a plugin I’m distributing on the Asset Store, which allows to use that kind of layer blending effect in Unity and it can’t be implemented with URP or HDRP at the moment.

7 Likes

Concerning Shader Graph and upgrades

I’ve been immensely disappointed and puzzled that Shader Graph cannot be used with legacy renderer. While I can understand to a degree that it might be complex to automatically upgrade an existing legacy or standard shader to a SRP, I do not understand the difficulty or resistance to having the Shader Graph produce legacy version shaders.

From my point of view if Shader Graph could output to shaders for legacy renderer then i’d be using, experimenting and learning Shader Graph now, today. The obvious benefit of this is come the time when I need to switch to UDP or HDRP i’ll already have built a collection of useful graphs that can immediately be used. This would greatly ease the transition to using the new SRP and i’d be up and running much quicker.

As it stands every time I think of switching i’m faced with the fact that I’ve got a library of several dozen tweaked legacy shaders for projects that i’d have to port first before doing anything else. This increases my resistance to moving over to the new pipelines.

15 Likes

+100 this. It would be a very good way to increase adoption of shadergraph - and to reveal the problems with it.

5 Likes

Any news about shaderlab replacement? x.com

1 Like