Hi! In previous Versions of Unity you could write custom sprite shaders by multiplying the sampled _MainTex with the vertexcolor. But it doesn’t seem to work anymore in recent Unity versions.
Do they write the color property of Sprite- and Image Renderers to a differently named vertex property now?
Sample Graph that used to work:
I dont know, who to tag here. But to me this is a regression for people who create custom shaders for sprites, for example as opaque materials instead of transparent ones.
For anyone curious, it looks to me like the Sprite/Graphics Renderer now use a property called unity_SpriteColor instead of baking the color into the vertices of the sprite mesh.
(I looked into a compiled SpriteShaderGraph shader)
Unfortunately ShaderGraph doesn’t seem to support the use of said property fully. It does work, but breaks the preview.
Hi, while we are taking a look at the issue, please try the following:
Set Material to Sprite CustomLit under Graph Settings.
You should now be able to use and connect the Custom Function.
Once the node is connected as required, please change the Material back to whatever is desired “SpriteLit” etc…
Please ignore the error / warning icon. Save the Graph and the generated shader works.
We will post an update once we find the error issue. Sorry for the inconvenience caused.
Also could you please submit a bug report with the project? Thanks.
As I mentioned: The SpriteShaderTargets aren’t always fit for purpose, for example if you want to create an opaque shader.
Awesome that you are investigating this though! A custom node for the built-in properties would be a great solution!
Adding a bit more info. Sprite Renderer Color is represented in various ways depending on the Batching Pipeline used to render it. The following are various ways 2D Renderers are batched:
- Dynamic-Batching (All versions of Unity).
Color is baked into Color channel of the Vertex Data. This way multiple sprites can be batched to a single draw-call even if their colors are different as long as the Material and Textures are the same.
This is suited when rendering different sprites that has the same Material and Texture when their triangle count is small (like a quad sprite for example)
-
Instancing (All versions of Unity).
Color is now set through internal unity_SpriteRendererColorArray cbuffer of the shader so multiple sprites with same instanced Material as well as Sprite can be batched together. This is suited when rendering different sprites that has the same Material and Texture when their triangle count is very high like sprites with highly detailed tessellation (when using 2d.animation for example).
Vertex Color is always white for these draw-calls and is unused. -
SRP-Batcher (>= 2023)
SRP-Batcher was only introduced in recent version of 2023 and Color is now set through unity_SpriteColor property so that multiple sprites with the same Shader and Sprite can be batched together.
Vertex Color is always white for these draw-calls and is unused.
Dynamic-Batching is the default batcher and is the default way of batching Sprites for both Builtin and URP for all versions older than 2023.
In 2023 and beyond SRP-Batcher is the default Batcher for URP. Dynamic-Batching is default for Builtin pipeline.
Thanks! That answers pretty much all related questions.
It would be great if there was documentation of shader properties set by unity (eg unity_SpriteColor for u2023+) → if there already is, could you point me to it?
Since only the Renderer Color is exposed and the implementation details are Internal, I believe it may not have been documented although the shaders are available for modification.
Will try to add documentation in an upcoming version. Thanks for your patience.
I encountered the same issue in Unity 6 where my SpriteRenderer’s shader stopped working.
It can no longer retrieve the sprite color through VectorColor.
so. from Unity 6 is there any other way than just use
CustomFunction Color = unity_SpriteColor;
in ShaderGraph to access colors?
Thanks
Vertex Color should now always return the Sprite Color.
Which version of Unity 6 are you using?
Hi,
I need to use SpriteRenderer in a 3D scene and have it cast shadows.
In my current Unity version (Unity 6.1.6000.1.9f1), when I use the Sprite Lit shader, I can access the color set in the SpriteRenderer via Vertex Color.
However, enabling Cast Shadows on the SpriteRenderer (via Debug Mode) does not make it actually cast shadows.
On the other hand, if I switch to the Lit shader, shadows are rendered correctly — but then I can no longer access the color from the SpriteRenderer using Vertex Color.
In earlier versions of Unity, I was able to access this color in Lit mode using:
CustomFunction Color = unity_SpriteColor
But this no longer works in Unity 6.1.
So
- How can I access the color set in the
SpriteRendererwhile using Lit mode in Unity 6.1? - Or, how can I make Sprite Lit mode support casting shadows?
Thanks
Hey, it has been a while, did you have the chance to improve the documentation for unity shader properties?
This would also be helpful because in the past I and probably other users have encountered shader errors because of accidental redefinition of ‘reserved’ property names like _Emission etc.
This issue is still present in Unity 6000.2.2f1, “the customnode, unity_SpriteColor” works in the game but the preview panel still shows as broken. Similarly, the VertexColor no longer seems to get set from the color property on SpriteShapeRenderers, getting vertex color returns white.
I agree that this should be fixed, however if you need something that works now you can solve it like this:
if you wrap your hlsl code in #ifdef SHADERGRAPH_PREVIEW you’ll only execute the shader code if it’s in the sg preview window.
This is also valuable for things that are only present in a game scene.
#ifdef SHADERGRAPH_PREVIEW
Color = float4(0,0,1,1);
#else
Color = unity_SpriteColor;
#endif
Hey, how’s the addition to the documentation coming along?
I just recently discovered this page:
This seems to be explicitly for the legacy render pipeline. It would be great to have a document like this for the scriptable render pipelines.
Unfortunately, adding “color = unity_SpriteColor;” as a custom node completely breaks the shadows for me. It seems like this variable isn’t set in the shadow pass.
It does work to use the sprite colors but shadows stop working.
Anyone managed to solve this issue?
I’m using SRP batcher in URP, and a shader graph lit shader applied to a sprite renderer.
Note: By the way if you disable SRP batcher, the Vertex color is working. That only stops working when you enable the SRP batcher. But I would like the SRP batcher to work for optimization.
make sure that your renderer doesn’t strip the shadow properties on cpu side, as it often happens with sprite renderers and might also apply when “unity_SpriteColor” is present.
Switch your Inspector to Debug Inspector to check.
at this point I need to also point out that I’m not affiliated with unity in any way it would be really nice to have some official staff response to peoples inquiries. @FredMoreau
My settings are already like this, it still breaks shadows for me when using unity_SpriteColor in Unity 6000.0.60 URP and multiplying it to the texture color.
As it seems unity_SpriteColor is not sent to the shadow pass. Shadows are working fine otherwise when i remove that variable.
My goal was to make sprite trees transparent when the player is behind them. So i used to change the sprite color alpha. My old shader was using Vertex Color but when I enabled SRP batcher it broke so I had tried to switch to the solution in this thread, which broke shadows.
To go around this. I set a color property on the material. And when the player is behind the sprite, i swap the material to a unique one, then change the _Color property on that material. When the player goes far away from the tree, i swap back to the common Opaque material shared by all tree so that all trees can be drawn in a single batch, except the one with transparency.
And Unity devs: You should consider sending unity_SpriteColor variable to the shadow caster pass with URP SRP batcher. I already sent a bug report from inside the engine: IN-127136






