Nate Yes Affinity does have clipping masks. however, Spine doesn't handle clipping masks for use cases like animating a pupil moving inside an eye, without going over the face, or without going over the eye lashes. you can work around this with a clipping attachment, but that requires setting up a mesh and isn't 1:1 to the shape you need depending on the use case.

another example would be a scrolling texture over a certain part of a weapon. it'd be really easy to pull that off with a clipping mask

thanks for the response, it does work for its intended use, i started using it to easily paste some patterns over my character. i still wish there was a tag to make an image work as an active clipping mask in Spine. currently when working with things like eyes i have to split eye outlines on a separate layer above the pupils. For the most part it works, but it isn't perfect.

i've recently been switching to PSD imports for my spine projects (its a life saver). however, i don't understand how the [overlay] tag works. the docs say it works as a clipping mask for all underlying layers, but when i view it in Spine it just removes any layers I put under it.
for example i want to have an eye overlay with pupils under them. i'm not a big fan of clipping attachments for handling these

if it helps, i'm using affinity designer 2. everything else exports properly, and when viewing the exported PSD everything looks normal. it also loads into spine just fine

woohoo! i was watching it be solved in realtime. building with github actions is typically a cleaner solution for me

Mario

i accidentally built Godot 4.4 from the latest commit on the master branch from the Godot repo (woops) however it did successfully build. i also tried to run the spine Github Action again, and got the same errors and results for only windows builds.

here's my vanilla Godot scons build logs:

(i tbh just copied that from the console, i have no idea where else to get the logs as no file was generated)

Mario
oh it's all good. i realized after looking at the workflow .yml files you guys provide on the runtime repo, there's a whole bunch of ENV variables in there, and i decided to try putting my own PCK env variable in there (using secrets ofc) and it worked!

Mario if I want to compile with a PCK encryption key on Godot, do I have to build the export templates locally? i assume i would because the Godot docs warn "This will not work if you use official, precompiled export templates. It is absolutely required to compile your own export templates to use PCK encryption."

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.

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.

the thing that fixed the nuget problems for me was opening visual studio (not vscode) and clearing nuget cache in settings. i don't have a nuget package manager, but i'm sure it has the same thing. after that try launching your project then editting the c# script

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)

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?