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 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