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).
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.
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.
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.
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:
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.
@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