Official Block Shaders: Surface Shaders for SRPs and more (Public Demo Now Available!)

This looks DEFINITIVELY EXCITING!
Will this be a core feature only available on future Unity versions or will this be compatible with current Unity 2021 LTS ?

 

Long awaited, very much necessary! Maybe a silly question, but there's no compatibility / interoperability with built-in RP? Just wanting to know if we'll be still 2+ years either stuck at legacy built-in or tied to Better Shaders (the Asset Store package)...

 

At the very least, you can have Shadergraph shaders target BiRP alongside the others now.
It does seem strange to me adding support for BiRP wouldn't be as simple as having a third compilation target that maps the outputs to BiRP syntax, given they already do that with ShaderGraph...

But anyways, excited to see this is finally here and to try this out!

 

Ok so let me recap: Block Shaders is not compatible with current or older Unity versions, is not compatible with BiRP and it's not compatible with Surface Shaders.

What we asked for was to port Surface Shaders to SRP for retro and inter-compatibility with ALL render pipelines and 10+ years of shaders and what we got is yet another layer of incompatibility over Unity.

Nice.

 

Yet another disappointment in the long list of Unity disappointments.
I'm out.

 

The main issue with re-using old surface shaders was the barrier to entry of copying their functionality to the newer pipelines. This system should in theory make it very easy to translate old surface shaders to the new pipelines, especially once some templates are made for it.

 

First of all, let me be clear that this is not against you or your team in particular but about Unity's direction in general and there is nothing personal in it:

You'll have to excuse my lack of confidence in any potentiality after all these years of lackluster SRP performance and compatibility compared to BiRP.
With this you had the opportunity to bridge the gap between BiRP and SRP, incentivize adoption of the SRPs by BiRP users and leverage more than a decade of shaders by simply supporting Surface Shaders on the SRPs, but instead of that you opted for yet another new layer of incompatibility over the SRPs, doubling down on all what the community criticized the SRPs for.
You keep pushing the SRPs and try to bury BiRP and yet the community refuses to let BiRP die. You should ask yourselves WHY, instead of doubling down on something the users don't really want.
The problem here is the mindset.

 

+1 to what @atomicjoe is saying. Big problem for adapting SRP is the fact that we can't easily port shaders, now you make a tool that could solve it and completely neglect this fact. It's just annoying to see Unity trying to act like BiRP is not a thing again and again. That's not exactly how you make people change their toolset you know.

It's like if Blender 2.8 decided to just straight up remove old shortcuts instead of providing compatability options. You don't exactly need a survey to understand why this would not work well

That said, I have a question regarding syntax

Code (csharp):

1. Implementation VertexDescription
2. {
3.     FogBlock()->(VertexFogIntensity: FogInterpolator);
4. }

Why use -> operator instead of just FogBlock(VertexFogIntensity: FogInterpolator);
And what can Implementation thing have inside it anyway, except call to a block?

Also. How template is selected, or whatever is used to generate a shader? Would it be possible to select template from block shader itself, thus, assets like GPUInstancer could provide custom templates that would work with their own rendering systems

 

Definitely. Oh, damn it, definitely! My understanding was that all this was intended to finally provide RP interoperability between all RPs supported by Unity.

What we desperately need since the very arrival of SRPs is some way to have our shaders and materials so they just work no matter the actual RP being used in the project (BiRP, URP, HDRP, future/other RP...). Of course they may look different depending on the RP used. Of course some features will be available in some RPs and not in others. But they will *just work* instead of showing a pink material.

You guys even gave a talk in Unite Copenhagen 2019 entirely dedicated to create BiRP-URP compatible shaders and effects! It's a very unexpected surprise that now BiRP is a "lower priority", given that it's the only RP that is truly universal still today! Many of us have been stuck here since forever, as upgrading to any non-BiRP pipeline has always been an one-way destructive path for our projects.

Sure, I'll fill the survey if that helps. Thank you for your understanding!

 

If you can actually have a tool that could convert surface shaders to block shaders it could as well be a proof that new system at least has no regressions compared to previous. So I think that would be a good idea

And syntax now makes perfect sense to me, thanks. So far idea looks better than surface shaders. Those were weird and built around edge cases so I like this new approach more

 

I’m not technical enough to understand the way it all works but I have a question, Jason made this tool that lets you write shaders for all the render pipelines, ( BIRP included ) why does unity not allow for this?

https://assetstore.unity.com/packag.../better-shaders-2021-standard-urp-hdrp-205770

 

Same for Amplify shaders, they can work on all pipelines, what is needed is more unity between pipelines and not just between URP and HDRP

 

Please, please do. Compatibility between *all* RPs supported by Unity has been desperately needed for too many years.

Young people might not remember this, but years ago one of the mottos in Unity was "author once, build many". The introduction of SRPs blew all that up, leaving many of us stuck at BiRP or Better Shaders.

 

