1. SpineSprites are only Node2D:
   Currently, the SpineSprite node in the spine-godot runtime is designed to work with 2D scenes and inherits from Node2D. There is no native support for Sprite3D at this time. However, you can use a workaround by creating a custom node that handles 3D transformations and rendering. This involves manually updating the SpineSprite's position and rotation to match a 3D node's transform.

2. Pixel Grid Function:
   The "Pixel grid" function in Spine is not directly supported in Godot through the spine-godot runtime. This feature would require a custom shader or material to replicate the pixel grid effect. You can create a custom shader in Godot to achieve this effect by snapping the positions of the vertices to a pixel grid.

3. Lower FPS for Animations:
   To achieve a lower frame rate for animations, such as 12fps, you can manually control the update rate of the SpineSprite. Set the Update Mode to Manual and update the skeleton at your desired frame rate by calling SpineSprite.update_skeleton() in a custom _process(delta) function. This allows you to control the exact timing of the animation updates.

extends SpineSprite

var frame_time = 1.0 / 12.0  # 12 fps
var accumulator = 0.0

func _process(delta):
    accumulator += delta
    if accumulator >= frame_time:
        update_skeleton()
        accumulator -= frame_time

These features are not currently supported natively in the spine-godot runtime, and there is no official timeline for their implementation. However, the provided workarounds should help you achieve the desired functionality in your project.

bitsalive 2) You added the cool "Pixel grid" function to Spine:
...for working with pixelart games -> doesn't work in Godot. Are you missing a custom shader/material or something?

Please note that Pixelgrid is a viewport rendering option of the Spine Editor only (like Smoothing):
"When checked, the viewport rendering is rasterized to simulate pixel art."
It is not a setting which is exported with the skeleton, or which any of the Spine runtimes supports directly.

@bitsalive See this issue ticket:
EsotericSoftware/spine-runtimes2135

You can check out the road map here:
http://esotericsoftware.com/spine-roadmap

@bitsalive You might also find related forum threads with additional info like this one:
https://esotericsoftware.com/forum/d/23907-is-it-possible-to-use-spine2d-in-the-godot-3d-scene

Spine's pixel grid first renders the skeleton to a buffer at full resolution, then renders the buffer using the viewport camera. This causes rasterization to happen when rendering to the buffer. For example, when an image is rotated and you draw it scaled up, you'll see the pixels are rotated. By drawing it to the buffer first, the buffer is scaled up and the buffer's pixels are larger but not rotated.

(I'll have to let our other staff field your Godot questions! They are likely enjoying their weekend and will respond Monday.)

I'm not aware of anyone trying to reproduce the editor pixel grid functionality in Godot. You can get the bounding box of the skeleton in its coordinate system via SpineSprite.get_skeleton().get_bounds(). Depending on your scene hierarchy, you might have to transform those bounds further, i.e. by the SpineSprite and anything else that may modify the on-screen location of the sprite, like a camera system. That's not something we can anticipate or cover via our API.

As for consoles, I'm working on turning spine-godot into an extension. W4 Games has indicated interest in that with regards to consoles as well, so there's a clear path forward plus safety for businesses targeting consoles with Godot via W4 Games. We ourselves do not have access to any console SDKs, so we won't be able to give support for that.

bitsalive So to get the correct rasterization you need to know the input size of the original image, is that correct?

Spine uses a 2048x2048 buffer. If your skeleton is larger than that (at 100% zoom), it will be cut off. You can see this in the editor by moving part of your skeleton far away with pixel grid enabled.

When you say you're working to turn it into an extension, do you mean like an addon that works with the default version of Godot (so no custom build required?)

Yes, as a GDExtension.

Is there any ETA for the extension?

When it's done Sadly, it's a ton of work to switch over to GDExtension, as the API is incompatible with the Godot module API.

And... any love for Sprite3D/SpineSprite3d? :-)

When the conversion to a GDExtension is done.

The extension is complete, with two caveats: no support for AnimationPlayer, and specifying animation mixes in the inspector can't be done as nicely as with our custom Godot build. Other than that it's fully functional.

I still have to fix up the automated builds so we also publish binaries for all platforms. Once its ready, we'll post on the blog, on here on the forum, and send out an email.

Our you subscribe to the issue here:
EsotericSoftware/spine-runtimes2651

When you say, no support for AnimationPlayer- do you mean the ability to use Godot AnimationPlayer Editor when creating the Spine Animation Track, mentioned here in the docs:
https://en.esotericsoftware.com/spine-godot#SpineAnimationTrack

Exactly. No support for Spine Animation Track in the GDExtension version of spine-godot

Are animation mixes working in general? Just not as comfy as in the build version?

Yes, they work either in the inspector by filling in the general purpose array UI (which is super uncomfortable), or via a script attached to your node that sets them on node initialization via the standard Spine API.

Also, is a Sprite3D Version supported yet?

Nope, that will come once I have finished the next point.

Is there a version to download somewhere? Maybe i just didn't find it. Or do we wait for the automated builds?

I'm currently working on setting up the automated builds. You can compile it yourself from source by:

git clone https://github.com/esotericsoftware/spine-runtimes
cd spine-runtimes/spine-godot
./build/setup-extension.sh 4.3-stable true
scons target=editor

This will clone the Spine Runtimes, setup everything so the extension can be build, and finally invokes SCons to build the extension for the platform you are on. The resulting binary will beplaced in examples-v4-extension/bin, along with the spine_godot_extension.gdextension file, which tells Godot where to find the shared libraries for the extension for each platform.

I've only tested on macOS so far, and only editor builds. YMMV. That's why we'll provide automated builds

One more caveat: it's currently not possible to generate nice, idiomatic C# bindings for GDExtensions. Instead, you'll have to go through the ClassDB and Object APIs provided by Godot. It's basically string-based, untyped, reflection.