[godot] Add support for Godot Engine

[lbowers]

Is this no longer happening?

[badlogic]

It is! Just not in the 3.6 release. It's the next runtime we are going to implement. We will likely target Godot 3.0 as it has some promising new features specifically geared towards plugins/extensions.

On Mar 13, 2017 7:22 PM, "Leigh" notifications@github.com wrote:

Is this no longer happening?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/EsotericSoftware/spine-runtimes/issues/728#issuecomment-286197933, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBGblPuZne_CZLm1ml5cEOuQP7sieks5rlYlOgaJpZM4KV4hx .

[lbowers]

That's great to hear!

Appreciate you responding so promptly.

[shahasad78]

Looking forward to seeing this implemented. Will buy a spine license once it works with Godot

[ambethia]

Godot 3.0 alpha1 is out now. ;)

[shahasad78]

I know the Kestrel Moon people have been on the forums trying to enlist help to port Creature to 3.0

[Geequlim]

Here is a module that implemented the spine support for godot. Both godot 2.1 and 3.0 is supported with the spine runtime 3.5.51. https://github.com/GodotExplorer/spine

[millansingh]

Any idea on a timeline for this?

[mjtorn]

@badlogic you added the "ready" label, what's up with that? Is this available somewhere?

[badlogic]

That means it's ready to be worked on. We have not started work on Godot yet.

[mjtorn]

@badlogic thank you very much for replying :) Do you know what kind of issues you may expect? I tried to make the runtime above more API-compliant with Godot's AnimationPlayer API, but there are some things that are really tough. The spine-c API looks nothing like Godot's, so I'll love you forever if you find a way to make Spine a transparent drop-in replacement ;)

[badlogic]

I haven't looked into issues concerning Godot yet, so I'm afraid I have no input in the Animationsplayer API and it's compatibility with Spine's API. What I can say is that we won't change Spine's API for Godot.

On Mon, Apr 23, 2018, 16:38 Markus Törnqvist notifications@github.com wrote:

@badlogic https://github.com/badlogic thank you very much for replying :) Do you know what kind of issues you may expect? I tried to make the runtime above more API-compliant with Godot's AnimationPlayer API, but there are some things that are really tough. The spine-c API looks nothing like Godot's, so I'll love you forever if you find a way to make Spine a transparent drop-in replacement ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EsotericSoftware/spine-runtimes/issues/728#issuecomment-383598892, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBJ_2MltpjKUYEhw4yVKwmYBG4BE9ks5tred2gaJpZM4KV4hx .

[mjtorn]

Of course you shouldn't change the API and I never meant to imply anything like that :D Just that it would be real sweet if the Godot-facing API would be Godot-like if possible, and if not, well, it isn't at the moment either.

[badlogic]

I quickly looked into Animation and AnimationPlayer. It seems that is more targeted at animations authored in Godot itself, manipulating node properties. I'm not sure if marrying that with the Spine Runtimes API makes sense. Do you have any use cases?

[mjtorn]

My case is probably a niche one, but this PR for the Escoria framework. "My animator guys" are Spine users, so I got the license and tried to make things work out in Godot-using-Escoria.

https://github.com/godotengine/escoria/pull/134

That's why I have to accept things might not work out optimally and I may be stuck with a commit containing some personal wrapping.

[badlogic]

OK, as I understand it, Escoria uses the AnimationPlayer/Animation API. To integrate Spine with Escoria, you can either have separate code paths (as in your PR) or Spine implements the AnimationPlayer/Animation API. I'm afraid that will not be happening. The AnimationPlayer/Animation API by Godot does not cover the full feature set of Spine's API (and vice versa for a single feature: reverse playback. Which indeed is not as simple as Godot makes it out to be :)).

While I can't give an ETA, I can say with 99% confidence that Spine's Godot integration will not interact with Godot's AnimationPlayer/Animation API. We will also not convert to a different format as we don't have the resources to support our own format and third party formats. Sorry if that's a bit of bad news for you :/

[mjtorn]