That's not what we need. We need full Surface Shaders compatibility.
Sorry if that's not what you wanted to hear, but that's just the way it is.
If that's not easy to do with the current state of SRPs, then maybe that is what should be fixed, instead of putting band-aids over a bleeding wound.

 

I can kinda get why people want BIRP support, it would help with the transition for sure. I imagine on Unity's end since BIRP will DEFFINITELY be depreciated at some point it doesn't seem worth the effort. Cause as soon as URP/HDRP is more dominantly used, they'll move on completely. They just need to make a more convincing argument to do so.

And the side effect of adding support for this is people may stick with BIRP for longer than they'd like.

But I think the reason they should is cause when that depreciation happens, hopefully the transition will be much smoother. I've already long left BIRP behind personally, but there's still the issue of assets and such that might not be SRP compatible. So, I would maybe see benefits on the asset store side in the end if people could more easily update their assets.

But I'm certain this will complicate matters, sure it CAN be done, but people already complain about Unity being slow as it is. And maybe some dude who knows BIRP in an out can make a tool for it, but how many people at Unity now are at that level that are available for that job?

At least for me personally, the need is low priority compared to the desire to see things move forward as an SRP user.

 

Don't you think being able to transition without redoing all of your shaders from scratch would be nice argument?

This kind of thinking doesn't apply to majority that still use BiRP. Mostly because it's not only not compatible but actually better than glorified mobile renderer which is URP and simepler than parameter hell that is HDRP. But I'm getting off track now so gonna shut up

 

Not at all. Adding support for BiRP would allow us to finally move to URP and HDRP.

The need of support BiRP for full compatibility is what forces us to stay in BiRP. If we had cross-RP compatibility, we'd just move to HDRP and write HDRP shaders and materials with the confidence that they will still work in BiRP and URP. That's what many of us desperately need to leave BiRP behind.

Then Unity may sunset BiRP at any point later when anyone can use any SRP and URP is feature-parity with BiRP.

 

BiRP compatibility is needed, though I get why unity keeps wanting to kill it. But it should be easy enough for them to write a template for it, if it isn't, then something is very wrong with this new system.

That said, I think sticking with the old surface shader format would not only have been a mistake, but would have caused all kinds of headaches for users as well as developers, as some features of that system simply would not work. Further, that syntax was rife with issues - such as the magic variables (viewDir, what space is it in?) and implied vertex interpolators from texture names, etc. It also would have prevented composition of shader blocks, which Better Shaders proved is a very desirable feature.

However, it does mean people like me will have to do yet another translation of all of our shader code to yet another new format, which will take a few months given how much shader code I have. So we'll just throw it on the 2 years of unpaid labor Unity has already forced me to do or lose my business.

As for the actual system, I'll need to spend some time with it and figure out if I'll be able to port my work to it. Immediate things which come to mind is how do I modify things like texcoord's to have centroid sampling without modifying the template, since raw v2f structures don't seem to be exposed, are tessellation stages supported, etc?

 

I think Unity's coexistence effort if done properly will mostly nullify this problem, even if BIRP isn't supported. I understand there's some risk, but at some point the feature set will have to make BIRP obsolete.

Like I said it makes sense for transition.

At some point things will pass the rubicon where people are annoyed when anything new supports BIRP.

 

So unzipping the mac editor from the doc file just produces a large file with a .out extension. What am I supposed to do with this?

 

Since i can't run the editor, I'm reading the docs:

- float2 is not listed as a supported type? nor int2, int3, int4?
- having a color type instead of a float4 seems like a mistake
- the property syntax has changed - is there a reason for this? Does this invalidate all material property attributes, etc?
- only surface and fragment shader support?
- no way to add a custom pass without modifying the template, for things like an outline pass
- How are texture2d's passed to functions? What about samplers, _ST, and _TexelSize? Examples seem to use tex2D semantics
- How are template inputs handled - I see the examples use normalTS, but what if my normal is in world space? Do I have to pay the cost of putting it into tangent space and just having them template convert back? Or can I set either and have it do the right thing somehow by declaring which space my output is in?

Code (CSharp):

