Feature request: Dragonbones json data exporting

[blurymind]

This is an incredible piece of software with huge untapped potential and seemingly abandoned by its developer.

You have all the tools you would need to create skeletal animation for 2d games in it, but not a single way to export it as json data!

The suggestion is to use dragonbones export format. Why? Because the runtimes for games that it uses dont require the developers to purchase any licenses. Some blender addons have implemented it as a result.

So for example a game developer can use anime effects to create an animation, export it as dragonbones json data and make it interactive, like this: https://pixijs.io/examples/#/plugin-dragonbones/eyetracking.js

and the dragonbones js runtime https://github.com/DragonBones/DragonBonesJS/tree/master/Pixi

All we need to make this happen is the export to json feature.

But why use anime effects over dragonbones editor? Anime effects is truly open source and also runs on linux. Dragonbones editor is not. Actually AnimeEffects its the only open source fully featured 2d skeletal animation app out there. But nobody is using it, because it doesn't export the data in a format that is useful for game dev

Documentation https://developer.egret.com/en/apidoc/index/name/dragonBones.EgretEvent

also on the data format https://github.com/DragonBones/DragonBonesJS/blob/master/docs/DragonBones_5.0_data_format_zh.md

There is a Dragonbones C++ runtime here https://github.com/DragonBones/DragonBonesCPP

[Jose-Moreno]

@blurymind This would be great but I doubt the developer will come back to this, they've been MIA ever since 2017 even his social media is deserted (I honestly hope he's alright and nothing serious happened to them)

I think it should be more fruitful to fork this and continue working on it on the side as well as promoting it on other places to see if people would become interested.

If the dev ever comes back then all has to be done is make a huge PR to restore whatever fixes and functionality that were added to upstream master, otherwise this will continue to be a dead project, unfortunately :disappointed:

I've already forked this project although i'm not proficient with C++, and I think @herace did the same and actually fixed some things last time and submitted a PR in 2018.

[blurymind]

I would really love to roll my sleeves and add that feature, but I will first need to learn c++ and even figure out how to compile this. The author didn't leave many instructions.

It is an absolute shame how little exposure this project has, considering the potential

[herace]

Yeah thats a really good idea @blurymind, a json export will be a really good feature. Honestly not sure how the dragonbones json works. If i take the time to sit down and take a look at it im sure i can figure it out.

Also there is one big issue with AnimeEffects for animators and that is the workflow. You can most definitely produce something out of it but its a bit of a hassle to place items to the workspace one at a time. I think this is one of the main issue that turns some animators away form this application.

If this manage to be fixed then im sure AnimeEffects will gain more traction. Honestly i thought the original developer was taking a small hiatus but seems like like @Jose-Moreno said hes been mia since 2017 which is alarming (hope hes doing well). :(

I really do love AnimeEffects and like you said it has lots of potential, its ashamed really. Looks like there's still interest in this application so ill just dust off my fork and do some development on it.

[blurymind]

I think we might get a lot more developer interest if we can get it to export to something that game developers can use. The dragonbones file spec is fairly straightforward. You export two json files and an image atlas from db, that its used by dragonbones runtimes to render the animation.

@ndee85 created a dragonbones exporter for his coa tools extension on blender. It's in python, but perhaps can be of use to see how to do it? https://github.com/ndee85/coa_tools/blob/e9b9680f18b1cc400c98181a2a8c2a0c5d13db96/Blender/coa_tools/operators/exporter/export_dragonbones.py I wonder if some of its code can be borrowed :)

The biggest advantage of exporting to a dragonbones json spec is of course the already developed and battle tested dragonbones runtimes for various game engines. Those runtimes are totally open source and available to anyone to use - no license required, unlike the competition (spine, creature, etc)

[Jose-Moreno]

@herace I totally agree regarding the workflow, there needs to be a bit more concurrency and efficiency on several tasks. I had a list of thinks I wanted to have improved since I was tasked with evaluating software for a production back in 2017. I need to find that, or otherwise sit down again and review the whole software from an animation production perspective to help pinpoint additional bottlenecks in the workflow.

@blurymind

Don't worry, it seems it's using Qt 5 framework which would simplify the compilation process a lot, it's also indicated that the compiler can be MSVS, MINGW, GCC or Clang. I already have QT / MinGW setup on my computer to help test and debug other FOSS apps. I'll look into the compilation process (and a guide if possible), but it should be hopefully as easy as pressing the green play button in Qt Designer.

I see there are various "widgets" referenced, so this must be a Widget style application, not QML or any of the newer deployment types The Qt Company has implemented so there are more people capable of developing for it (the downside is that porting for mobile devices will be a tall order).

Also it seems that there are no UI files in this repository so that means all the interface must be done programatically, which is a bit of a pain, and should be worth thinking to migrate all the panels to dedicated UI files in a future revision.

If you guys need any testing done let me know, If it's about finding bugs and documenting them for reproduction I'll gladly help :+1:

[blurymind]

I am currently working on getting dragonbones runtime built into gdevelop - my experience is more with javascript :) After that is ready I will have a look here again. Not sure how much I can do, but I will start digging into the source and get it to compile with qt creator, then maybe try to learn some c++

