Harald wrote

We just released a fix for the Sprite shader GUI changing it to an int value, you can then set it to 550 to get the desired render queue 3000. We have also added a preview line below showing your what the current value is set to.

Awesome, this is definitely what I was looking for. I really struggled to find information on rendering queues yesterday after looking into it for about an hour, so your help was perfectly on time!

Thanks a ton, as always, you're my hero. Hopefully this will be my last problem with my URP and Spine environment Definitely looking forward to being less of a bother for you guys! Thanks again!

Nooo, spoke too soon. Changing the render queue offset broke my Depth of Field effect, which makes sense. I'll play around with the offset to find a threshold that allows for both this effect and lets objects be rendered as intended. In the event that this doesn't work, I may just have to give my Sprite assets a ZWrite feature or change their render queue values.

Okay, I found that adding the asset to the Background queue (setting the offset below -450), seemed to work. The asset is still able to go behind other Sprite and 3D GameObjects in the World Space and the Depth of Field effect still works without needing to be adjusted. I'm not sure how fragile this setup is, but at least it's working for the moment.

If you are curious, this is a dropbox link to a GIF that is a proof of concept of what I was trying to make: https://www.dropbox.com/s/qbvut4n0bi9vt5n/movie.gif?dl=0

...Maybe that might help put my madness into perspective? Hmm... Doubtful.

Harald wrote

Could you show screenshots of your current Material settings at both the Sprite mid-background and the Spine skeletons?

Definitely, the first image is my material for my Spine skeletons, I am using the most recent Spine-Unity and URP Shaders packages:
The Sprite background is currently Unity's Sprites-Default Material. To err on the side that this is still useful information, here are the material and shader files respectively: I might soon be updating the background to a new Sprite shader (or to a Spine asset) so that my background can have normals that better interact with the scene's lighting. Either way, these are my current settings.

This is most likely overkill, but here is also my MeshRenderer and SkeletonAnimation settings:

Harald wrote

So the solution would be to adjust the render queue to draw the Skeletons later, or to draw the Sprite mid-background earlier.

Okay, gotcha. I will most likely look into this today.

Harald wrote

Could you provide a comparison shot of what it should look like?

Of course! The following is a better image with labels. Here the 3D background is getting rendered through the Spine assets, ignoring the purple Sprite background that lies between them.
The next image is a more expected result. Despite the Spine assets still not rendering the purple Sprite background behind them, it is nonetheless more true to what the expected result ought to be, as the 3D world is isn't seen behind them (even though it has been removed in this image to yield a more accurate result).

Unfortunately, I tried removing the opacity on each Spine and using another technique for highlighting a Spine Skeleton, but upon closer inspection, the 3D world is still rendered behind the assets on other points where opacity is present, again ignoring the purple Sprite background.In this last image you can see a vague green outline of the 3D world behind the asset even though the Spine's opacity is set to 1.

I have some ideas how to 'band-aid' the problem, but I would love some pointers if I am missing something simple.

Harald wrote

No, the dot product is zero when the angle is 90 degrees. This is intended, this is how lighting flat surfaces works with Lambert shading (and also with more complex models) - light is dimmed to black when the light angle gets parallel to the surface.

That's why I asked why you want the light to affect the sprite from the back. Now I guess what you want is that light affects the model depending on distance and independent of the angle?

[...]

Perhaps you should think about what you really want your light to behave like, how your light should affect your Skeleton.
.. or not, if it looks good, it's good .

Yea, I think you might be right that I need to do some more thinking about what effect I'm looking for. At the moment I think I want to do a hybrid of Lambert shading and radial distance influencing the lighting (independent of the angle). Of course it sounds odd, but I definitely want the asset to be still lit when it is orthogonal to the light source while additionally it would still be nice to have the normals be influenced by the light's angle. Perhaps some weighted addition could solve this in the future, but I definitely will need to do some experimenting first.

However, regardless of lighting, an issue popped up today when I added opacity to my URP/Spine/Sprite shaded asset. Essentially the 3D background behind the Sprite background became visible through the asset, seen here:
The asset also has Write to Depth enabled with a Z Spacing of -0.001 (I wanted to create a Depth of Field effect in the scene as well). Not quite sure what logical errors I might be making to make the renderer skip the sprite background, but maybe I need to enable the ZWrite on all my Sprites in the scene? I'll look into it over the weekend, but either way, sorry for the hassle again.. :tear:

Awesome! I'll download it and give it a look! As always, you're the best! :grinteeth:

Harald wrote

Please check your Deph Alpha Cutoff value. Most likely you left it at the default 0.5 which explains your problem.

Oh! Okay oops, that definitely solved one problem.

