It's probably because there are too many viewports; one for each SpineSprite.
[Godot] 4.2.1 + Spine = huge performance issues
You might think the isssue is with animation itself. So we did tests with sample Spine animation. Just one Spine animation in simple 2D takes almost 100% GPU.
The same computer running Dota
Something is not right with Godot version supporting Spine
- Düzenlendi
SilverStraw We have tried different approach. We did test with 5 active animations and 5 viewports - put on 100 meshes recycling 100 times the same animations. We can achieve more than 100 FPS in that way. Still, power of GPU needed for 5 skeleton animations is ridiculous.
Test is done on different PC now.
Worth to mention, we use 3D hack mentioned on that forum (Mesh3D + Texture from SubViewport)
This is the problem. This is a very bad way to render anything. I'll eventually get to adding a SpineSprite3D. I'm afraid other things currently have priority.
- Düzenlendi
#1
Please, please do it. Should be extremely simple to do that (I mean replace Node2D with Node3D)
#2
That is not explaining why pure Spine sample on 2D scene takes 100% GPU of GeForce 1060
The reason of 100% GPU usage is unlocked FPS amount.
It would be nice from Esoteric side to allow unlocking FPS without killing performance.
BorysBe Please, please do it. Should be extremely simple to do that (I mean replace Node2D with Node3D)
If it was as simple as that, we'd already have done it.
That is not explaining why pure Spine sample on 2D scene takes 100% GPU of GeForce 1060
If you disable vsync, then yes, your CPU and possibly GPU usage will go to 100%. That is not a Spine related issue, that's simply what disabling vsync will do to any app, be it Godot based or a simple OpenGL/DirectX/Metal/Vulkan app that just clears the screen.
Mario I have some concerns because I do not know how Spine in Godot works, not because I wanted to be impolite. At least it was not my intention earlier.
Try to understand what is happening in background
- what kind of calculation is executed by Spine library every frame? Is it possible that we do some redundant calculations which results is the same by 10 frames in a row and we could cache last result?
- Is Spine library using Godot objects like Node2D? Flat mesh in 3D space with Node3D instead of Node2D would have only Z-coordinate constant. There is no need to do any additional calculation. I don't understand what makes things so hard. Not saying that it is easy to do. Just saying don't see good reason to things not being simply.
TheSunOfMan make it open source
Can't you fork the runtime repo and add whatever?
- Düzenlendi
It is not open source, but I can see it is available to view.
EsotericSoftware/spine-runtimesblob/4.2-beta/spine-godot/spine_godot/SpineSprite.cpp
I will ask some employee to do that for me 
edit:
actually that seems to be more accurate
EsotericSoftware/spine-runtimesblob/4.2-beta/spine-godot/spine_godot/docs/SpineSprite.xml
@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.
That is not explaining why pure Spine sample on 2D scene takes 100% GPU of GeForce 1060
A quick note: when rendering in any game toolkit / software is not limited by vsync or something else then it runs as fast as possible. If I modify the Spine editor to do this, it renders at over 3600 frames per second. With a simpler application I see over 8200 FPS. Rendering so fast naturally uses a lot CPU and GPU.
2 ay sonra
Is there any workaround? Or recommended way to use spine animations in 3d scenes?
There is no workaround until we implement a 3D SpineSprite equivalent.