We're happy to announce that our spine-godot runtime now supports programming using the C# language! Learn more in our blog post.

Edit: Also be sure not to miss our second blog post about Setting up spine-godot with C#.

Alyria Skins are supported in Godot, but only if they're set up in the Spine editor, then exported and included in the texture atlas. In Unity with attachment API, you can swap individual sprites, create runtime only skins and even repack the texture atlas on the fly. No additional re-export or setup from Spine necessary. This is very handy if you have hundreds of customization options for a couple dozen skeletons.

Mario Web and mobile for C# are currently unsupported in Godot 4. They're waiting for upstream support in .NET 8 sometime next year most likely. For GDExtension, since nothing is specified, the assumption would be that support is equal to engine modules. I've created an issue for docs improvement in this regard:godotengine/godot-docs7685

The reason to use internal vertices is to fight against the texture distortions inherent to realtime mesh rendering!

Here's what I mean: in that first image, the vertices are helpfully organized into squares/quads. Quads are great; they're easier to think about and work with in many cases. However, a 3D (or 2D!) mesh cannot be represented with quads, to the GPU it's always triangles.

So, for each of those quads, there will be a hidden edge down the middle splitting it into two equally sized triangles. When you curve or bend that arm, those squares will get squished down to trapezoids, and one of those triangles will be much small than the other! Since at rest both triangles had the same number of texture pixels, this causes a distortion. If the entire arm is curved, then a noticeable sawtooth pattern will emerge.

Here's an example I pulled out of a web search:

In that image, picture 1 shows this kind of distortion in action. Picture 2 shows what an undistorted quad should be expected to look like, but which isn't trivial to achieve with realtime techniques.

So, how do you stop this from happening? One way is to increase the number of segments; the apparent curvature of any individual segment will drop. Another is to add internal vertices, which will chop a long, badly distorted quad into several stacked, individually less distorted quads.

However, in those cases, the distortion still remains, just reduced. That might be enough for many tasks, and you have to balance the pain-in-the-butt factor (and on some platforms, performance/memory cost) of adding more vertices to the mesh; weighting it will be more fiddly and take longer. Knowing when its worth the time to fix and when you can get away with terrible rigging sins is a bit of an art form, but getting good at it will let you work much more efficiently.

However, we can actually do a bit better, here! If you look at that checkerboard image again, you'll notice that at every edge, including the internal edge from corner to corner, the black squares are evenly spaced from one another. What that tells you is that pixels on or very close to a triangle edge behave reliably, they're protected... and we can take advantage of that.

Basically, lay down additional edges around any details you want to preserve. Don't bother placing them on places nobody will notice, such as within a section with flat colours. Here's an example from my current project:

While this isn't for quite the same sort of bendy tube shape it should help illustrate the thought process. On each outside edge of the calf I have vertices inside and outside, closely wrapped to the shadows/lineart in the texture. That lets me carefully control how the width of the lineart changes during animation, and hides all the distortion artifacts inside areas of flat colour where they won't be seen. I also do the same thing on the horizontal around the hem of the pants and the top of the sock since those are details I want to keep control of. You'll notice a line of verts down the middle; this wouldn't help if I were bending the calf side to side like your examples, but the actual use case here is a fake 3D tilt effect:

Arguably every middle vert above the pant hem is superfluous since it's flat shaded there. That's mostly there out of habit from 3D modelling where the consistency helps the workflow... but if I added any internal detail needed for the tilt I'd need them to continue the effect upwards, and it didn't cost me much.

So... to sum up: if the distortion effect isn't going to be a problem (won't be seen, won't be bent too hard, isn't important enough to burn art hours on, etc) then just go for the simple and straightforward ribbon of quads and save yourself a ton of time. Honestly, I frequently err on the side of perfectionism when "good enough" is... well, good enough! However, if it's an important part of the rig, or if you need a huge range of motion, or if the image has a very noticeable pattern that highlights any distortion (crosshatched shadows, for instance) then additional vertices thoughtfully placed can help a ton.

As for "using the least vertices you can"... honestly, in most cases, don't worry about it. There are times when it matters (if you're rendering a thousand of the same character at once, for instance), and platforms that are more limited; If you're deploying to mobile (which I haven't done much work with) triangle/vertex count can still matter. Even so, modern phones are powerful machines with impressive GPUs; we're long past the days where adding another hundred triangles was a big deal. If you're deploying to desktop, any modern machine is going to chew through an obscene number of vertices/triangles per second; modern GPUs pass vertices through the same processors that handle pixels, and your screen has a LOT of pixels. Most spine rigs aren't going to come near the mesh complexity of a typical 3D asset.

As long as you aren't going overboard vertex count is rarely going to be an issue, and usually the problem it causes is creating more work for you!