Introduction of Render Graph in the Universal Render Pipeline (URP)

[ilcane87]

@ilcane87

Hello, I’d like to request clarifications about an Issue I’m having: I just updated my project to Unity 6 from 2022LTS, and CommandBuffer.Blit doesn’t work anymore.
I know it’s not the recommended method for blitting, and I knew it back then when I started using it too, but neither the recommended Blitter.Blit nor the ScriptableRenderPass.Blit commands have ever worked for me, even though i’m using them with the same parameters and shaders I was successfully using with CommandBuffer.Blit, so right now I’m left with no working option for blitting.

What I’m trying to do is very simple, I have a Texture2D, and I need to blit it to a RTHandle of the same size through a material. That’s it.
Here are the relevant lines of code, the latter used to work before the update, but that has no effect on the target texture either:

Blitter.BlitTexture(cmd, sprite.texture, rtHandle, material, 0);
cmd.Blit(sprite.texture, rtHandle, material, 0);

Could you explain what is going on?
Thank you very much.

@ilcane87

After some more experimenting, I should note that Blitter.BlitTexture does affect the target texture when using a material with a “Fullscreen” shadergraph; however, it has no effect with any other type of shadergraph on it.
CommandBuffer.Blit does affect the target texture when using a material with a “Fullscreen”, “Canvas”, “Unlit” shadergraph (and maybe some others), but none of the Sprite types work, which are the ones I need.

These are starting to look like bugs, could a Unity dev please chime in?

Just an update in case someone else with the same issue is taken here by google, I received a response from Unity that suggested a workaround:

Based on the developer’s investigation, it seems that the Sprite-Unlit shader is being used for Raw Blit and ideally Blit-Shader should be used for render texture/blitting. However, if the current approach is required, please set the default values explicitly for the properties as defined in the following attached script:
[…]
spriteRenderer.sharedMaterial.SetVector(“unity_SpriteProps”, new Vector4(1.0f, 1.0f, -1.0f, 0));
spriteRenderer.sharedMaterial.SetVector(“unity_SpriteColor”, new Vector4(1.0f, 1.0f, 1.0f, 1.0f));
[…]

In my case it wouldn’t make much sense to use ‘Blit-Shader’ since I’m blitting for the purpose of caching the outputs of custom sprite shadergraphs, so I went with the sprite properties alternative.
Apparently, unity_SpriteProps and unity_SpriteColor are undocumented internal shader properties that as far as I’ve seen can be written to but not read from a material.
According to the only post I could find about them, unity_SpriteColor is used to communicate the renderer color to the shader, while the ‘x’ and ‘y’ of unity_SpriteProps are used to communicate the flipX and flipY values of the renderer (supposedly their value is 1 when flip is false and -1 when it is true).
I asked Unity about the ‘z’ and ‘w’ too, and this is what they answered:

‘z’ of unity_SpriteProps to -1 is used internally for skinning (usually set when using 2D Animation package). It refers to the starting offset index of a global transforms buffer which is used if GPUSkinning is enabled.
‘w’ is unused as of now.

I can confirm that this workaround solved the issue for me, at least as far as using CommandBuffer.Blit goes; unfortunately it had no effect on Blitter.Blit, which still yields a completely transparent texture, but since I now have a working blitting method I’m not going to pursue the issue further.

I will soon disable ‘compatibility mode’ and attempt to convert my scriptable render pass to an unsafe pass in render graph, if this causes any changes to the sprite blitting behavior I will report it here.