Up until recently, I was using the “RenderPipeline” = “UniversalRenderPipeline” tag for my URP shaders. They worked fine both in editor and builds. Just updated Unity/URP, all my shaders worked fine in the editor but simply stopped working in builds.
Found out that the tag is now supposed to be “UniversalPipeline”. Made this change and the shaders now work, what-the-heck.
I have two questions:
Why does this only have any effect on builds, but not in editor. I’d say this is a bug?
Why on earth would anyone think introducing a cosmetic, absolutely unnecessary change that breaks compatibility with literally all existing hand-written shaders is a good idea? Wasted more than two days worth of work debugging trough this, thinking shader variants were being stripped from the build or shaders just not being included. Would have spent more if not for this tweet: x.com
Don’t get me wrong, I’m fine with investing time learning new APIs/tools/frameworks/etc. But this kind of casual “let’s just silently and purposefully break all existing user code for no reason at all lol” annoys me to no end. Been this way since SRP’s early days and doesn’t seem to have gotten any better, this simply has no place in what’s supposed to be production-ready software.
We are facing a similar problem, while we are using a custom SRP, the RenderPipeline tag just stops working after upgrading from Unity 2021 to 2022. Accurately, it works fine in Editor but not on builds (iOS and Android).
We used to using “RenderPipeline” = “CustomRP” and “RenderPipeline” = “” to switch between the custom SRP and the built-in RP, for now we need to fully remove the built-in RP support, which we tried to avoid. Even “RenderPipeline” = “UniversalPipeline” didn’t work, while, since we are not using URP, it’s kind of convincing.
But same question, why does this only have any effect on builds, but not in editor…?
I have also run into this issue. I have some post processing shaders for a plugin I maintain, which was working at least as far back as 2022.2.1f1 and now fails to compile the post processing shader, in builds only, for 2022.3.7f1.
This is an active asset on the store and I provide support as far back as 2021 LTS. Given this change, how can I provide the shaders in a way that is compatible with previous and future versions of Unity? To my knowledge it is not possible use shader preprocessor directives outside of the hlsl block, so it is not possible to provide different tags for different versions. As far as I can see, this apparently minor bug effectively breaks all backwards compatibility for shaders in builds between 2022.3.7 and versions beforehand. Are there any workarounds?
(Contrary to what Unity states in the publishing guidelines, UPM does not provide a functioning way to serve packages that are different versions to different versions of the engine, and this would not be workable anyway as people will eventually want to upgrade their engine version. The errors with UPM have been reported years before and they are not going to be fixed)
That’s the fun part: you can’t, at least not as far as I’m able to tell. You have to provide separate shaders for each version, each with the appropriate tag. At least that’s the solution I’ve settled on.
So in addition to having 3 different render pipelines, one of them is split into 2 mutually incompatible versions as far as shaders go. How nice!
Ok, at least for URP it’s not so bad. Via the shader discord, Cyan told me that the tag was always UniversalPipeline, it’s just that a bug in previous versions would incorrectly also render UniversalRenderPipeline. That bug is detailed here - the renderer was ignoring filtering via the draw tag Opaque forward render pass renders shaders that are defined as incompatible w/URP
So for URP, you can have compatibility with both future and past versions - you need to change UniversalRenderPipeline to UniversalPipeline and it will work with both old and new versions (I tested on 2021). The tag value didn’t change, it just was not respected beforehand.
If you don’t want to specify a render pipeline the shader is compatible with, can you not just leave the tag undefined? I noticed my CopyDepth shaders skip the tags block entirely, and they work on URP fine for me.
That’s assuming your shader is actually compatible with all pipelines. Simple shaders that don’t deal with lighting or any pipeline-specific stuff will often be.
If you want to eg. implement a parallax-offset mapping shader, you have to write 3 separate shaders, each with the correct tag.
Yeah, so there’s a bug that causes Unity ⪅2022.3 to ignore the RenderPipeline tag, and an error in the manual that instructs you to use the wrong RenderPipeline tags.
I honestly wish that whoever is responsible for this accidentally steps on a lego brick.
So… Unity guys, can you please address the code and/or the documentation? I also stumbled on this one, and yeah, once you figured out that the issue is the wrong tag name it is easy to search and find this thread.
Buuut… when you are working on a pink shader that is player-only, with zero error messages and that follows the docs you’ll look in a lot of places (was the shader included, does it compile in the platform, is it stripped, am I passing bad data from a non-editor define??, the list goes on), as @CDF said, wasting time.
(it was much more than a day for my team until we finally finally decided reconstructing the shader step by step until we hit the tag)
