@TheSunOfMan sure, we do accept pull requests on the spine-runtimes repo, provided we get a signed contributor license agreement. Sorry for the red tape, but it allows us to publish contributions under our license. We've had quite a few great PRs over the years, including the initial spine-godot runtime (which was then heavily rewritten).
Every frame, the bones will be posed, then attachment vertices will be calculated based on the bone poses. That's the same for either 2D or 3D. Have a look at
Skeleton::updateWorldTransform(),Bone::update()etc. It's all extremely light weight calculations and usually not the case for any performance issues, especially given that spine-godot is based on spine-cpp, our C++ runtime.The Spine runtime directly talks to
VisualServerandRenderServerfor best performance. Adding (or removing) a z-coordinate per vertex will make absolutely not difference in terms of performance.
As I said earlier, the performance issue you are seeing is due to your usage of viewports. spine-godot itself is very fast, both on the CPU and GPU side.
As for simply switching between Node2D and Node3D, again, it's not that simple. Godot's internal rendering architecture distinguishes between 2D (Canvas) and 3D rendering (spatials). We need an entirely new rendering backend for 3D support. There is also the issue of transform coordinate spaces for methods that give you skeleton -> world transforms, or vice versa. Finally, both SpineSprite and SpineMesh2D are subclasses of Node2D, which does not have the same interface as Node3D. We can't thus just swap out the base class and call it a day. For supporting both 2D and 3D, SpineSprite's functionality needs to be taken apart, putting common pieces into a base class, then have separate SpineSprite and SpineSprite3D classes. All while keeping compatibility with existing projects.
As I said, if it was easy, we'd already have done it. It's not. It's a lot of work, for which we currently don't have the cycles.