[godot] Add support for Godot Engine

[badlogic]

No description provided.

[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" ***@***.***> wrote: Is this no longer happening? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#728 (comment)>, 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 ***@***.***> 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 <#728 (comment)>, 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.

godot-escoria/escoria-demo-game#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 <#728 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfYBLJ-4f8CMwXNxzWMIp4pfn1_l703ks5t3DbHgaJpZM4KV4hx> .

[samlletas]

Having Spine support in Godot would be great!

@badlogic, are there still plans to start working on this in the near term?

[PaulsonH]

@badlogic hey is there have any news about it?

[badlogic]

@PaulsonH I'm afraid we haven't started working on this yet. Our focus is currently on curve editor support, which requires large changes on the runtime side of things.

[PaulsonH]

what a sad news TAT

[samlletas]

@badlogic Sorry to bother again but I'm wondering, has Godot support task moved to low priority for the near term or are there plans to start working on this after curve editor is completed?

[samlletas]

Adding to the early discussion about performance, it seems that mesh rendering performance was improved with the recent 3.2 release:

godotengine/godot#19943 (comment)

[hortopan]

Still sad to see there's no Godot official runtime yet.

[scottkunkel]

Unofficial:
https://github.com/scottkunkel/spine

Godot 3.2
Spine 3.7.94 (skipping 3.8)

allows for blending skins and takes draworder into account when animation changes it.

BUT: does not adhere to strict API
godot does autosense spine methods
all methods are found under

void Spine::_bind_methods() in spine.cpp

[yuraj11]

I have found this on github and it looks that it works with spine 3.8 and godot 3.2 and also far more advanced library. There's demo with working spine boy and aim animation.
https://github.com/rayxuln/spine-runtime-for-godot
https://github.com/rayxuln/Spine-Run-Time-For-Godot-Example

[scottkunkel]

I have found this on github and it looks that it works with spine 3.8 and godot 3.2 and also far more advanced library. There's demo with working spine boy and aim animation.
https://github.com/rayxuln/spine-runtime-for-godot
https://github.com/rayxuln/Spine-Run-Time-For-Godot-Example

Wow, that one looks like a by the books implementation. Nice find!

[scottkunkel]

Did a quick fork to make it build on windows.

I would call it a commercial implementation with adherence to the official Spine API. The code is as clean as it gets and the usage in godot makes total sense. @mjtorn check it out! No normal map support but should be easy to add.

@badlogic using this as a basis for the official godot implementation would save you a lot of time and effort.

[mjtorn]

@scottkunkel maybe I will. There's nothing on which version of the runtime is included and the
documentation reads as Chinese, though.

Godot has had some other long-standing issues that make life hard for us, so we have been
experimenting with moving to Unity. Using affordable assets and a moderate amount of in-house
glue code seems to deliver what's expected. Still, money needs to be made so I don't have
active hours to use on this.

Having things like label sizes fixed and whatnot might encourage to give Godot another shot,
but also the framework we've been using seems to have taken some steps in a new direction
and stopped.

Then there's the question of trust, as Esoteric has basically flipped off the Godot community,
as is their right, by stalling on empty promises while maintainer after maintainer of
third party modules have ceased caring.

That's why things are on hold for me now, and will be for quite a while anyway.

[badlogic]

I understand your frustration that we have not yet gotten to officially support Godot. We are a very small team with a huge workload trying our best to get things done. Doing Godot justice is not a matter of spending a few days and out pops a runtime. A good integration likely takes me between one to two months, as it not only involves writing code/examples/docs, but actually diving deep into Godot, understanding its idioms, understanding its deployment model(s), its performance best practices etc. Fitting those 1-2 months into the already existing workload is not trivial. Given our resources, I need to prioritize things. I'm afraid Godot didn't make it to the top of that list yet, not because I don't want to, but because I simply couldn't slot it in given business needs yet. We, or specifically I, have not "flipped off" the Godot community.

…

On Thu, Jun 25, 2020, 07:40 Markus Törnqvist ***@***.***> wrote: @scottkunkel <https://github.com/scottkunkel> maybe I will. There's nothing on which version of the runtime is included and the documentation reads as Chinese, though. Godot has had some other long-standing issues that make life hard for us, so we have been experimenting with moving to Unity. Using affordable assets and a moderate amount of in-house glue code seems to deliver what's expected. Still, money needs to be made so I don't have active hours to use on this. Having things like label sizes fixed and whatnot might encourage to give Godot another shot, but also the framework we've been using seems to have taken some steps in a new direction and stopped. Then there's the question of trust, as Esoteric has basically flipped off the Godot community, as is their right, by stalling on empty promises while maintainer after maintainer of third party modules have ceased caring. That's why things are on hold for me now, and will be for quite a while anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5QBBNDHVVFYZN6S2O4ALRYLPOHANCNFSM4CSXRBYQ> .

[mjtorn]

@badlogic I apologize if I was harsh and misunderstood. I have worked the field long enough to understand business needs and sadly that's the reason we're evaluating Unity - and only at the time and money we can spare for any of this.

But to explain myself, the "flipping off" referred to earlier communication, not "not supporting Godot". It's been sounding like Godot support is constantly just around the corner. Saying up-front "we don't have the resources, don't expect this at all, but maybe we can give clues unofficially to a dedicated 3rd party dev on how to maintain a module" would have been as honest as your message and maybe kept the interest going in one of the previous iterations.

(I understand even those clues would be a tall order, as you would spend an indefinite amount of time on what could turn into a dud at any time. Open source and maintainership and all of that is hard! And combined with business it's even harder...)

I'm glad to hear this latest one adheres to the APIs, because it's also a bit risky to get locked in with someone's hobby module, even if it was sincere and actively maintained, and then the official release worked completely differently.

Hope that clarifies my view and constitutes an acceptable apology.

Also thanks for making Spine!

[badlogic]

No worries. I agree that expectation management on my end should have been better. Alas, I'm always a bit to optimistic when it comes to planning... story of our engineering life. I'm sorry if the unavailability of an official runtime caused uncertainty in your business. FWIW, the last 3rd party entry above actually looks pretty solid. Keeping the spine-cpp part up-to-date should be simple, as we almost never change the API. Lacking experience with Godot's API change frequency, I can't speak on how hard it would be to maintain the Godot specific parts of that runtime.

…

On Thu, Jun 25, 2020, 09:15 Markus Törnqvist ***@***.***> wrote: @badlogic <https://github.com/badlogic> I apologize if I was harsh and misunderstood. I have worked the field long enough to understand business needs and sadly that's the reason we're evaluating Unity - and only at the time and money we can spare for any of this. But to explain myself, the "flipping off" referred to earlier communication, not "not supporting Godot". It's been sounding like Godot support is constantly just around the corner. Saying up-front "we don't have the resources, don't expect this at all, but maybe we can give clues unofficially to a dedicated 3rd party dev on how to maintain a module" would have been as honest as your message and maybe kept the interest going in one of the previous iterations. (I understand even those clues would be a tall order, as you would spend an indefinite amount of time on what could turn into a dud at any time. Open source and maintainership and all of that is hard! And combined with business it's even harder...) I'm glad to hear this latest one adheres to the APIs, because it's also a bit risky to get locked in with someone's hobby module, even if it was sincere and actively maintained, and then the official release worked completely differently. Hope that clarifies my view and constitutes an acceptable apology. Also thanks for making Spine! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5QBCU7IR44ZKUDTWWALDRYL2QNANCNFSM4CSXRBYQ> .

[scottkunkel]

Did a workover and put my fork into my own test project.

The nice thing is that slots come in as children (MeshInstance2D) of the spriteobject, allowing direct manipulations.
Found some bugs and usability issues but am working on workarounds and fixes:

• custom skins cannot be initiated as empty skins atm; copying existing skin and adding more skins to it will work.
• fixed c++ code to allow shader assignment post skin change to the children.
• updated spine-cpp to latest version
• ubuntu in windows build works, not sure what if the commented out line in SCSUB is needed (no Mac available to me)

Regarding the locking in: this runtime creates a SpriteObject. I am using the classic decomposition in godot and am passing that object into the components as a parameter. That allows me to call the API as documented on that object. As long as any runtime adheres to this API I can switch them out quickly.

Also: https://godotengine.org/article/maintenance-release-godot-3-2-2
Godot now includes batching! Haven't tested it yet and there might be caveats with this:
https://github.com/lawnjelly/Misc/blob/master/Batching/batching.md
Did a quick and dirty test which showed no appreciable improvements on windows, but I did not look deeply into what's needed to make this work.

Continue giving it a whirl, but so far it's easy to use (and I can finally use the API documentation to look up functions)

I am worried about the 4.0 godot release since they are changing quite a bit underneath the hood. However, this runtime is creating only basic godot resources. The SpineSprite and it's children are the only "real" godot objects and hopefully there won't be too much happening in their API. I also had more trouble with godot and its bugs as well as the build process to integrate Spine. Such is the life of open-source.

All in all, I can produce results in godot much faster than unity and the editor is very focused. For the hobbyist that I am, godot is my first choice.

[scottkunkel]

Adding normal maps back into the code. Currently master branch is broken (guess I have to start dev branch).

My c++ is really not there. Could someone pls check scottkunkel/spine_runtime@f7df902
especially the unload function to make sure I am doing the right thing here?

Much appreciated.

Next steps is to put the normal maps onto the meshinstance which now is a trivial coding exercise.

[yuraj11]

@scottkunkel would not be better to create PR in original repo (+ ask original author of the runtimes for code review)?

[scottkunkel]

I contacted the person early on but have not received any communication. I'm impatient :-)

[scottkunkel]

PR created and merged. Continue to use and work on the code.

[scottkunkel]

Rayxuln has updated the original libraries and added normal map support! Atlas will load normal maps with _n suffix.

[iamjoeysox]

Any help I can offer here? Would love to have this for my pipeline. :)

[badlogic]

It's happening, see the spine-godot branch. The initial runtime was contributed by @rayxuln, see https://github.com/rayxuln/spine-runtime-for-godot

I'm currently reworking it a little and smooth out some rough edges, as well as writing documentation and example projects. This is a pretty big task, so will take a bit.

We will initially support Godot 3.x via a module. That means users will have to compile Godot with our module themselves. We've decided against GDNative as it is being discontinued in favor of GDExtensions. GDExtension is essentially how modules work, so there's a lot less duplication of work, and we can hopefully support both Godot 3.x and 4.x with the same code base.

[mhilbrunner]

As both a Godot contributor and Spine user, that sounds like an extremely reasonable approach. :) Hype! 🎉

Link to the branch for people as lazy as myself: https://github.com/EsotericSoftware/spine-runtimes/tree/spine-godot/spine-godot

[scottkunkel]

Glad this has found its home Thomas

…

On Sep 30, 2021, at 2:29 PM, Max Hilbrunner ***@***.***> wrote:  As both a Godot contributor and Spine user, that sounds like an extremely reasonable approach. :) Hype! 🎉 Link to the branch for people as lazy as myself: https://github.com/EsotericSoftware/spine-runtimes/tree/spine-godot/spine-godot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[obinnaEmelumadu]

@scottkunkel
I'm glad to see this is being supported officially. I will be looking forward to the GDExtension when its ready

[cesarizu]

I've been testing this branch with Godot 3.4 and I found a few compilation problems. I've created a PR #1979 to fix those.

Also I'm seeing this error in the console but I'm not sure how to fix that:

ERROR: Invalid setter 'SpineSprite::set_skin' for property 'custom_skin_resource'.

[badlogic]

Done :)