Grabpass changes behaviour in built-in shader?

Unity Engine
1

Hi All,
I have encountered a slightly odd problem with the built in renderer (not universal or HDRP) on 2018.4 LTS.
Essentially, I have a large gameobject which brings in the environment, and in particular alpha rendered water. If the object is enabled when I start the game, then a lot more grab passes are shown in the frame debugger, which is probably bad for performance but means my explosions which use distortion from grab pass look correct.

If I disable the object, then enable later only one grab pass is performed, but this is before the water rendering, so the distortion in the explosions “sees through” the water :frowning: Here is a side-by-side from the frame debugger:

5538883--569758--grabpassdebug.png
5538883--569758--grabpassdebug.png1466×1458 234 KB

It looks like if the object is disabled on startup then unity is deciding that only a single shared grab pass is needed but if enabled then it enables grab “per mesh”. Does anyone have any details on how unity decides this?

I can fix this using a zero-sized water object with the same shader etc placed in front of the camera but I was wondering if anyone knew how to debug when and why unity calls a grab pass, or if there was a better way to artificially “force” a grab pass? Ideally it would probably just be two grab passes, one for the water, then afterwards a single shared carried out after the water is drawn I think…

Thanks in advance for your help!

2

so, I have found some information which is relevant by looking at the source for the unity standard shaders. From the docs there is different behaviour between generic GrabPass {} and GrabPass { “NamedTexture”}. In the unnamed context the grab becomes available in a texture called _GrabTexture, and the grab is made whenever an shader needs it, i.e. per mesh. In the named context, it is only grabbed once.

Here is the interesting part - the unity particle shader uses GrabPass { “_GrabTexture” }, so it appears to sort of “rewrite” the behaviour of the unnamed context to be a single grab. I think this might go some way to explain why in one scenario we get multiple grab passes and in another only one…