@herace would be amazing if you can get it to export the json data :D Or even just starting the work on a basic exporter. We can continue developing in on your fork.

[herace]

@blurymind Cool sounds like a plan :) and also @Jose-Moreno thanks for the explanation on the Qt-5 framework. Going to install the necessary packages to get my environment up and running. Going to dedicated some of my free time on this project. Hope we can breath back interest in this project with our combined efforts. :)

[Jose-Moreno]

@blurymind @herace Sure thing, also, success :) This was built with Qt5.11.3 and MinGW 32-bit which was originally downloaded via default Qt installation component manager. By the way you don't need to create an account when using the installer, it's optional

Only had a single warning which is outstanding by most standards.

One thing though to consider for the future, is that to support enough legacy systems the developer(s) building the releases would have to deploy using Qt5.6 at least and use either a properly configured virtual machine or the actual machine (particularly for mac release), because Qt drops support every version, and this is particularly true with Apple and macOS. Since a lot of people still have 10.7 through 10.11 for OSX, it's important to consider that. For Windows XP / Vista I believe 5.6 would have to be used as well, however considering the OpenGL requirements even with the lowered 3.0 requirement on Herace's fork, people could only use it with computer from that last 6 to 8 years at most.

More info on the version support here: https://wiki.qt.io/PlatformSupport

Other than that setup should be fairly straightforward :v:

[herace]

@Jose-Moreno Okay awesome thats good to know. ill take a read on the qt wiki, also ill just revert my commits on the master branch back to the Qt5, with my fixes then. Originally i just wanted to able to run this on an old wacom tablet/laptop i have laying around. We'll stick with qt5 since compatibility is not really the main objective for now.

[blurymind]

I really like how it can load the character's library straight from one psd file's layers. You don't have to move them into place that way :)

@herace wouldnt it be better to keep your fixes for better backwards compatibility? That is unless you think it would be bad in the long term

[larpon]

@Jose-Moreno, @herace, @blurymind - I've been watching this for activity and trace of the original author (I hope he's alright). I think we should fork this. I've tried to implement #31 but as years has gone by I can't find the changes anymore. I had something working at some point. Anyway the software has a huge potential - let's keep it alive?!

[larpon]

I think we might need to organize this somehow.

Do you all have IRC? We could set a channel up on freenode and have a chat about how to proceed? I also have a few ideas to improve usability (and hackability). I've also successfully packed a build as an AppImage - which would help distribute the software a little easier on Linux etc.

edit join #animeeffects-dev on freenode

[blurymind]

We could fork this repository and even rebrand it as a new project (mangaBones?) Anime-effects is imo a vague name that doesn't really communicate what it does. Anime is an art style, effects is something people associate with compositing vfx or sound effects.