@badlogic thanks for the reply, it was pretty much as expected because obviously APIs reflect the feature sets and thus are hard to integrate.

I'm almost relieved to have the matter settled now - and certainly grateful for the quick comments! - because that takes useless speculation and what-ifs off the table :)

[p0w1nd]

Looking forward to this (hopefully "soooon"). Thanks :)

[thomas-james-1986]

Do you think this could be available around the time of the Godot 3.1 release (July / August)? That would make a Godot / Spine combination a very attractive package for a lot of people I think

[badlogic]

I'm afraid that won't happen.

On May 28, 2018 19:41, "thomas-james-1986" notifications@github.com wrote:

Do you think this could be available around the time of the Godot 3.1 release (July / August)? That would make a Godot / Spine combination a very attractive package for a lot of people I think

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EsotericSoftware/spine-runtimes/issues/728#issuecomment-392576609, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBLJ-4f8CMwXNxzWMIp4pfn1_l703ks5t3DbHgaJpZM4KV4hx .

[mhilbrunner]

FYI, Godot 3.1 alpha is currently planned for July 1st. Could be later, depending on how fast the remaining features can be implemented. Even then, Godot 3.1 final release in July seems optimistic. Even August would be early, wouldn't bet on it being released before September.

We're starting to have more docs that may be relevant:

http://docs.godotengine.org/en/latest/tutorials/plugins/gdnative/gdnative-c-example.html http://docs.godotengine.org/en/latest/tutorials/plugins/gdnative/gdnative-cpp-example.html http://docs.godotengine.org/en/latest/tutorials/plugins/editor/index.html

You'd probably want to do something similar to https://github.com/GodotExplorer/spine but using GDNative, so you'd need to translate those C++ bindings for your C runtime into a (C/C++) GDNative library/plugin so it can be used by dropping it into the project or downloading it from Godot's asset lib instead of recompiling Godot with it (like with the above module).

Feel free to reach out once (if) you get started on this. I should be able to answer questions and point you in the right direction, and if not then at least to the right people.

Official Spine support would be awesome. :)

[mjtorn]

Not sure when Spine 3.7 will be out, but looking at the beta branch https://github.com/EsotericSoftware/spine-runtimes/tree/3.7-beta/spine-cpp it seems that a generic c++ runtime is coming! :)

[mjtorn]

@badlogic, here's an update to

OK, as I understand it, Escoria uses the AnimationPlayer/Animation API. To integrate Spine with Escoria, you can either have separate code paths (as in your PR) or Spine implements the AnimationPlayer/Animation API.

I've done some work on a third way. The Godot AnimationPlayer is versatile enough to control Spine nodes. I didn't realize this initially and though work is in progress, I think I can replace all my custom code with using Godot animations. Well, Godot animations that actually change the playback/play etc on the Spine nodes.

Just as a heads-up that you shouldn't have to need to stray very far from @Geequlim's work :)

[mjtorn]

I also wrote this tool https://github.com/mjtorn/spine-to-godot to make it easier to generate Godot scenes from the JSON files.

I've only used it with the Escoria framework, but it should work with anything.

[ghost]

Sounds interesting. Hopefully it comes around soon enough. We're investigating options for 2D mesh animation tools that have flexibility inside Godot for an upcoming project.

[mhilbrunner]

FYI, just as a small update: Godot 3.1 alpha was just released: https://godotengine.org/article/dev-snapshot-godot-3-1-alpha-1

There are a lot of improvements for plugins/modules under the hood. Also, animation stuff was mostly reworked.

I too believe the sanest route would be to add an additional code path via a plugin/module, without touching any of the existing Animation code in Godot.

[badlogic]

I think some form of integration with Godot's animation sequencer would be nice, i.e. key playback of a specific animation on a specific track (concepts from our AnimationState API).

I'm not sure yet about providing binaries instead of having users compile Godot itself.

On Tue, Sep 11, 2018, 13:22 Max Hilbrunner notifications@github.com wrote:

FYI, just as a small update: Godot 3.1 alpha was just released: https://godotengine.org/article/dev-snapshot-godot-3-1-alpha-1

