spine-runtimes
spine-runtimes copied to clipboard
EsotericSoftware
[godot] Add support for Godot Engine
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" [email protected] 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 .
Looking forward to seeing this implemented. Will buy a spine license once it works with Godot
I know the Kestrel Moon people have been on the forums trying to enlist help to port Creature to 3.0
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
@badlogic you added the "ready" label, what's up with that? Is this available somewhere?
That means it's ready to be worked on. We have not started work on Godot yet.
@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 ;)
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 [email protected] 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 .
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.
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?
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.
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 :/
@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 :)
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
I'm afraid that won't happen.
On May 28, 2018 19:41, "thomas-james-1986" [email protected] 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 .
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. :)
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! :)
@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 :)
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.
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.
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.
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 [email protected] 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 .
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.
Any update? why not use Geequlim 's work? What's missing in Geequlim's module?
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.
