pvalium I've search and I'ff found some shaders that makes texture always face to camera, but I I haven't been able to get them to work with spine objects.

What problem did these shaders cause when used with Spine skeletons? Perhaps you just need to switch from PMA to Straight alpha atlas export, if the main problem is having dark outlines around attachments.

pvalium Is there any shader or feature in runtimes that prevents this?

Unfortunately there is no official Spine shader available which would provide such functionality.

The question is what would you like the result to be? Should the result look the same as the tilted skeleton, but the depth should be written as if it were upright instead of tilted (based on the skeleton mesh origin)?

If so, are you sure your billboard shaders are not only rotating the object to face the camera, but actually modify depth and "distort" the original depth of the vertices?

In any way, you would normally need to copy an existing shader and modify the vertex shader part so that the vertices are modified accordingly to move them closer to the camera the higher the Y position is. If you have a working billboard shader, you could just copy the vertex shader code over to your new shader and use this vertex shader function as vertex shader.

Another rather simple solution would be to not tilt the skeleton. Instead, you could scale it in Y direction. When not using orthographic projection (and your screenshot looks like it's using perspective projection), this will be incorrect however.

@pvalium If you can share the code of your working billboard shader which does not work with Spine skeletons, and which Spine shader you originally wanted to use, we can help you in more detail.

pvalium But i would like if this can be solved without touching z transform.

As I mentioned above, the perfect solution requires a custom vertex shader. This vertex shader should not uniformly offset your z position at all vertices as it looks from the screenshots, as you could also do the same by simply moving the Transform forward.

The proper solution in the vertex shader would offset only the vertex output coordinates (after transformation). To be precise, it should offset the output z position by a factor dependent on its local input y position. So the higher up the local (object-space) vertex position, the more it should move the output vertex z position forward.

@pvalium I'm sorry to say that we can't provide such a shader feature officially as part of our shader set, since this feature (a) is a very niche use-case and (b) would need to be added at multiple (or all) shaders, including unlit, lit, built-in RP, URP 2D and URP 3D shaders, which adds a lot of clutter to the package.

If you tell me which shader you originally wanted to use, I can perhaps quickly create a modified version of it.

pvalium I use urp lit 3d.
That's not a shader name. Which one of the following shaders are you using:
https://esotericsoftware.com/spine-unity#URP-Shaders---Extension-UPM-Package

pvalium The shader in
https://github.com/Jiaquarium/unity-URP-2.5D-lit-shader
Runs perfect with sprites, but with spine only fails in last commented before.

It runs perfect with Sprites? How? Could you place a Sprite of the same height next to the Spine skeleton with the same shader to show how this works without issues?

@pvalium That is indeed interesting. Could you perhaps send us a minimal Unity project that still shows this? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at why this works with Sprites.

@pvalium Thanks for sending the package. Unfortunately it only contains only half the things we need, you've only included the golem with the custom sprite shader, but not the Spine skeleton seen in the above screenshots.

When I import the spine-unity runtime and use Spineboy from the examples with this custom sprite shader, I could not reproduce the issue you are showing in the screenshots above (that it's tilted backwards and cut-off at nose-level). What I did encounter is a different issue related to zwrite and the depth that the shader seems to be writing, as can be seen below. However, I don't think you meant that you encountered this issue, as I can see nothing of this sort in any screenshots above.

If this is not the issue you meant, please send us a package that contains all relevant parts displayed in the test scene.

pvalium Sorry for the delay in responding! Thank you for sending us the Unity project to reproduce the problem. Harald is currently on vacation and will return on January 8th. He will investigate the problem as soon as he returns, so please wait a while for his response.

@pvalium Thanks for sending the project, and sorry for the long delay! I will get back to you here on the forum soon.

@pvalium The problem shown in your reproduction project is that your 2.5D shader project everything onto a single plane, effectively removing the Z-spacing offset of attachments again.

The fix would be to change the following line in unity-URP-2.5D-lit-shader-main/LitForwardPass.hlsl:

float4 planeOutPos = mul(UNITY_MATRIX_VP, float4(rayStart + rayDir * dist, 1.0));

to

float4 planeOutPos = mul(UNITY_MATRIX_VP, float4(rayStart + rayDir * (dist - IN.positionOS.z), 1.0));

Or if you don't need the shader to write to the depth buffer, instead of the above line in unity-URP-2.5D-lit-shader-main/SpritesLit.shader change the first occurrance of ZWrite On to ZWrite Off. Then you can set Z-Spacing to 0 at the SkeletonAnimation componenet.

@pvalium Anyway, I'm not quite sure however why your screenshots always showed a completely different issue with your skeleton in this posting:
https://esotericsoftware.com/forum/d/25182-render-spine-in-3d-world/10