If you look at other similar apps - spine2d (part of skeleton), dragonbones (bones), creature2d (has bones)..

On the new repository we will be able to properly merge PRs and set up a readme with a proper project roadmap.

For the roadmap we can use trello, similar to how gdevelop does it: https://trello.com/b/qf0lM7k8/gdevelop-roadmap

I don't use irc and am currently a bit tied with adding dragonbones runtime to gdevelop and maintaining yarneditor, but can join the channel once in a while :)

Anyways, just some ideas on moving forward

In any case after such a long time of inactivity on this branch I don't think we have any other choice if we want to keep it alive. Getting coverage on sites like libregraphics and open source game engines (godot, gdevelop, etc) can help us get some exposure to it, but developers will not commit if the repo maintainer is not there to evaluate and merge their prs

[Jose-Moreno]

@Larpon Excellent, thank you for your enthusiasm. I am familiar with IRC but don't use it at all tbh, In the other project I help we have a discord bot to read the IRC chat and an IRC bot to allow the discord server writing back, I'll ask the owner to see how to enable that. For now IRC is fine though, I'll get a client to read IRC or something for now, no worries (and thanks for setting that up!)

@blurymind Hmm I'm not exactly opposed to change the name, but I think AnimeEffects was meant to capture the Japanese market which depends a LOT in (Adobe) After Effects (particularly in studio settings and hobbyist circles). This app really seemed it was looking to fill the place that the DUIK plugins have in After Effects (DUIK is also open-source btw and recently they are looking to work on plugins for Blender as well)

I wanted to leave ample time for the main developer appearing out of nowhere to resume work, not necessarily leave the project behind, so for now I think the branding can wait a bit as we would have a lot to do to get the fork going anyway.

However there is always a matter of urgency with FOSS, so if you guys are ok with this proposal, let's wait until next year. If the activity on the new fork doesn't bring his attention to continue working on this, then let's re-brand the project as suggested and simply hold a candle to continue his legacy. If he ever resumes work after that, then kindly PR all the improvements for him to cherry pick so the projects stay as siblings with a different flavor and not as competitive tools. Let me know what you think of that.

As for names, well I agree on the "bones" part, but unfortunately Manga has a different connotation in the west than it does in the east (Manga is simply the word for "Comic", but around here is anything that comes from South East Asia)

If we're going about names I think something that is catchy and communicates the core function of the software (even if it is expanded to be more complex later on). Maybe something like Puppetry DollMaster , SwiftBones or something to that effect.

I have trello so I don't have an issue using it, however Github now has better integration with its own Kanban board system (similar to trello) so that could help any developer who doesn't want to have an additional account to inspect the roadmap or what's in progress. It'd be good if everything could be contained in a single place.

Also we can setup github pages to get the website running and hold the documentation as well as a download page to link directly to the release tag binaries. This should be setup preferably in a different repo within the same organization.

I'd gladly setup a discord server to work like a temp forum considering traditional forums are starting to fade away and I don't want to deal with server stuff, but if anyone has a better suggestion please mention it :+1:

Lastly I've always wanted this app to integrate with other apps, particularly Pencil2D (pre-planning), Krita (bitmap workflows) and Synfig (vector workflows), if we could get some interest on having exporters from those apps for cross compatibility between applications, that'd be great, and considering at least Krita and Synfig also can be made to work with Python it could be relatively easy to make the plugins ourselves if needed.

[larpon]

The reason I suggest IRC is that there's a better chance that information won't get lost and a chance to log conversation history easily, letting us search in history etc. There's a reason that big projects use IRC as their main developer (and support) channels (krita, godot engine, kde and many more).

It's the same story with forums, they might be old fashioned - but they keep relevant information gathered in the same place for people to find answers more easily (forums are really good for search engines to plough through). Plus you're not in doubt where to go to for help. And yes we'll have to find a way to host it.

