Provide access to surface shader generator as a feature

I am developing an editor extension. While working with surface shaders I encountered problems with unity's way of tessellation https://forum.unity.com/threads/artifacts-in-tessellated-terrain.498964/. In this particular situation I wanted to do some modifications in the hull shader and make triangles bigger to overlap some tiny gaps caused by lack of precision. With surface shaders in its current state it is not possible to do anything like that.

I am a huge fan of surface shader as they make shaders simple and compatible with the engine. I have seen people with similar problems gone the pixel shader route and use self-made tools to create pixel shaders that are largely copy-pasted from generated code derived from surface functions. That's error prone and easily breaks compatibility across platforms and different lighting setups.

I am wondering if unity has plans to provide an API to the surface shader generator. I mean in simplest form it could provide some hooks that give generated functions as string and allow the developer to replace it with something else before the actual shader object is generated. For example give me the generated vertex shader and I change that slightly. Even such a simple system can be far far better than ad-hoc solutions by developers.

So what's your opinion guys?

 

Full source code of surface shaders is avialable in download section. Every single thing.

https://unity3d.com/get-unity/download/archive
Select "built-in shaders"

According to unity's staff it is under permissive license (I think it was MIT), meaning you're allowed to modify them as you see fit.
https://forum.unity.com/threads/unity-shader-sources-license.433178/

Keep in mind that built-in shaders are a big mess.

Also... if you're talking about hull shaders, keep in mind that unity only supports triangle domains. No quads or anything like that. Which makes certain things inconvenient.

 

Thanks for the answer. The would be feature I am talking about is the ability to interact with surface shader generation. I mean the code that converts the surface shaders into pixel shaders. Exactly as you mentioned things like quad tessellation can't be done with surface shaders.

I am talking about a potential feature that acts when pixel shader is generated from surface shader. After the generation of pixel shader code from surface shader it could give developers the whole or partial generated code as strings and give developers opportunity to change the code. After that pixel shader asset will be generated.

This kind of feature allows directed surgical changes to specific parts of generated pixel shader code. It is simple both for unity to create and for developers to use, It keeps compatibility with unity's engine and different rendering setups, and it gives developers the ease and reliability of surface shaders with all the power of a raw pixel shader. I hope UT guys watch this thread and see the potential.

 

Well you posted in the forum section to have decent chances of that happening

https://forum.unity.com/forums/shaders.16/

 

I would be grateful if get an answer from someone in UT Is Aras still around?

 

My understanding is this is unlikely.

Surface Shaders are at a state where minor fixes and features might be added, but if you want to make major changes to what the Surface Shader generates the solution is usually "write a vertex fragment shader."

Some asset authors have taken to write their own shader generators. See MicroSplat for an example of this.

Going forward for the future Unity is planning on likely replacing the existing rendering pipelines with their Scriptable Render Pipeline with allows far more control over how things are rendered from C#. Part of that work appears to include a shader generator of some kind.
https://github.com/Unity-Technologi...ScriptableRenderPipeline/Core/ShaderGenerator

Also, Aras is no longer working on graphics related stuff... most of the time.

 

Exactly. I know some of these works. The authors went to great lengths in order to overcome shortcomings of surface shaders. Imagine if there was a single delegate which would give you a chance to change the generated pixel shader in string form. Shouldn't be too hard I guess...

That's fantastic news. Hope it gets out in 2018 version. I took a peek into the code and I don't think it's about surface shaders. It seems more like a node editor.

Thanks for bringing some light to the matter.

 

MicroSplat/MegaSplat's compilers are mostly about getting around the shader_feature combinatoric explosion. I have around 100 features in each, which takes over a month to compile every combination of, so shader_feature wasn't a viable solution.

That said, I think the abstraction Surface Shaders currently provide is a very useful one. I have asked Unity how they are going to deal with this in a post-surface shader world like SRP, and have not gotten a very useful answer yet. Doing everything in a vert/frag for MegaSplat has become one of the largest support cases for the product, which is why MicroSplat only generates surface shaders. The current Unity lighting pipeline is such a mess that they can't even explain everything you need to do to get all the various lighting modes working, and I have had to spend countless hours diffing changes Unity makes in the pipeline trying to keep it all compatible.

So lets fast forward to the SRP world where there's no abstraction around lighting. How does one write a shader that just works across multiple SRP pipelines? How does one write a new SRP pipeline that doesn't require re-writing every shader? Without some kind of scriptable shader compiler I'm not sure how this would be possible.

One answer I have heard from Unity is that they will make the lighting pipeline 'much simpler' so this isn't an issue, but certainly on the low end I'm not sure how that is possible. A single unified lighting model that just works across multiple hardware variants, performance characteristics, and rendering styles does not exist that I know of. Almost every lighting model uses some combination of hacks and multiple techniques to work, all of which tend to muck up shaders with multiple passes, data stuffed into vertices, etc.