Sorry for the late reply as well, back from my vacation.
WiseKodama As for the render pipeline, it's neither? Not sure, our quality settings, do not contain any render pipeline asset(Unity 2020.3) not sure what Unity defaults to.
Thanks for the info. If no RenderPipelineAsset is assigned in the Graphics or Quality settings, then you're using the Standard Render Pipeline (not URP, Universal Render Pipeline, which is a scriptable render pipeline).
Also since I've never worked with URP, is that something we should consider? We are heavily sprite/spine based and are focus on Android/iOS.
Standard Render Pipeline should be fine, as URP might have some advantaged but also comes with its own set of problems. You could of course perform some measurements on the target device with the same scene (and comparable shaders) using different render pipelines, that would give the definitive answer.
WiseKodama As for the solutions you've mentioned, I am afraid I would need more guidance.
Do you mean you need more information about passing data per vertex?
If so, then please see this forum posting below about passing additional vertex data to your shader:
https://esotericsoftware.com/forum/d/18476-how-to-add-additional-uvs-to-skeletongraphic/3
You would then need to read the vertex data in the shader accordingly (read it in the vertex shader and pass it to the fragment shader, then use it there) and use it instead of your material parameter.
Currently I am using MaterialPropertyBlocks for two cases with this shader:
To tint upon impact(Color animated over time)
To "cut-off" based on water depth(float set each frame based on skeleton position)
If I could get the batching working with those two requirements in mind it would help our performance quite a bit
As always, please make sure to perform some measurements on your target device. Successive draw calls using the same Material with only different MaterialPropertyBlock parameters might be cheap enough to not matter. 10 draw calls using the same material and MaterialPropertyBlocks should be far cheaper than using 10 different materials with entirely different shaders.
To be sure that the modifications are worth it you could compare performance with the identical material settings vs. modified tint and water height values. If you can't measure any difference, then you won't get any benefit from your modifications either.
WiseKodama Currently I am using MaterialPropertyBlocks for two cases with this shader:
To tint upon impact(Color animated over time)
To "cut-off" based on water depth(float set each frame based on skeleton position)
If you would only require tint upon impact, you could get away without any (or with fewer) code modification. That's because the spine-unity runtime comes with tint-black functionality. You can enable Advanced - Tint Black at the SkeletonAnimation component which then passes a second color (the dark color) as vertex attribute to the used shader. Note that the "dark color" property is set per Slot however (not per Skeleton).
Nevertheless, if apart from tinting upon impact you also need a water level parameter, I'm afraid you would need to write some code to pass this information to the shader.
An even easier solution might be the following: If you don't use the primary vertex color (which tints by multiplying your texture color with it) at all and always have it set to white, you could get by without any additional vertex data at all: you then could use the primary vertex color to convey all information that you need in your shader: you could for example pack the water level into the alpha channel of the color (normalized to reasonable values, as they will end up as values 0-255), and pass the tint color in the RGB channel. Then you can set skeletonAnimation.Skeleton.SetColor(Color yourPackedColor); to have the information passed to your shader.