There are a lot of improvements for plugins/modules under the hood. Also, animation stuff was mostly reworked.

I too believe the sanest route would be to add an additional code path via a plugin/module, without touching any of the existing Animation code in Godot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EsotericSoftware/spine-runtimes/issues/728#issuecomment-420239283, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBBtPXFZruLuIK43Y6Q7GqZKJ4S-dks5uZ50RgaJpZM4KV4hx .

[ghost]

Very interested to see what pans out as far as integration goes.

Even without any direct integration, the AnimationPlayer can modify whatever properties a custom Node would expose to the editor. Keyframing and interpolating their values with what is shown in the property inspector. So maybe that might be an option as well.

[zhengying]

Any update? why not use Geequlim 's work? What's missing in Geequlim's module?

[DavidjMarkham]

I'm looking forward to this feature as well. The Geequlim's module works as a decent placeholder, but it would be nice to get official support with Godot quickly gaining popularity.

[mjtorn]

@zhengying actually we started seeing weird glitches in our latest project. The way we've been doing this is a Godot AnimationPlayer kicks off the Spine animation and things work well.

However, now an idle animation doesn't move until the Godot animation has finished. Because of how things are currently set up, I don't yet know if that's only in the animation editor or can it happen in the game as well, but that's on us for now.

I think the other problems, like a character trying to move but only his hand is twitching, is somehow related.

Having official support would probably make this stuff easier to reason about than having an unsupported 3rd party module.

[zhengying]

spine 3.7 released. godot 3.1 beta will coming soon, when godot runtime is coming? any update here?

[scottkunkel]

I strongly recommend https://github.com/chanon/spine Having attachments directly available to manipulate, add shader etc is invaluable.

[zhengying]

I strongly recommend https://github.com/chanon/spine Having attachments directly available to manipulate, add shader etc is invaluable.

Great! Thanks @scottkunkel.

[mjtorn]

@scottkunkel nice! The readme does however mention a performance problem due to a Godot issue https://github.com/godotengine/godot/issues/19943 which opens up to a :hankey: show of other unresolved issues, apparently in favor of doing rewrites etc instead of fixing performance, so what kind of penalties would one be looking at if using that module?

... of course as we have some problems where the animations simply don't work, and I'm bogged down by billable work, I would maybe prefer slow code, but no idea when I can get to run tests.

[scottkunkel]

I don't think anybody has actually benchmarked this solution. On my machine :-), on an intel GPU running on battery I am able to create 10 screen sized characters with ~30 slots running at an even 50+ fps. To me that is good enough.

Where that solution lacks is having anything but the Spine Global namespace as real objects. Obtaining bones for example will return a dictionary. Dynamic scaling of bones is thus out of question. From my understanding of the godot module system it is only a matter of writing correct header files, though. I haven't worked with C in a while, though.

Again, I like the flexibility this provides for a programmer within Godot as the slots are now "native" Godot elements. I do see the need for some TLC on that implementation, though.

[mjtorn]

That sounds reasonable for my purposes, and we had to implement a workaround in one character animation because his arms couldn't have separate z-indexes, so that's all good.

The bad is that I patched the make-nodes branch to compile with 3.0 and it didn't fix my major Spine issue: trying to make the player character talk, instead of the talk animation, his hand twitches. In the editor this is for the duration of the AnimationPlayer animation, but once that's over, the animation plays fine. Never works in the game, but I haven't tried setting the dialog timeout to ridiculous lengths yet.

Maybe something else will solve my woes.

[scottkunkel]

Interested in what you needed to patch, I am running that branch in 3.1 beta without changes.

[chanon]

Hi ... if your target device is PC, then my fork should be ok.

The real performance issue is only on mobile devices. Whenever the Godot devs implement automatic draw call batching, then it will get a massive performance boost.

[chanon]

@mjtorn You might want to check if your spine application version matches the runtime version in my fork. 3.7 and 3.6 aren't 100% compatible.

[mjtorn]

@scottkunkel