Now, of course it's perfectly fine that the community spin off "unofficial" channels on discord or matrix - but I'm not sure it should be the official place to come and ask for help. I know because I'm currently contributing to Godot and write plugins for Krita so I've seen the advantages of keeping things on a reliable and battle tested platform. It's no quite a big deal - but in the long run I think you'd want to filter out the noise from Gifs, emoticons and pictures... it's usually irrelevant noise.

A live example is the Godot game engine - their community is scattered on many different platforms, which is both good and bad because it's making it extremely hard to search for questions that is already answered etc.

I know people are jumping boats all the time to new and flashy networks with emoticons and cat gifs - but that's not important compared to overview, readability and reliability IMHO.

But if we can connect to IRC from Discord and vice versa, I'm fine. Just thinking we need a better place to discuss than in this fairly hi-jacked thread :smile:

---

I also thought about the name. Maybe we should wait until the project branch too far away from the original work? I mean; Let's see how much work will actually get done and decide from there? In respect to @hidefuku 's work so far.

---

In regards to trello/github projects - I have absolutely no preference. Mainly because I've never used it :)

---

A few ideas I've had for the future of the software:

• Separate the player and format into a library/runtime that can be integrated with - like the Spine runtimes or the DragonBones integration. It's probably a huge deal (untie core parts from Qt etc.) but I think it'll help rocket the project a lot.
• Open up/change the file format. Make it easier to "hack" the format (I'm thinking something like Krita's .kra format which are simply zip files containing both binary and text data) - I once saved hours of work because of this :)
• We need to keep the license in mind... GPLv3 is not everyone's favourite :slightly_smiling_face:

---

It looks like there's enough interest to try and kick this fork off

[blurymind]

Some good discussion happening here, eventhough a bit off topic from the request :)

The suggestion to change the name was just a suggestion of course. Yes we should probably wait a year or two and see if the original author will come back, but having the master branch of the project look so abandoned (last commit several years ago) gives off a bad impression on new devs. This is why I suggested to start it out as another project - so we have a master branch that does not look neglected.

Most of the times when you hear about a cool open source project, you go and see the master branch. The forks are usually ignored and having many of them makes it difficult to know which one is the one that has most contributions.

It also makes it less straightforward to contribute to a fork instead of a master branch. You fork the fork in order to commit to that fork? You have to find the specific one to push your changes to.

That is why my suggestion was to rebrand it. Similar to what happened to another animation app, called pencil. The original developer abandoned at one point. After no activity for years, a bunch of the passionate users rebranded it as pencil2d, then continued work on that. But waiting for him to come back to it for years before doing the rebrand did a lot of damage to pencil. The code which became outdated started failing to compile and was harder and harder to maintain. A big chunk of pencil's community left it due to the neglect and alot of them didn't pick up pencil2d, didn't even know about it because the original pencil repo users had no way of changing the readme to send people to their new repository.

If the original author comes back, he can still pick up the updates. If he comes back we can make a PR for him to review. :) My suggestion is informed by what happened to pencil2d and try to minimize damages

[larpon]

I totally see your point. It's probably good with a rebrand early in the process then.

'SwiftBones' is my favourite so far BTW 🙂

[Jose-Moreno]

@Larpon Yeah I have no problem with IRC, although I always thought you couldn't read the logs back though :open_mouth: I downloaded the KVIRC client and logged-in last night and will gladly log from time to time (when I remember to do so :yum: )

Same with forums, if someone has a way to freely host discourse powered forums, i'm familiar with the system as I moderate similar forums elsewhere, so I can help with that.

I know people are not fond of the license. I'm not against keeping it GPLv3 as this is an open-source project and at the same time I doubt we can change it to anything else because the same license is meant to keep the project free & open forever. If we wanted to re-license to a more liberal license like MIT for example, we'd need express approval from the author and other accounted contributors and I don't see that happening anytime soon.

Lastly your proposals on creating a library / runtime and format openness sound great, i'd really like to see this happen in the foreseeable future :smile:

