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:
Nemaš dopuštenje za pregledavanje privit(a)ka dodan(og)ih postu.
Avatar
IndieDoroid
  • Postovi: 250

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.
Avatar
Harald

Harri
  • Postovi: 4110

IndieDoroid

Harald je napisao/la: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!
Avatar
IndieDoroid
  • Postovi: 250

Harald

Ah, thanks for the clarification.
IndieDoroid je napisao/la: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.
Avatar
Harald

Harri
  • Postovi: 4110

IndieDoroid

Harald je napisao/la:Ah, thanks for the clarification.
IndieDoroid je napisao/la: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 :)
04_SpineShader_change_Queue.jpg

Harald je napisao/la: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)
Nemaš dopuštenje za pregledavanje privit(a)ka dodan(og)ih postu.
Avatar
IndieDoroid
  • Postovi: 250

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.
Avatar
Harald

Harri
  • Postovi: 4110

IndieDoroid

Harald je napisao/la: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 :)
Avatar
IndieDoroid
  • Postovi: 250

Harald

IndieDoroid je napisao/la: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!
Avatar
Harald

Harri
  • Postovi: 4110


Natrag na Unity