1. Block DirectionalLightingToon
2. {
3.     Interface
4.     {
5.         [Property] in UnityTexture2D DissuseMap;
6.         [Property] in float RimAmount;
7.  

whats a DissuseMap? Does that mean it's not used? I've had enough of that second property over the last few years thanks

Suggestions:
- Consider something like the SurfaceData structure I do for Better Shaders to make shader authoring easier for new users. This structure contains a bunch of precomputed variables for the user, like "WorldSpaceViewDir", "TangentSpaceViewDir", "WorldSpaceCameraPosition", etc. Learning to compute all that stuff requires a lot of unity shader specific knowledge and is also different in different pipelines (camera relative, not camera relative, etc), so having a simple set of variables or functions all in one place to do it in a cross platform way will make everyone's lives much easier than crawling through source files.

 

Ok, unzipped the tar, but it says the editor is not a valid application - also tried adding it to the hub, which also rejected it.

 

When added through the hub, it warns me and I click got it, but then when trying to open the project it can't find the editor version..

 

Amplify is a node based shader editor, just like ShaderGraph. Amplify shaders themselves are just regular shaders that have been compiled out of the Amplify editor for each of the pipelines. ShaderGraph supports all 3 as well and you could just the same include ShaderGraph shaders in your store asset and add a shadergraph package dependency.

 

Yeah, I had to do it via command line because the anyone option isn't available by default..

- Adding via the Hub complains that it's not a signed unity application
- Double clicking it says "the application Unity cannot be opened"
- "open Unity.app" via terminal "Application cannot be opened for an unexpected reason"
- go into contents of Unity.app/Contents/MacOS and try "open Unity" just opens a text editor with a bunch of goop in it.

 

Code (CSharp):

1. [Property(uniformName = "SamplerState")][SamplerState(filterMode = Trilinear, anisotropicLevel = 8, wrapMode = MirrorOnceV, depthCompare = true)] UnitySamplerState MySamplerState;

So does this mean we can expose sampler states to materials in a non-texture binded way? That would be a big help in fighting the sampler stripping issues that arise when sharing samplers or when passes are run that don't use all the outputs. For instance:

Code (CSharp):

1. TEXTURE2D(_Foo);
2. TEXTURE2D(_FooNormal);
3. SAMPLER(sampler_Foo);
4.  
5. SurfaceFunc(Input i, Output o)
6. {
7. // this will break on URP2021's depth normal pass because albedo is not used and the sampler gets stripped
8.     o.Albedo = SAMPLE_TEXTURE2D(_Foo, sampler_Foo, i.uv);
9.     o.Normal = SAMPLE_TEXTURE2D(_FooNormal, sampler_Foo, i.uv);
10. }
11.  

 

Ok, so no way to have that exposed to the user then. I'm also assuming I can create a texture without a sampler state, right? Because I have hundreds of textures in some of my shaders, so I can't have a sampler for every texture, but I still need the user to specify things like wrap mode, etc (it just uses the albedo one). And that also means I'll still have to hack around samplers getting stripped when they are still being used by other textures, which is a drag but no worse than what it is now.

 

Would it be possible to add ability to expose sampler properties to editor somehow? Like selecting filtering from shader/setting from C#. This would be really nice

 

Yeah, I get it - just got excited for a minute there as I dev on mac and this often bites me when someone runs on windows (mac doesn't strip the samplers like DX does), and often not because of a change I make, such as when URP added the depth normals pass and all my existing code broke because there was now a pass that didn't use albedo and just used normals.

Now if I could just get the editor to run to try this thing..

 

This does remind me it might be valuable to consider having an 'escape hatch' to raw code within your constructs - one advantage of Better Shaders is it really just outputs code from combining text blocks, so it doesn't need any translation or understanding for the most part. And in this case, if I could raw output a texture declaration, it would have allowed me to declare a texture without you adding any features to the system. Not to say that textures without samplers shouldn't be added, but I can imagine coming across other advanced cases where something isn't supported.

It also makes me wonder if the system should encourage combined samplers via tex2D and such at all. Or if it's better to just force users to understand textures/samplers being separate things from the beginning, since that is how all graphics APIs work these days. The idea of combined texture/samplers is really DX9 heritage at this point, right?

 

Until the DX9-isms are completely gone (like having sampler state option based on the selected texture), I expect the idea of combined samplers will remain.

While that's very true about backdoors, when has a system ever truly been 100% wrapped correctly? Shader lab allowed backdoors into HLSL/GLSL code so you could write it directly - fully understanding that it isn't portable or upgradable. Shader graph allows the same with its HLSL node, and is being used to hack in all kinds of interesting things that shader graph couldn't do without it. Now this might not be true for things like properties, but certainly we already have use cases of this within the system that have proved incredibly valuable in the past, and most languages allow some form of this in one form or another (unsafe blocks, asm in C++, etc). There is always a need to get to the lower layer and avoid the abstraction for one reason or another.


Hey, custom editors for blocks? How will they be handled and combined into an interface for a shader built out of reusable blocks? I do this in Better Shaders by allowing blocks to declare them and they receive a list of properties they can display, then a custom editor just iterates through the blocks sending each custom editor their data.

 

May be better make new tool of 2023+ that will bake projects aimed for 2024+ to support only DX11(maybe), Dx12, Metal, Vulkan?

Drop support for abandoned tech and stop limiting yourself.
For older platforms we already have plenty of different tech in Unity and on AssetStore.

 

This looks really cool! Any ideas on timelines for when a public beta could be released?

I gave up on URP and stuck to BiRP because the amount of setup and trial and error needed to just convert very simple shaders was insane, this seems to fix that and lead to a world where writing URP shaders is actually fun and productive.

I agree with everyone that straight up BiRP support would be awesome, but a sensible system like this means that it’d be much more straightforward to convert shaders.

 

I'd agree with this if vulkan on android felt more complete... But my personal experience with things like the game crashing when using more than 1GB of ram says otherwise.