[Godot] Request for when 3D Spine support is added

Skeir · 2023年10月14日

Before 3D is supported for Spine on Godot I have a small request. I saw someone make a temporary solution for 3D. And I realized I actually enjoy how this feels and looks for my game.

I'm one of the many Unity refugees, and had some issues with 3D Spine skeletons back on Unity. On Unity I was required to add some Z-Depth, but if I wanted to rotate my character in a 3D space I'd have to instead rotate it in 2D space using ScaleX. Using the temporary solution I can rotate the Sprite in 3D space, which felt better both visually and for the 2.5D effect. Having it on a completely flat plane also seemed to improve how it looks when lit and shaded.

Could you add support for being able to render 3D sprites on a plane similar to how it's done in that GitHub issue?

leslie · 2023年10月14日

Busy evaluating whether Spine would fit with my new project and was just about to ask whether SubViewport is our only option to get Spine to render to 3D. I did a quick test with a Sprite3D rendering the viewport and it seemed to work okay but an official Sprite3D-like would be nice.

Mario · 2023年10月17日

SubViewport and SpineSprite3D are different things. For the former, you don't need any additional thing from us. You can simply follow what the user did in the comment on GitHub.

SpineSprite3D will have to work similarily as it did in Unity when it comes to z-fighting. Each attachment would have to be offset slightly on the z-axis to avoid z-fighting. If you do not want this, then the SubViewport solution is the better option.

Skeir · 2023年10月17日

Mario
Is there any way I could make my sprite rotate in 3D space or appear to rotate in 3D space without using ScaleX?

The only thing I can think of right now is inverting the z-offset when the character is 90° through the rotation (aka pretty much invisible to the camera). If the z-offset works how I think it does, then inverting it from a value like 0.01 to -0.01 would make it so when the entire sprite is flipped it'd appear facing the other direction but the draw order would be the normal order you expect.

(also unrelated thank you the NuGet package update fixed my C# issues)

Mario · 2023年10月18日

I'm afraid I'm not quite sure I follow. What is wrong with using ScaleX? That's generally how you should flip a skeleton on the x-axis and retain its drawing order (viewed from the front).

Skeir · 2023年10月18日

Mario
Oh I see the confusion sorry. I'm doing a Paper Mario styled game, and I'm trying to do a gradual rotation instead of an instant flip towards the left or right direction. I've compared side by side with my unity project using the ScaleX for a pseudo rotation effect, and on Godot using the actual plane's Y rotation for the effect. I notice when using actual rotation the effect feels more appealing compared to gradually changing the ScaleX from 1 to -1.

It is a small visual difference, but for my game I was planning on having an attack that uses a sprite spin effect, and when I tried that on Unity I wasn't liking the results when using ScaleX. I could continue using SubViewports for the rest of my game, but I read I believe from you that it would have a big performance hit if more than 10 sprites were on screen.

Mario · 2023年10月19日

Ah, makes sense. I'm not super familiar with spine-unity, so I'm not sure how it solves the attachment draw order problem in 3D. @Harald can you elaborate how you do sort order in 3D in the Unity runtime?

As for SubViewports and performance, I think if you do culling you should be fine performance-wise.

Harald · 2023年10月20日

Skeir I notice when using actual rotation the effect feels more appealing compared to gradually changing the ScaleX from 1 to -1.

Did you just interpolate ScaleX linearly from 1 to -1, or did you use ScaleX = cos(angle)? The latter should look more convincing. Lighting (due to angles) and Z values will still be different to real rotation obviously.

Mario I'm not super familiar with spine-unity, so I'm not sure how it solves the attachment draw order problem in 3D. @Harald can you elaborate how you do sort order in 3D in the Unity runtime?

Actually in spine-unity, when adding z-spacing and rotating the skeleton 180 degrees around the Y axis, the attachment placement order would end up being be incorrect. Like depth order 123 resulting in 321 when viewed from behind. However, when not writing to the Z buffer, the draw order inside the mesh is still the same, draw order 123 still rendering in order 123. Thus unless ZWrite is enabled, the result will look good when rotated, visible attachment order is not inverted.

What users can do to compensate incorrect depth order is to programmatically change the z-spacing from the normal negative value to a positive one once the angle is greater than 90 degrees (and less than 270).

In case I misunderstood the question and it's regarding sorting order of the whole MeshRenderer skeletons inside a scene: Unity let's you change sorting from the default sorting by depth along the camera axis to along a custom user-defined axis (useful for isometric games, using the Y up-axis then). The center (not the origin unfortunately) of the MeshRenderer's Mesh will be used as position for sorting.

Skeir · 2023年10月20日

Harald
Yeah I was linearly changing the scale, I can see how that makes it less convincing now. I'm glad you confirmed I can programatically change the Z spacing after the halfway point. I was worried I couldn't since in Unity it only allows me to change the Z spacing to a negative value in the inspector.

Harald · 2023年10月23日

@Skeir Glad it helped. Sorry that the Inspector Z-Spacing range is a bit misleading. The range was set like this to cover 95% of the use-cases and not confuse the normal user with a [-1, .. ,+1] range. You can safely set it to positive values though, just don't mind that the Inspector behaves differently here.