The other is still that the asset doesn't appear to be be 50% opaque when its alpha channel is set. Instead alpha/A seems to effect the grayness of an asset rather than its opacity.

Using shader Universal Render Pipeline/Spine/Sprite at an opacity of 1

Using shader Universal Render Pipeline/Spine/Sprite at an opacity of 0.3

A more expected result using shader Spine/Sprite/Unlit at an opacity of 0.3

Hello again! Of course, sorry to bother, but I am having trouble with utilizing the following code:

// set spine opacity
Transform spineTransform = transform.Find("Spine GameObject");
Spine.Skeleton skeleton = spineTransform.GetComponent<SkeletonAnimation>().skeleton;
skeleton.A = 0.5f;

...with the shader Universal Render Pipeline/Spine/Sprite. The opacity appears completely invisible with a value below ₀.5f, and only appears slightly darkened with values above ₀.5f; I also have the Write to Depth enabled if that changes anything.

I don't _think I am doing anything wrong as the code worked fine before changing the shaders and upgrading to URP. It appears to be some sort of internal error, or I am misusing the property.

Harald wrote

And in case you mean that: You currently cannot assign a normalmap attachment image in the Spine Editor. This is only done in the spine-unity runtime side.

Oh! Okay, this is very interesting. I will try to figure out how to create correct maps for my Spine assets using the Universal Render Pipeline/Spine/Sprite shader. Thanks for the clarification! I've looked at the Stretchyman Material a few times in the past, but I struggled a little on how to generate the .png file for each map. I'll look into it again though with my fingers crossed.

Harald wrote

Hmm, this is strange, I implemented it in a way which should light it as your first image shows, even when the light is placed behind (which was the whole point).

Ah. Sorry, I completely misread what you said in your previous post! My apologies! Yes, after I implemented what you suggested it worked fine for Skeleton Lit. HUGE thanks! There was one hiccup with the dot product getting zeroed out when the normal and lightDir were on the same Z-Axis, which made the object black/unlit. Since I will probably be only using point lights in my project, I changed the function to:

half3 LightingLambertLitFromBehind(half3 lightColor, half3 lightDir, half3 normal)
{
   half mag1 = length(normal);
   half mag2 = length(lightDir);

   return lightColor * saturate(mag1 * mag2);
}

... which produced the desired effect. I'm not entirely sure what each variable does nor have I ever worked in HLSL, but it seemed to work for the time being. Hoping this code doesn't cause the world to catch on fire! :grinteeth:

Using specifically the Stretchyman's Material in the URP 3D Shaders example scene along with the Sprite shader, I see what you mean with the asset looking a little strange while Lit From Behind is enabled. The normalmap and its lighting definitely seems a little off when the light is behind the asset. For the time being I think I will stick with the Skeleton Lit shader in the URP/Spine package without using a normal or an emission map. Once I figure out how to incorporate the Sprite shader with the attached maps/textures, I will revisit the Sprite shader you have provided and see if there is an alternative solution to the lighting that yields a symmetrical result if the asset has Lit From Behind enabled.

I just tested it all out, depth of field, 3D lighting with 2D assets, URP and Spine, bam! It really works wonderfully for the time being. Thank you so, so much again, Harald, I really, really am grateful for all your help. If you are ever in Los Angeles, let me know and I will gladly buy you dinner! :grinteeth:

Harald wrote

What exactly do you have problems with? You create normal and emission maps in the editor of your choice based on the normal atlas texture (with Photoshop, Substance Alchemist, etc.) and assign the textures to the slot in the Material Inspector.

Okay, I'll give this a try soon. The main problem is simply that I don't know how to attach those maps to my Spine assets, but truthfully, I haven't done the research on it yet. I'll try attaching them and reading some tutorials on it and then maybe get back to you when I succeed/fail. That might be a post for another problem later down the line.

Harald wrote

This feature has just been completed, all SkeletonLit shaders now provide a Double Sided Lighting parameter to properly light the back-face as well.

I downloaded the new version and reinstalled the URP/LWRP packages and gave it a try. Awesome work! Again, I super appreciate you doing all of this to help me out. However... tragically, I think we miscommunicated. The Lit From Behind functionality I poorly described aimed to light the front of the asset where the light was behind it.

In this first image, the asset is lit as intended with the light in front of the asset.

In this second image, the asset is unlit with the light behind the asset.

Sadly, lighting the asset from the other side isn't the desired effect, instead I wanted the asset to be lit as if the light was cast in the front of the asset as seen in the first picture. The reason behind this is that the world is 3D with the characters being 2D. The characters can traverse the X and Z axis but their Spine's are always orthogonal to the Camera View. As a result, I wanted to implement a lighting system that applied in a unique way for these characters.