diff --git a/spine.cpp b/spine.cpp
index cb7a1a3..4baad51 100644
--- a/spine.cpp
+++ b/spine.cpp
@@ -218,8 +218,10 @@ void Spine::draw_slot(SpineSlot *spine_slot) {
                    p_points,
                    p_colors,
                    p_uvs,
+#if (VERSION_MAJOR == 3 && VERSION_MINOR >= 1)
                    Vector<int>(),
                    Vector<float>(),
+#endif
                    texture->get_rid());
            break;
        }
@@ -270,8 +272,10 @@ void Spine::draw_slot(SpineSlot *spine_slot) {
                    p_points,
                    p_colors,
                    p_uvs,
+#if (VERSION_MAJOR == 3 && VERSION_MINOR >= 1)
                    Vector<int>(),
                    Vector<float>(),
+#endif
                    texture->get_rid());
            break;
        }

[mjtorn]

@chanon the animations we have are provided by an outsider, but I have it on good authority they're using the 3.6 versions. I have a 3.6 installation and though I don't really know how to use the software and have it for the runtime license, it doesn't look bad.

Most of our games' animations work, but embarrasingly enough pretty much anything related to the actual player character (in the latest game) is broken in one way or another. This makes me think maybe the glue between the runtime and Godot is somehow broken. Having an unmaintained codebase for this is pretty "yolo", but we've been happy taking the risk so far, because we haven't had problems so far.

That's why official Godot support would be so sweet.

[chanon]

maybe try the upstream version of my fork to see if it is still broken

[mjtorn]

@chanon I did. This is kinda flooding the wrong issue, but this is what the Git log looks like, when I committed the diff from above. Note that I had to cherry-pick another 3.0 compat commit.

* 173c77f – Add version checks (1 second ago)
* 4a96a97 – Add version check to compile with 3.0 as well (18 hours ago)
* 8f18472 – Added performance note to README (3 months ago)

I did not construct the Spine nodes "the hard way" but only tested with what we currently have. It'll take a while for me to attempt an alternative solution. Gotta round-robin my work :(

[RtFishers]

So is it safe to conclude that Esoteric is no longer going to implement an official runtime for Godot? I would absolutely love if they did, though!

[badlogic]

No, we definitely have plans for Godot! It's just that we had a lot of work with the 3.7 release.

On Jan 22, 2019 12:23, "RtFishers" notifications@github.com wrote:

So is it safe to conclude that Esoteric is no longer going to implement an official runtime for Godot? I would absolutely love if they did, though!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EsotericSoftware/spine-runtimes/issues/728#issuecomment-456365399, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBNhdLlmbj8fT8yxrR6C_xr-UcM3uks5vFvS9gaJpZM4KV4hx .

[mjtorn]

@badlogic, are you considering normal map support for lighting? I've understood this is fine in Spine but neither @chanon 's nor @Geequlim 's implementation has anything for it. Thanks!

[mjtorn]

May we ask if there is progress on this? Looking at it this is an enhancement, but not in progress, so any news are welcome :)

[jacksparrowGreg]

No, we definitely have plans for Godot! It's just that we had a lot of work with the 3.7 release. On Jan 22, 2019 12:23, "RtFishers" notifications@github.com wrote: So is it safe to conclude that Esoteric is no longer going to implement an official runtime for Godot? I would absolutely love if they did, though! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#728 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfYBNhdLlmbj8fT8yxrR6C_xr-UcM3uks5vFvS9gaJpZM4KV4hx .

Hi @badlogic , Would be great if you have any more details on SPine integration with Godot. Now Feb 2019, i know you guys are busy, but any news? a roadmap? a plan? Godot is really gaining some good steam and the community is flourishing. Would be great of you could let us know whats happening. Thanks again. (I want to buy a SPine license but cant pull the trigger as im developing with Godot at the moment

[badlogic]

Hi everyone. We've been working on 3.7 for the past year, released it in January, and are now tying up loose ends. I can't give you an ETA, but we'll likely start working on Godot at the end of Q1/beginning of Q2.