The goal
I am proposing it here to see if we can collect a bounty to hire someone to create an addon for godot , using gdnative that allows using gdscript to control assets imported from dragonbones. It is for an addon that uses the dragonbones runtime and gdnative to expose all the dragonbones runtime features to gdscript,visualscript and godot's editor(a dragonbones node)
I am not requesting for the dragonbones runtime or the addon to be included with godot. The addon can be posted to the asset store. That would be enough.
We can still take advantage of this issue tracker for:
The goal is to make this addon and put it on github. Then post it on
https://godotengine.org/asset-library
The addon needs to be able to:
A bounty
If you want to see this feature in Godot, you can help by contributing to the bounty to implement it here:
https://www.bountysource.com/issues/50931377-create-gdnative-bindings-for-the-dragonbones-runtime-bountysource-and-add-it-as-a-free-addon-to-the-asset-store
Why Dragonbones ( www.dragonbones.com )
https://github.com/ndee85/coa_tools
Using json animation data instead of frame by frame sprites has the following advantages:
Popular games that use it:
Why Gdnative - gdnative would allow people to use the runtime without having to recompile the entire engine
@blurymind While I'm familiar with GDNative a bit, I'm not so familiar with DragonBones or the integration of runtimes really. Could you explain exactly what these bindings would entail / what functionality they would enable that isn't already available in the Animation system for Godot? I think I would understand better if it were just a matter of being able to examine a dragonbones file format and port it to a .tscn with established settings for an AnimationPlayer, but you seem to be describing something a bit more involved than that.
@willnationsdev the biggest feature is of course 2d mesh deformation. The editor allows turning 2d cutouts into actual tessellated meshes and bind multiple bones to a single cut-out piece. The editor is much better suited for animation work than the tools available in godot. Here is the FREE editor's documentation:
http://edn.egret.com/en/index.php/article/index/id/528
here is their english blog for latest features:
http://blog.dragonbones.com/en/
a video of the editor:
https://www.youtube.com/watch?v=3mC9suxK6zM
https://www.youtube.com/watch?v=DWwwRiM1u2A&t=5s
as for the runtime itself, it has a big number of features to aid controlling animation procedurally via scripting:
The full API documentation is here:
http://edn.egret.com/cn/apidoc/index/name/dragonBones.Animation
its partially chinese, so you might have to google translate the description of the methods, but they are really self explanatory anyway. All you need to do to understand it is open a demo scene that is provided for cocos2d or for unity3d runtimes
It has too many features to list, its mind boggling. You can see these features in actual example files in action, if you actually download the example files and open them. cocos creator and the cocos engine has a builtin dragonbones support now- so it has the best example files of the c++ and javascript api in action
http://discuss.cocos2d-x.org/t/cocos-creator-1-3-2-released/33625
Here is the c++ api in action- in another engine:
https://www.youtube.com/watch?v=BhnJcPYzIKg
other videos:
https://www.youtube.com/user/DragonBonesTeam/videos
Sorry that this is all I could find, but there is ALOT on their github repository
Because godot doesnt yet support 2d meshes you cant simply write an importer that converts the data to a godot scene file.
You wont get the awesome features of the runtime either that way
Um...I think I'm starting to get confused by what exactly you think you need to do in order to use this. I mean, GDNative C++ is working...so if all you wanna do is include DragonBones' C++ API into your Godot project, there are no DragonBones-specific "bindings" that you have to make. The godot-cpp
bindings are all you need to integrate 3rd party libraries written in C++.
.gdns
script that points to the GDNative class you made in the GDNativeLibraryIs there some aspect of this that doesn't line up with the functionality you are looking for? I would guess this would be something like triggering DB editor behavior from the Godot editor (?), but that may not be what you want.
Well that's a cool idea, but I'm not sure this is the place for such proposal.
Indeed, we're not going to list in the repository issues everything that could be done as external assets. Unless you want this to be a built-in feature (but it is almost sure that it will never happen).
@groud Yeah, I think his suggestion is the creation of a plugin that can enable this functionality, in which case...there isn't really a good place to "put" it. Except for maybe its own independent repository. But even then, I'm not quite sure what the goal is.
If the goal were to allow the user to edit a DragonBones project and see those changes reflected in Godot assets, then you would need the desired features to actually be added to Godot (THAT would be a Godot Issue), and then create a GDNative C++ plugin project (in its own repostitory) that would have to call the analogous behaviors into Godot via signals whenever the DB functions are called (assuming the DB editor calls those functions when you mess around in its editor).
If the goal is instead to make DB editor functions trigger based off of Godot scripts, then the procedure described earlier should do that.
Not sure if I'm missing anything here?
@groud I am proposing it here to see if we can collect a bounty to hire someone to create an addon for godot , using gdnative that allows using gdscript to control assets imported from dragonbones. It is for an addon that uses the dragonbones runtime and gdnative to expose all the dragonbones runtime features to gdscript,visualscript and godot's editor(a dragonbones node)
I am not requesting for the dragonbones runtime or the addon to be included with godot. The addon can be posted to the asset store. That would be enough.
We can still take advantage of this issue tracker for:
@willnationsdev what you list is actually very difficult to do by someone with little c++ experience. Nobody has done it yet. If you do succeed, would you please share an example godot3 project that successfully uses dragonbones assets and the exposed dragonbones c++ runtime?
The goal is to make this addon and put it on github. Then post it on
https://godotengine.org/asset-library
The addon needs to be able to:
I updated the first post to make the proposal clearer. Hope this is ok now :)
@groud I am proposing it here to see if we can collect a bounty to hire someone to create an addon for godot , using gdnative that allows using gdscript to control assets imported from dragonbones. It is for an addon that uses the dragonbones runtime and gdnative to expose all the dragonbones runtime features to gdscript,visualscript and godot's editor(a dragonbones node)
So this is not a part of the engine, it's a plugin proposal.
I'm not against this idea, I just don't think such proposal should be posted here. If everyone that has a gdnative-based plugin idea post it into the engine repository it's going to bloat the issues list for things that are not even meant to be merged.
That being said, there's no other place to post that kind of idea ( yet? :) ).
@groud unfortunately the bountysource website works only with github issue links. This is a good place also because godot developers such as @willnationsdev visit it- it gets exposure.
@willnationsdev if you think you can do it, you can put a bounty on the job for your time if you want to :)
This bounty+issue tracker approach has worked quite well for opentoonz features, I was wondering if it will work for godot too.
Of course it is only optional, if nobody contributes, a dev can still implement it for free if they wish to
perhaps gdnative plugin proposals could have their own tag?
@groud Yeah, I think it would be a good idea for us to come up with a dedicated space for people to post plugin and/or module ideas (and then just keep finished versions on the Asset Library). For now, you basically have to create an entire repository for the implementation or, if your just the "ideas" guy who wouldn't know how to actually implement it (no offense), then currently the best you can do is post it somewhere and hope someone else starts implementing it. But that somewhere for now is basically just random social media and it's not any sort of "primary" space. It doesn't fit as a godotengine/godot Issue. I suppose we could create an entire GitHub repository for plugins/modules affiliated with Godot and use the "Issues" to track/discuss these ideas. I don't know if a repo like that is better hosted by a random dev or by the godotengine organization though. Various links would need to be added to a couple of sources.
@blurymind Heh, well I only saw it because you shared the link on Reddit. Had nothing to do with it being a GitHub issue. With that said, and as mentioned above, this particular repository isn't really the place for it. Would love to make a space for things like this though.
I think part of the confusion for an implementation is that there are misunderstandings on your part on how the GDNative interfacing would actually work.
Please share an example godot3 project that successfully uses dragonbones assets and the exposed C++ dragonbones C++ runtime
expose the latest c++ runtime of dragonbones to godot
it needs to support all of the features of the latest dragonbones runtime
All we would be able to do with GDNative is create a NativeScript (a .gdns
file), accessible from the scripting engine (and therefore the NativeScript class would be accessible to ALL scripting languages bound to Godot: GDScript, VisualScript, C#, other NativeScript classes), that would have the ability to make calls to the DragonBones editor's C++ API, and consequently trigger the DragonBones editor's behavior. This isn't exactly what you want though. It allows Godot to make changes to DragonBones, not the other way around.
What you seem to want is to make something in DragonBones and then be able to render that exact same content into Godot. There are two ways this could be done.
Recreate all of the DragonBones content using the Godot API (so you essentially just find analogous behaviors in Godot's API and generate a scene with similar content as the DragonBones scene's content), but this would mean you are limited by both APIs as only the content that is shared between them would be something you can generate at all. This would defeat the purpose of using DragonBones in the first place and instead just fund the development of the same features in the Godot Engine so that we can just take DragonBones out of the process entirely.
Have some sort of image file that gets updated by DragonBones in real-time as the animation plays and which Godot can pull from at an equivalent rate to render content to the screen. I don't know the first thing about how this would be done. I suspect something about StreamTexture would facilitate this, but I haven't the faintest idea of how to use that node.
The ideal thing would be to get an understanding of how to pipe the rendering stream output of DragonBones into the input rendering stream of Godot's StreamTexture
. That way, there wouldn't even be a need for a plugin. You would make changes in DragonBones, and those changes would show up on some sort of resource in real-time, and Godot's texture could simply point to that resource, causing the same images to be rendered in Godot, simple as pie. But I don't know anything about how to handle stuff like that. Maybe someone with more rendering awareness?
@blurymind Also, "ain't nobody got time for that". I'm currently in the middle of writing two other plugins on my own, and moving to a new house over the next month, so I'm way too busy packing/unpacking to do anything more. XD Would love to help if I knew more / had more time, but...
@willnationsdev I understand :) perhaps somebody else will pick it up. Thank you anyway for outlining your approach of implementation. It might help the next developer.
When gdnative gets better documented, I might give it a try myself - but I am an absolute c++ noob. Will need to watch a lot more courses to get to your level.
I just really really want to see godot become on par with cocos, unity and all the other game engines that do have support for the runtime. This will have a huge impact on the kind of artistic direction godot games can have
@blurymind I've also been looking into this - more to just implement sprite meshes in the current godot editor, but this is in the same vein. Keep in mind from @reduz article on the renderer design, the Visual Server is heavily abstracted and in @reduz own words, a primary disadvantage to this approach _is It is not possible to control, from user code, the internal steps of rendering._ I traced the sprite rendering workflow a little back to the rasterizer_scene_gles3 code and I think we would need to expose 2D meshes to the 2D engine and I'm not sure how involved that is. This makes me think a GDNative approach alone will not work (I definitely could be / probably am wrong ).
All of this to say that I plan on digging a little deeper in December. If you wanna chat about it, ping me on Discord. I also want mesh deforms for my next 2D project - I'm just trying to weigh how much effort there is in going this route (especially with my VERY limited knowledge of the code base).
@bitbionic thank you for looking into this.
Really hope for this to become a reality in godot, as it will open a lot of creative possibilities
If Dragonbones support Linux. I may try to make a module for godot 3.0
@Geequlim The Dragonbones editor does not run on Linux. It is an Adobe AIR app which will supposedly never run on Linux, because Adobe dropped support forever ago. I'm not sure why they are coding something in such an antiquated environment, but to each their own.
The dragonbones editor does run on linux via wine. Also you can use an
addon for blender to create and author dragonbones files
On 19 Dec 2017 06:00, "Ross Hadden" notifications@github.com wrote:
@Geequlim https://github.com/geequlim The Dragonbones editor does not
run on Linux https://github.com/DragonBones/DesignPanel/issues/31. It
is an Adobe AIR app which will supposedly never run on Linux, because Adobe
dropped support forever ago. I'm not sure why they are coding something in
such an antiquated environment, but to each their own.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12504#issuecomment-352647909,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVRQRkfVc8E9w_VV8wUQG_XM9ft0pks5tB1DngaJpZM4QK5ND
.
@blurymind Being able to run something with wine does not magically give it Linux support, even if it might be technically runnable.
@Geequlim Both Spriter and Spine do have official native Linux clients, though.
Spine costs 300$ and spriter has no mesh deformation support - not even
gonna have it soon
On 19 Dec 2017 15:00, "Ross Hadden" notifications@github.com wrote:
@blurymind https://github.com/blurymind Being able to run something
with wine does not make it runnable on Linux.@Geequlim https://github.com/geequlim Both Spriter and Spine do have
official native Linux clients, though.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12504#issuecomment-352783223,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVa1jnmcX8caqVpUOAmRY8amcTLQgks5tB8-bgaJpZM4QK5ND
.
It looks like somebody has created a dragonbones runtime via a Godot module for Godot 2:
https://github.com/sanja-sa/gddragonbones
The goal now would be to get it ported to Godot 3 or even better to create a gdnative addon that would elliminate the need to recompile godot and it's export templates
Many thanks to sanja-sa!!
The plugin linked above now seems to support Godot 3.0 and 3.1. I guess this can be closed now :slightly_smiling_face:
If there are bugs or missing features in the plugin above, please report them on https://github.com/sanja-sa/gddragonbones/issues, not here.
Most helpful comment