Vertex displacement without affecting rendering in SRP

Hey everyone,
I have an asset that does simply vertex displacement in a surface shader without touching the rendering part. This is pre-SRP, of course.

Is there such a thing for SRP?
I'm afraid that I'll have to rewrite the shader for each Pipeline with specific rendering code.
If so, is there an easy way to do so? I'm just looking to provide basic lit rendering (lighting, 1 texture for albedo).

Thanks!

 

Grab the vertices from the mesh and change them in a script.

 

That's not viable in my case. Need to do it in a shader.

 

If you're looking to do vertex displacement in SRP, of course it's possible, but you're going to need to write a custom Shader for the target Pipeline that does the vertex modification.

To make it more simplistic for other pipelines to use, you could nest all of your vertex modification code in an include file and define a macro.

 

Shader Graph should be supporting Vertex Position at some point so you can create your shader then with the tool. Then again it depends on the pipeline you use since Shader Graph will probably be different in HD Pipeline (to support the extra shader options) than Lightweight Pipeline.

 

@equalsequals would you be willing to write up a minimal example of that? I would find it super useful! It was me you were talking to on reddit about creating custom master nodes (unless I have you confused with someone else!)

 

I'm trying to avoid ShaderGraph at all cost for now.

The vertex modification is fine (thanks for the macro tip), I was actually asking if I'll need to write different rendering code for each pipeline (I want standard rendering on all pipelines, like surf shaders used to provide), and if so, links to some examples.

Thanks for the reply

 

Ah I understand now. Unless you are needing to populate some global constant buffer or something from inside the Render loop, you shouldn't have to modify the loop's C#. You would need to, however, have some HLSL that would play nice with the vertex functions of each Pipeline's Shaders. The vertex functions are going to work pretty much the same way as in the built-in Renderer; Mesh data comes in, a v2f struct comes out.

If you're just doing displacement, that is going to get bound to your SV_POSITION, since that's the position data that is used by the rasterizer. As I mentioned, a Macro would increase portability to any SRP.

Cheers

 

Yeah, I could probably swing that. There really isn't anything to it that would make it any more complex than it was previously if you were to say, modify the Standard Shader with override .cginc files. Keep in mind that it's much easier to modify the SRP code if you have it directly in your project from GitHub than with the package manager, since obviously you have all the code right there.

To @Grimreaper358 point, though, the future is going to be writing reusable snippets and wrapping them in custom Nodes for ShaderGraph, however that could be the same snippets that exist in Macros or inlines in an HLSL include.

 

@equalsequals I didn't quite understand.

"You would need to, however, have some HLSL that would play nice with the vertex functions of each Pipeline's Shaders."

So it'll be necessary to have pipeline-specific rendering (not vert displacement) code? Could you point me to any examples?

 

Well yeah, if you are working outside of ShaderGraph, which is meant to be a solve for this (reusable snippets as Nodes), and with a lack of the concept of Surface Shaders (coming some day, perhaps?) you'd need to have some custom Shader code written.

Using LW as an example, LightweightPassLit.hlsl holds the structs LightweightVertexInput (read: appdata), LightweightVertexOutput (read: v2f), and the vertex and fragment functions ran in the LightweightStandard Shader. We can see that in the LightweightForward Pass of LightweightStandard the LightweightPassLit.hlsl file is included and it sets the pragmas for vertex and fragment to the functions located in that file.

The LitPassVertex (the vertex function) does essentially the same thing as UnityObjectToClipPos here:

Code (CSharp):

1. float3 posWS = TransformObjectToWorld(v.vertex.xyz); // object-to-world transform
2. o.clipPos = TransformWorldToHClip(posWS); // world-to-view-to-projection transform

Where o.clipPos is bound to the SV_POSITION semantic in the output struct. Here you have the opportunity to modify the vertex position in either object or world space.

Hope that helps.

 

It does!
Thanks for bearing with me here, having a hard time getting my head around SRP.

 

If it helps at all I wrote one from scratch to better understand them and wrote a blog about it here:

http://colourmath.com/2018/tutorials/exploring-scriptable-render-pipelines-in-unity-2018-1

Cheers

 

Definitely need to look more into it.

Thanks!

 

@equalsequals Hey those are a nice tutorial, do you have any public repo from that tutorial? seems to be a nice starting point to learn about SRP.
Edit : Ah i'm just being stupid, totally missed the link in your blog post. Sorry

 

Yes the GitHub is linked at the beginning. Here it is for convenience: https://github.com/colourmath/ScriptableRenderPipeline