Related Discussions
...

Davide 好的，非常感谢。有结果了请通知我

    10 jours plus tard

    This is a limitation of Godot. They currently do not implement batching for 2D triangle meshes.

    orgs/godotengineprojects/33?pane=issue&itemId=20224421

    We've worked around this as best as possible, by using meshes explicitely:
    EsotericSoftware/spine-runtimesblob/4.2/spine-godot/spine_godot/SpineSprite.cpp#L173

    However, that does not help with draw calls. It does improve performance compared to canvas_item_add_triangle_array though.

    Note however, that Godot 4+ uses Vulkan as the default renderer. Batching is much less impactful there, which is one of the reasons it hasn't been implemented by Godot yet.

      Mario 我了解了，其实我不久前才购买了spinePro，虽然我很希望在项目中使用这个便捷的工具，但godot似乎还不太成熟。
      所以这是否意味着，如果我希望大规模使用spine作为游戏中的角色，最好使用unity引擎，或使用godot的原生骨骼工具+图集的方式来实现，这两种方案似乎都可以解决batch的问题。

        Mario 等等，可能刚刚我没有完全理解你的描述，你的意思是不是说，我可以忽略掉合批这个概念去使用godot-spine，不能像对待传统引擎的思路去对待godot，因为它的底层渲染逻辑很特殊，drawcall对它的影响很小。是这个意思吗？我可以忽略drawcall这个概念，在godot中大量使用spine动画

          I think Godot is mature enough for production use, including on mobile. Vulkan makes batching mostly irrelevant.

          I suggest you setup a simple scene with multiple SpineSprite nodes that's similar to your target complexity and test performance on devices you care about.

            Mario 我测试了一下，在godot里跑200个spine和unity里跑200个合批的spine，最后unity的FPS非常稳定，godot在100个的时候i5处理器就已经扛不住了，200个时drawcall达到了3000+，i7也抗不住了。但unity跑到300个i5都能稳定在60fps（unity甚至是在3D空间里）。
            其实godot无法让多个spine合批这个事儿还勉强能接收。但godot甚至无法让1个spine文件只使用1个drawcall就太糟糕了，如果godot能让1个spine只使用1个drawcall绘制，200个spine控制在200dc，应该也不会太卡，现在一个spineSprite就要耗费20-30个dc，很难大规模使用

              Well, I suppose there's your answer. Did you use a release build for benchmarking? And what rendering profile did you use? Make sure to use Vulkan.

              We have no control over Godot itself, so we can't make things faster on our end. If Unity fits your needs, go for it. Our spine-unity runtime is as capable as our spine-godot runtime, if not more.