Shader for receiving shadows (built-in render pipeline)

SoulKarl

So I've found a few topics like this one https://esotericsoftware.com/forum/d/17643-how-to-receive-shadow-from-point-light-or-spot-light that do what I want, but all of them are using one of the scriptable render pipelines.

Older threads tackling this in the built in pipeline recommend Spine/Sprite/Pixel_Lit, which works with the major caveat that there is horrible aliasing on the edge of EVERY piece of the model (which is annoying on the exterior edge, and fully unworkable on any interior shapes like mouths and eyes).

So my question is if there is any current shader I could be using instead in the built-in pipeline to achieve this effect, and if not could I possibly request something like that be made in future updates? Alternatively if there is no possible way for this to exist within the built in pipeline (w/o the drawbacks associated with the current LitPixel method) please let me know so I can just give up on this pipedream lol.

Also, is there any prebuilt billboard shader for spine or is that something else I could also potentially request?

Cheers!

Harald

SoulKarl Older threads tackling this in the built in pipeline recommend Spine/Sprite/Pixel_Lit, which works with the major caveat that there is horrible aliasing on the edge of EVERY piece of the model (which is annoying on the exterior edge, and fully unworkable on any interior shapes like mouths and eyes).

While enabled ZWrite yields your described jagged outline artifacts at the exterior edge, you should not receive any inside the same skeleton where e.g. an eye attachment is overlaid over a face attachment of the same skeleton. Do you have any special setup at your skeleton, such as a SkeletonRenderSeparator component to split the skeleton or similar? If not, could you please send us a minimal Unity project that shows this issue, you can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

So my question is if there is any current shader I could be using instead in the built-in pipeline to achieve this effect, and if not could I possibly request something like that be made in future updates?

We could provide a simple pixel-lit shader which does not write to the Z-buffer.

Also, is there any prebuilt billboard shader for spine or is that something else I could also potentially request?

The problem with supplying billboard shaders is that there are many ways to orient billboards (keep Y upwards, or rotate it parallel to the screen), while at the same time it can be done with a normal script which rotates the GameObject's Transform. As an addition, since it's only vertex deformation, it may need to be combined with every existing shader as well, to cover the same lighting and coloration features. What are your requirements that can't be met with a simple billboard script component?

SoulKarl

Harald What are your requirements that can't be met with a simple billboard script component?

honestly thought a billboard script would be somehow heavier to run than a shader lol. If that is not the case I'll just do that since I agree that's a lot easier 😛

Harald We could provide a simple pixel-lit shader which does not write to the Z-buffer.

this would be great!

I did some more testing and there are two possibilities. However, when testing I now have pieces of the model disappearing completely using this same approach so that's not great (did not happen last time).
-Turning off mipmaps gets rid of the overlap aliasing, but then obviously gets rid of mipmaps which isn't exactly ideal (so it's related to that).
-Also worth noting that the model I'm using has 5 materials associated with it (in the event that is a known thing that would interfere).

Realized I never mentioned that I'm currently using spine-unity-4.1-2022-08-03 in the event this is out of date and that is somehow contributing to potential problems here.

Thanks for the help Harald!

Harald

SoulKarl honestly thought a billboard script would be somehow heavier to run than a shader lol. If that is not the case I'll just do that since I agree that's a lot easier 😛

Basically you move a calculation that is done once per object on the CPU to doing the same calculation repeatedly for each vertex on the GPU. Unless you have very few vertices per object that need to be facing the camera, then using a script to change the Transforms accordingly should be preferable. Of course, it depends whether you're CPU or GPU bound, etc. As always, you only can say for sure if you measure the result on the target device with the actual scenario. It should only be measurable with loads of billboard objects anyway, if at all.

To keep any script Update() overhead minimal, you could just create a single BillboardManager script which holds a list of Transforms which shall be rotated accordingly, then you only have a single script with one Update() or LateUpdate() call. You could use a Billboard script at each GameObject just to add itself to this list of billboards and do nothing else, or use tags for that.

SoulKarl I did some more testing and there are two possibilities. However, when testing I now have pieces of the model disappearing completely using this same approach so that's not great (did not happen last time).

I'm not sure I understand what you mean by that. Which "two possibilities" are you talking about? Do you mean that you assume that one of the two following points causes the issues you see?

-Turning off mipmaps gets rid of the overlap aliasing, but then obviously gets rid of mipmaps which isn't exactly ideal (so it's related to that).

Could you please share some screenshots? Are you sure you have set some Z Spacing other than 0 at your skeleton? In general mipmaps should not change anything in regards to the observed outline aliasing. Did you check your Materials Depth Alpha Cutoff threshold, perhaps it is set to an unfortunate value which triggers at certain mipmap levels? Apart from that, are you sure that the mip level bias at the texture is not modified to be more blurry than it should be?

SoulKarl Realized I never mentioned that I'm currently using spine-unity-4.1-2022-08-03 in the event this is out of date and that is somehow contributing to potential problems here.

In this case I'm afraid that updating the runtime will not resolve the issues you're seeing. Nevertheless, whenever reporting any issues, be sure to update to the latest runtime version first to see whether any bugfix was released in the meantime (and backup your project first to be on the safe side).

Harald

After having a more detailed look at why the Spine/Sprite/Pixel Lit shader always writes to the Z-buffer I've unfortunately remembered the reason why this is not optional: When Z-Write is disabled, the ForwardAdd lighting pass, which is required for additional lights (after the primary light), would let parts (attachments) shine through, which is not acceptable. So the option would be to either have parts shine through from behind and have multiple lights affect the skeleton, or limit lighting to just use the main light. Either of the two options is not really acceptable unfortunately, so I'm afraid we can't provide a pixel-lit shader for the Standard Pipeline which does not write to the Z-buffer.