You've been such an amazing help, Harald, I completely understand if this exceeds the scope of the original post, and I will do my best to solve this problem on my own after I acquire further shader knowledge. Either way, again huge thanks.

Thanks for getting back to me, Harald! Unfortunately, I still couldn't figure this out. Toggling Advanced - Add Normals or Advanced - Solve Tangents along with Fixed Normals did not manage to solve the issue of the lighting only effecting assets focused around where the X-axis equals 0.

I'm going to try attaching a normal map to my assets and configuring it from there to see if they function as intended then. I'll edit this post once I have updated the scene.

Actually... are there resources for where I can find how to attach Normals and Emission Maps?

Gotcha.

Harald wrote

Did you perhaps not setup the Fixed Normal settings as mentioned above?

Maybe not, I had the Fixed Normal setting checked, but I didn't generate a normal map. Is that generated in Photoshop? (Also does the same apply to the emission map as well?) I also couldn't figure out how to make the Fixed Normal Space be Camera Space, but I'm guessing View-Space the equivalent?

As soon as I used a different Spine asset that had the Normal Map configured, the lighting started to work in 3D space properly for the Universal Render Pipeline/Spine/Sprite shader.

Harald wrote

I will add functionality to the shaders via a bool parameter. A new issue ticket is available here, I will let you know once it's done

Oh wow! Thanks! I was going to look into how to do that today but, okay, huge thanks! I'm excited to hear about any updates!

Harald wrote

Why do you think it's not suitable for navigating the 3D world?

So far I haven't found a way to make the Universal Rendering Pipeline/Spine/Sprite shader have any other Lighting Mode than Lit Universal; the other Lighting Modes cause the shader to fail and turn resultantly pink. I've only found the Universal Rendering Pipeline/Spine/Skeleton Lit to work with a local 3D point light. I'll do some more research on it today to see if I am missing a step.

Harald wrote

So the way to go is to not use the 2D renderer when you have a mixed 2D & 3D scene and want to light them in with true 3D lights.

Got it. I will not use a 2D renderer.

Harald wrote

Do you want to rotate the skeleton by 180 degrees?

Sorry, I think we misunderstood each other. I want a 3D light to affect the front of a Spine on either side of the Z-axis.

Here the light illuminates the front of the Spine

Here the light vanishes behind the spine, the front unlit

The desired effect would include the lighting in the first image while the light is on either side of the Spine. Otherwise, I will also try your recommendation.

It appears Universal Render Pipeline/Spine/Sprite does not work for me because I plan to have my Spine assets navigate in a 3D world. The lighting and visual effects seem to work best in tandem with the shader Universal Render Pipeline/Spine/Skeleton Lit

Thanks for the tips. Definitely sorry Harald for causing the headache, I will absolutely spend more time with URP. A lot of this has been really confusing for me since my project intends to be a hybrid of both 3D and 2D, somewhat of a Paper Mario or Don't Starve look, if you are familiar with either of those games.

If I am using Spine and 2D sprites along the side of 3D assets, is there not a combination of shaders and rendering settings that allows me to have every asset affected in a similar manner enabling a depth of field effect and general lighting?

Honestly, I think I got it working through rereading the URP installation page and re-downloading the Spine-URP package. A new, yet similar question popped up: using the shader "URP/Spine/Skeleton Lit" how can I make it so a 3D light effects the Spine on both sides of the Z-axis?

Alright, I tried again last night, and I still haven't been able to achieve the desired effect of Depth of Field with 3D lighting for my 2D Spine assets. Maybe I missed a step somewhere?

• Started with an existing project without URP, then added it in

• I then installed Esoteric Software's URP support packages

• Changed my asset's shader to one that had a "depth to write" option and then edited the z-spacing

Unfortunately, I still haven't figured it out quite yet. Maybe there's a particular URP Spine Shader you recommend for achieving this effect? I was able to accomplish Depth of Field or 3D lighting, but there doesn't seem to be a shader that allows for both effects to occur simultaneously.

Thanks, Harald, for the amazing response time as always! Sorry to get back to you so slowly!

I haven't gotten around to testing your recommendation yet. I might give it a few more days before I go down this rabbit hole again. I'll keep you posted if it works out or if I run into any more problems.

Hello! I was having some trouble getting a depth of field effect on my Spine assets. I wanted the camera to blur out spine assets far in the distance, while the ones up close remained in focus. I was wondering if there was an easy fix to this using URP or if I should look into other shaders that better address Spine assets and this desired effect.

Here is an example image. The two cubes are aligned with the Spine assets, yet only the front cube is in focus while the adjacent Spine is out of focus.