URP - Decal is causing Spine Shader to disappear

IndieDoroid

Hi Harald

I need to pick your brain again.

I'm trying out Unity's URP shader

Decal Renderer. I notice the spine shaders disappear if I set the "Decal Renderer Feature". Image below explaining what is going on.

After playing around with the Spine Shader Render Queue Offset, I can see the spine shaders again. But I'd prefer not to change all "n+" spine shaders.

I also notice if I adjust the Decal setting to Screen Space, the spine shaders show up.

I'm trying to understand the documentation. But it's all going over my head... maybe you can understand it better.
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@12.0/manual/renderer-feature-decal.html

DBuffer
Unity renders decals into the Decal buffer (DBuffer). Unity overlays the content of the DBuffer on top of the opaque objects during the opaque rendering.
Selecting this technique reveals the Surface Data property. The Surface Data property lets you specify which surface properties of decals Unity blends with the underlying meshes. The Surface Data property has the following options:

Screen Space
Unity renders decals after the opaque objects using normals that Unity reconstructs from the depth texture. Unity renders decals as meshes on top of the opaque meshes. This technique supports only the normal blending.

Selecting this technique reveals the following properties.

My question is:

For spine assets

do we need to use one type over the other? What kinds of performance issues would arise going either route.

I'll probably be diving into this topic head first next week. So I can follow up with other potential issues that come up.

Thanks for your help :nerd:

Harald

From the Unity documentation page:
"A Decal Projector component must use a Material with the Decal Shader Graph assigned (Shader Graphs/Decal)."

So using any other shaders is basically not supported. If you want to use a SkeletonRenderer, you could export the atlas using straight alpha workflow instead of PMA and use the Shader Graphs/Decal shader at the material.

IndieDoroid

Harald wrote
From the Unity documentation page:
"A Decal Projector component must use a Material with the Decal Shader Graph assigned (Shader Graphs/Decal)."

So using any other shaders is basically not supported. If you want to use a SkeletonRenderer, you could export the atlas using straight alpha workflow instead of PMA and use the Shader Graphs/Decal shader at the material.

Ah sorry for not clarifying. It made total sense in my head while typing it up. :rofl:

What was happening, was that as soon as I applied Unity's Decal Renderer Feature into the Universal Render Pipeline Asset

assets using the Spine Shader disappeared. (Regardless of being a decal or not)

The blue checkerbox was just using the spine shader. It is not a decal .

I'll work on this stuff more next week, so I'll report back if I see more oddities.

But the question still stands. Dbuffer vs Screen Space. Should Spine users choose one over the other for performance? 🙂

Thanks again!

Harald

Ah, thanks for the clarification.

IndieDoroid wrote
But the question still stands. Dbuffer vs Screen Space. Should Spine users choose one over the other for performance? 🙂

If all Spine skeletons disappear when setting the decal renderer setting to DBuffer, it would make little sense to use it even if performance increased, would it? :nerd:

Joking aside, if skeletons disappear in mode DBuffer you could have a test with Spine shaders writing to the depth buffer (ZWrite enabled).

In general you should never set culling mode to Back or Front at any skeleton renderers, since both front and back faces need to be rendered.

IndieDoroid

Harald wrote
Ah, thanks for the clarification.

IndieDoroid wrote
But the question still stands. Dbuffer vs Screen Space. Should Spine users choose one over the other for performance? 🙂

If all Spine skeletons disappear when setting the decal renderer setting to DBuffer, it would make little sense to use it even if performance increased, would it? :nerd:

Joking aside, if skeletons disappear in mode DBuffer you could have a test with Spine shaders writing to the depth buffer (ZWrite enabled).

Lol dang it

sorry the screenshots aren't clear either. :lol:

This one is DBuffer. And the spine object only appears if I set the queue above 50 🙂

Harald wrote
In general you should never set culling mode to Back or Front at any skeleton renderers, since both front and back faces need to be rendered.

Ok got it. So basicaly DBuffer and Screen Space are the same performance impact for Spine related assets. And I'll remember to not set culling mode to Back or Front ! Thanks for the help Harald! 8)

Harald

Basically as with any performance questions, the only way to answer this is to test (1) your actual use-case scenario on (2) the target devices. Any other answer is unfortunately just not a valid one, intuitive guesswork might just turn out incorrect. Here admittedly I don't even have enough insight yet to even guess.

IndieDoroid

Harald wrote
Basically as with any performance questions, the only way to answer this is to test (1) your actual use-case scenario on (2) the target devices. Any other answer is unfortunately just not a valid one, intuitive guesswork might just turn out incorrect. Here admittedly I don't even have enough insight yet to even guess.

Hmm ok ok. I guess I won't be finding out until much much much later into production. :rofl:

I'll keep you posted 🙂

Harald

IndieDoroid wrote
I guess I won't be finding out until much much much later into production.

I just noticed that "test your actual use-case scenario" was easy to misunderstand. What I meant by that is to create a quick test setup which is similar to your later real-world scenario. Anyway, delaying this decision until late in production might not be much of a problem if you only need to flip one switch in the settings and don't have many followup changes to make.

I'll keep you posted

Thanks in advance, it's always helpful to see real-world use case reports!