Godot 3 being a very capable, easy to use engine wich is growing more and more in popularity convinced me
to use it for the development of my next project. The only thing that is missing are the runtimes for spine.
I read on the forum that the runtimes are on their way and am very happy about it. So to my questions.
Will these runtimes enable us to use advanced features of spine like inverse kinematic, paths, constraints etc. ?
This is my first post here. so I want to congratulate Nate and all involved for this awesome software. :yes:
All runtimes support all features you see in the editor unless the game toolkit makes this impossible (which is rare). badlogic can give an update on when the Spine Godot runtime will be available.
It lacks lot of features, and it's basically a "read-only" runtime, you can't interact on the skeleton yourself, but you can play animations (it does support FFD)
It's still nice to have this runtime while waiting for the official one (wich hasn't been started yet I think)
Hey TheTrope, yes thanks.
I have tried it out and its nice for a "preview look" before the real stuff comes out. :p (although in my case it didn't function very well with a test export from godot. there was a problem with the json resource loading that i couldn't figure out). So we'll wait for master badlogic Maybe now that the c++ generic runtime is out, it is easier to implement with gdnative. darn it.... i wish i was better in c++ programming
I am also looking forward to the Godot runtimes. Any ETA on this? Perhaps we are waiting on the spine 3.7 c++ runtimes to be finished or Godot 3.1 to be released? Also, Will the runtimes support all platforms Godot can export to minus html5?
Godot is on the roadmap for this year and will be based on the spine-cpp runtime. As for platform support, whereever Godot supports textured meshes, Spine can be supported. I'd assume that'd include HTML5. Concerning ETA, I'm reluctant to give a concrete timeline, as there are always things coming up that need doing. The plan is to have it later this year, most likely Q4, but don't quote me on that
The plan is to have it later this year, most likely Q4, but don't quote me on that
I count myself in this as also very hopeful to see a robust run-time appear for Godot 3.0/3.1 in the near-term. My partner has been reviewing 2D mesh/puppet software, and we're very heavily leaning towards Spine at the moment. It looks like the clear winner for this style of animation, and that a lot of care has gone into the UI and functionality. The current downside is that we wouldn't be able to take much advantage of the features we're most interested in for our upcoming project, since we're targeting our work in Godot 3.1 alpha.
I saw some module out there, but it doesn't look very complete, so it may take too much time invested in it only to discover it can't do what we need inside the engine.
I don't yet have any first hand experience with Spine or what the run-times aim to expose, so just wondering the fuller extent of what will be available to manipulate in the nodes/resources?
Our needs are to create a character puppet that can be instructed where to point their weapon, while handling other body movement actions simultaneously. From looking at some of the videos it appears like it provides a means to do this. Perhaps more importantly, we'd also need to be able to access coordinates of certain locations that would be attached to moving and rotating parts. Such as origin points for the tips of weapon barrels. I imagine this is all standard stuff.
I'm not entirely sure what to expect, as it doesn't sound like it will be anything like an importer that maps things onto nodes and constructs a scene.
If a run-time can provide a solid interface through GDScript, and is expected in the near horizon of the next few months, that would be a big selling point for us. X)
We are currently working on getting the 3.7 release out in time, and we are also working on a secret project that needs to get done before new runtimes can be written. I'm looking at Q4 to investigate and implement a Godot runtime. As with all software projects, it's hard to estimate if we'll make the Q4 window though, so if this is a business critical thing for you, take that into account.
The plan would be to create a native module using our spine-cpp runtime and expose that to GDScript. I'm not sure yet if we want to map individual bones to nodes, or if a single node would manage the entire skeleton (I'm in favor of the later, as it means less synchronization between the Spine and GDScript side, leading to better performance, and less surprises). The requirement you described is called Inverse Kinematics, and it will definitely be exposed to GDScript. The same goes for getting the world positions of bones. I'm unsure if we'll integrate with the animation tools Godot comes with in the first iteration, as I haven't looked into that much yet. You'll definitely be able to use our AnimationState API to manage animation queueing and transitions.
@badlogic Great! Thanks for the reply and the info. This is all good to hear, I'll start investigating.
It sounds like you have quite a lot there on your plate. If you're dead set on this project and at least aiming optimistically for that time, I think we'll give it a shot. It's programming, so yeah, let's just say delays are coming.
It would be tight for us, and we'll probably be able to swing back and update some work in six months or so. I'm thinking as long as it doesn't take more than half a year, we may still get some good use out of the runtimes.
Looking at the site video, I think this is what we'll need to be able to keep things compatible and looking good:
As long as I can achieve that in Godot, I'll be happy.
I do like the idea of possibly having bones linked in through some type of CanvasItem nodes, but yes, probably only nice as an option to have, if one wants to trade off performance for some ease of use in the editor's scene tree. Though I'm thinking that may take a bit messing about with the tool scripts, and likely would need an editor plugin depending on your data.
At least with what you're describing, if it has a really strong API and reliably reproduces everything, I imagine it wouldn't be too difficult for many Godot users to write their own tool scripts and plugins to wrap around some of that functionality.
Best wishes to you and your team. Is there anything I can subscribe to for a notification when this is around the corner or hitting the floor?
With a straight exposure of our APIs to GDScript (or through native script) it should be dead simple to reproduce what you see in the video. All our runtimes across all languages (Java, C#, Lua, ActionScript, C, C++, TypeScript) work exactly the same. The code of that demo project would translate 1:1 to GDScript (with some changes to make the API a bit more idiomatic).
I hope this runtime can be done this year... module is the way against GDNative, best integration with GDScript. You should no translate bones to nodes because performance, Spine node should be one node and controllable with gdscript, bones, meshes, animations, z-order, etc... should be exposed to scripting sysem and if user need to attach one bone to a position or changing z-order, something like this, they can write exported variables to see that in inspector or make gdscipt logic to change that bone/mesh/texture/whatever in runtime...
We are waiting for this, please don´t forgot, in 2018 Godot it much more used that many of the other API´s that are now soported officially by spine, and behind Unity/Unreal/GameMaker, Godot is becoming the open-source alternative to this aplications.
What do you mean by translating attachments to nodes?
Which runtime are you using? If you are using the Spine Unity runtime, then there is an example scene Spine Examples/Other Examples/BlendModes which uses Skeleton Data Modifiers to assign different shaders for blend modes Multiply/Screen/Additive. You can set these blendmodes in the Spine Editor and they will then be automatically set up by the Spine Unity runtime.
Please note that the topic of this forum thread is not very suitable for your question, since it is most likely not related to Godot - it would be better to start a separate thread.
as Godot's popularity is currently growing rapidly and it's probably the 3rd most used engine after Unity and Unreal, a runtime for Godot is becoming more and more important.
It seems like this: https://github.com/GodotExplorer/spine has been abandoned.
Are there any current efforts to create a runtime with full support?
Only thing keeping me away from Spine, unfortunately. Like Spine Godot is just incredible!
As of using unofficial third-party libraries - GDQuest can convince you that it's too risky to use them in commercial projects.
