Official SRP Surface Shaders

Since Unity abandoned all attempts to do surface shaders 2, I did..

https://assetstore.unity.com/packages/tools/visual-scripting/better-shaders-standard-urp-hdrp-187838

 

any out of the box support for meshanimator and bakery?

 

It looks like Unity is starting to take this seriously, they've added Surface Shaders as a planned item in their graphics roadmap:

https://portal.productboard.com/8uf...ers?utm_medium=social&utm_source=portal_share

Personally I'd love to see jbooth's Better Shaders asset get acquired for this as it already works for LTS Unity versions, has Bakery support, and has stackable shaders for more modular shader code. If anyone on this thread who wants a faster fix to the lack of Surface Shaders problem, I'd recommend sending a comment via that link saying that Surface Shaders are an important feature and to show support for a solution that already works.

 

There's another item about Surface Shaders in the URP section:
https://portal.productboard.com/8ufdwj59ehtmsvxenjumxo82/c/621-surface-shaders

Maybe they're not considering cross-SRP surface shaders?? And/or not considering built-in pipeline at all?

 

I hope they will be cross-SRP and that they've duplicated the item for better visibility. Built-in I don't see it. As soon as URP get's feature parity, is game over for built-in, for better or for worse.

 

That's good news. We could definitely use some form of Surface Shaders / "semi-hand-coded shaders". Shader Graph is cool for simple shaders and prorotyping but once you start optimizing or need access to some lower-level features, you're stuck.

 

I think the way this is worded on Product Board is dangerous.

It sounds like the actual great parts about surface shaders (ability to specify custom lighting, vertex modifiers, additional pragmas and stages, etc) are omitted. I hope it's not true, but I'm afraid what we'll be getting here is a bare MVP for "defining the surface result" which I hope you know is not what people expect.

 

Well the risk is that they’ll limit it to filling out the surface function in the shader graph output, which would make it fairly DOA. But let’s hope it goes beyond that.

There’s significant low hanging fruit in terms of shader authoring that could be a large improvement over the old surface shader system with minimal amounts of work. I think that’s fairly well proven by Better Shaders, which greatly improves modularization of shaders and makes 3rd party integrations trivial, while remaining a fairly simple piece of tech that’s easy to expand and modify. My main worry for SS2 beyond it being too limited is it being overly restrictively engineered such that maintaining and extending it become the bottleneck. We see that a lot with modern Unity- shader graph can’t be expanded with new nodes, VFX graph either, Audio Mixer has no script access, SRPs require reflection to work with, etc.

Rendering tech is in an exciting transition towards more programmable models, and new tech like mesh shaders and bindless, and being able to quickly incorporate those technologies into a pipeline leads me to believe that a simpler parser which doesn’t need to understand the code much is the way to go.

lately I’ve been optimizing things like interpolator usage in better shaders; or rather putting in features where the user can opt into certain optimizations by making certain contracts with the generator. This works reasonably well, but it’s the one part of the pipeline I wish the generator knew a bit more about. Still, everything “just works” without much of the complexity and you can still get down to tighter interpolator usage if you need to. Note that the shader graph templates make this more difficult than they should; some pipelines just keep texcoord1/2 around while others decode the data into specific lightmap interpolator a- would be nice if all that got unified across pipelines.

 

Are there any updates regarding surface shader till now? (it's been 1.5 years now)

 

Agreed. We need a robust and flexible "written in code" Shader API for SRP but we don't need or want "Surface" Shaders for SRP as in the surf function by itself and the far too simplified ethos it represents. I know it's not actually this simple but Vertex Shaders and Fragment/Pixel Shaders separate roles' in rasterization as high level abstractions can be explained to and understood by any 5 year old that's familiar with a coloring book... form (black outlines like wireframe geometry) and color (crayons or colored pencil that define color, texture, lighting, etc). Which is why trying to oversimplify the concept with Surface Shaders was so puzzling, a context where the user is already considered comfortable with writing code.

One hope that I have is that even Shader Graph (a no code / low code tool) has already embraced the inherent division between Vertex and Fragment stages with "Master Stacks" so I would hope any Shader API (at a lower level representation than a visual tool) would be less abstracted, not more. And if you don't need vertex modification, fine, just leave that boilerplate (visual or code) alone.

There is also some confusion as it seems many people colloquially refer to Built-in Render Pipeline / BRP's entire ShaderLab Shader API as "Surface Shaders" even when there is a Vertex modification function and all these things that very necessarily broke the "simple" Surface Shader ideology. As is common if you need a custom shader these days anyway.. if you need something really simple.. just use a pre-made material, or use Shader Graph.

So yes, it is troubling that the way this is currently worded on the Roadmap / productboard items as it implies that this is somehow going to be regressive or is misunderstood perhaps because folks at Unity hear this composite swell of people yelling "Surface Shaders for SRP!" when that taken literally and without proper context is not actually going to get the job done and fill this Shader API for SRP shaped hole we have right now.

Hopefully @ali_mohebali and the team(s) are already of aware of this / still hashing out the exact scope and thus hasn't updated the vaguely worded Roadmap item description(s) to reflect this yet?

 

Yes, as was mentioned earlier in the thread, "Surface Shader" like API and Shader API improvements are now officially planned features on the URP and HDRP Roadmaps as of ~3 weeks ago. See the "Planned" sections under the URP and HDRP tabs for "Surface Shaders", and "In Progress" section in URP tab for "Shader Library and API Documentation Improvements"

So, this is happening. But the exact scope of features is as of yet unknown, so that's still a hot topic of discussion right now.

Main Rendering roadmap page: https://unity.com/roadmap/unity-platform/rendering-visual-effects

Direct links to roadmap items:
https://portal.productboard.com/8uf...er-library-and-api-documentation-improvements (URP)
https://portal.productboard.com/8ufdwj59ehtmsvxenjumxo82/c/621-surface-shaders (URP)
https://portal.productboard.com/8ufdwj59ehtmsvxenjumxo82/c/628-surface-shaders (HDRP)

 

I dunno maybe they can use Shader Graph codegen as the starting point to generate human readable future cross-pipeline surface shader code just like human written code to battle test this future cross-pipeline surface shader tech. I imagine the future that I can write cross-pipeline surface shader to become shader graph and back and forth.

 

I think you are confused, your puzzlement comes from the fact you miss that surface shader is an abstraction of light implementations, ie it had a new light pass on top of vertex and fragment, because i always had these 3. Which allowed to change the light model while not touching the surface definition. It's about decoupling light and surface, ie you write a surface as an input to a light program. I meant you didn't have to reimplement the light back end such as shadow, probe, etc... only control the final composition. NOW the implementations mostly favor pixel lights over vertex light, but that's a limitations unity used as a convenience.


Imho finding a new abstraction for managing the light back end would be a great innovation to complement the surface idea. I thought srp would have been that in some way, but some features were missing and I'm not sure their srp abstractions is clear enough. But i only had cursory look at srp, never did anything with it yet.

 

The initiation of this thread feels like:

"Justify Surface Shaders, and design them for us. We've forgotten why they matter and can't understand why everyone wants them."

 

All they need to do is talk to @jbooth and @Aras and @bgolus - I don't care what other people say, these three have long since earned my trust in matters of shader authoring (not that they ever asked!)

 

Any updates on this topic?

 

https://forum.unity.com/threads/blo...s-and-more-public-demo-now-available.1350497/