@blurymind It's funny you mention Pencil/2D. For sure getting abandoned at such a critical point where it had enough support from its community but also had a serious amount of bugs and missing features was what doomed it at first. After Pencil got too many forks, Pencil2D was an effort spearheaded by Chris Share, and later Matt Chang, to try to gather all of those into a single product again. So the others have extra context I'll just leave this article that explains the initial mayhem: https://lwn.net/Articles/554174/

While I understand the comparison, I feel we have slightly different problem here as this project simply had an initial spurt of popularity, but later went away, and there weren't even as many devs interested initially judging by the number of PR's & forks (which by rule of thumb about two-thirds of devs often end up not working on the fork after the initial split)

That said, I honestly agree with you on the re-branding topic because of this precedent, but I also agree with Larpon. We should try to see how far we can get with the initial fork effort, reeling in devs along the way, and afterwards, once we have enough traction and a solid application working, then make the choice to transmigrate the project to a new organization (and a new name), particularly because of advertisement, as once we start promoting the app to users and potential community sponsors , it's going to be tough to change the name and the image due to the principles of brand positioning.

So after all we've said we have to ask:

• [ ] Who's going to host the initial fork? (@herace was the prime candidate IIRC)
• [ ] Or are we going to create a new organization first to host the initial mirror fork while preparing for possible transmigration anyway?
• [ ] Who's going to do what in the organization? For example my strengths lie in: Technical Customer Support, Beta Testing, Community Management, and I can help with other miscellaneous tasks such as Basic Web Design & Programming, but I'm lacking in the "hardcore" programming department despite understanding the foundations :stuck_out_tongue_closed_eyes: .
• [ ] When do we start?

[herace]

Oh wow, look like its gotten really lively the last time i checked in :D and also hey @Larpon :wave: very cool for you joining in :grin:

Here are my thoughts of what have been discussed so far. (Also I made some fixes on AnimeEffects, take a look when you have time https://github.com/herace/AnimeEffects/pull/1 )

:building_construction: Rebranding:

When it comes to rebranding i would say give the original developer by the end of January of 2020, maybe by chance the original developer will look back on this project and dust it off as a new years goal or something. according to the article the original dev went mia for 4 years, so 3~ months wont hurt.

its definitely worth the wait and see if the original dev return since he knows the ins and out of this project, plus the 3 odd months will give us time to plan things out if he doesn't return.

Thou im not a fan of rebranding but after reading @blurymind said and that article @Jose-Moreno provided I see why that's an important matter. Not saying rebranding will be a last resort, but treating it as a Plan B if we get no response.

Also I have some name suggestions as well

• ToonEffects - A safe name that clearly indicates that its a fork / continuation of AnimeEffects

:fork_and_knife: Hosting: I like @Jose-Moreno idea on creating a new "organization" on git and send invites to interested developers and of course send an invite to the original developer as well.

I think the name of the organization will be "AnimeEffects Devs" for the time being until the pass due date of Jan of 2020, then simply remaining it to the agreed rebranding name.

I guess the organization will fork my branch since i haven't see any recent development on this projects to my knowledge and then work on that new fork.

Hosting this way will make the project more democratic and safe, you never know when a dev will neglect a project wither they just lost interest or gotten terminally ill :(

Ill leave it as that for now, i want to talk about about communication and other stuff but this comment is getting long enough. Also i do have to agree with @blurymind this is trailing off the original issue, another issue titling "AnimeEffects Hiatus" and do further discussion there since this is a legit issue. @Jose-Moreno i think you should create it since you brought concern about this. :+1: PS. Also dont forget to link this issue to the new one

[larpon]

Hi @herace 👋 I actually had a fork at one point as well. But it seem I deleted it for some unknown reason - maybe because I deemed the project inactive. And yes, let's try and organize the forking discussion in a better manner.

[blurymind]

Documentation https://developer.egret.com/en/apidoc/index/name/dragonBones.EgretEvent

also on the data format https://github.com/DragonBones/DragonBonesJS/blob/master/docs/DragonBones_5.0_data_format_zh.md

There is a Dragonbones C++ runtime here https://github.com/DragonBones/DragonBonesCPP