Remove SRP Batcher compatibility from custom shader

Unity Engine
, , , ,
1

Hi, does anyone have an idea of how to remove SRP Batcher compatibility from a shader?

I will be trying to implement GPU instancing for the same shader but need to get rid of SRP Batcher compatibility for it first. I know how to deactivate the feature globally in the Rendering Asset, but that’s not what I’m looking for.

Per “documentation”, I copy the ShaderGraph generated code into a new .shader file, add a new material property under “Properties”, NOT declaring it under “CBUFFER”, and that should do the trick… but instead, after recompiling, the shader is still marked as “SRP Batcher - compatible”.

I also tried utilising the newly generated property somewhere in the shader code, with no luck in breaking the SRP Batcher compatibility. Not being an expert (at all) in hlsl, I have no idea of what to try in order to actually break it.

So, am I missing something? Maybe it is really not compatible anymore but is still flagged as it is?

If someone could help, it would be awesome!

2

EDIT: I managed to make the shader incompatible with SRP Batcher, but in my own way:

  • Instead of declaring a property under “Properties” and not under “CBUFFER” as the documentation stated, I did the opposite: in my shader’s generated code, went straight to the “CBUFFER_START(UnityPerMaterial)” section, and added this line (any line of this sort would have been ok, actually) before “CBUFFER_END”: float SRPBreaker;

  • Saved the shader, and it compiled, but this time showing “not compatible” on the SRP Batcher section, with a message saying “UnityPerMaterial CBuffer inconsistent size inside etc etc…”

Hope this could help anyone having the same blocker that I had, at least in finding a different way to reach a solution!

1 Like
3

I’ve just had a similar issue. That is: I’ve been adding properties to the material that aren’t in the cbuffer (because a custom material editor requires them, but the shader itself does not). According to the documentation, this would break SRP batcher compatibility (which is not what I want), but according the the inspector, compatibility is intact for this shader… I’ve also found that having properties in the buffer that aren’t in the material property block do indeed break compatibility. So does having inconsistencies between the cbuffer used by the main pass and the shadow pass.

I would really like to know what exactly is breaking compatibility. Specifically I wonder whether it is indeed safe to add properties to the material properties block not covered by the cbuffer…

1 Like