New script to import layout from Spine JSON (Affinity, Krita, Spine, Photoshop, AfterEffects, Gimp etc.)

[mmmaarten]

Hi Folks, I just published my Spine importer (also to import layers from Affinity and Krita) Script on mohoscripts.com

It can import all layers as cropped images from Affinity Photo and Designer completely and generates layers with positioned images in Moho. With the spine.json exporter script for Krita it should also work with Krita's spine.json exports to make it usable for Krita too (see mohoscripts page for the script). Also it imports already quite a lot from spine.json files generated by Spine itself (including hierarchical transformations through the bone tree and even tinting of images)!

(the next version will probably also import the bones from spine. I already started on that and it looks promising, but I have some other things to do now )

See mohoscripts.com description for more information.

If people could test this on Apple machines I'm happy to hear if all paths are working for you. As I only can test on Windows.

Have fun with it

It's here:
https://mohoscripts.com/script/wp_spine_import

IMPORT FROM AFFINITY PHOTO OR DESIGNER
Short tutorial video on how to use the script to import Affinity (Photo/Designer) Layers as cropped images in Moho:



IMPORT FROM KRITA
Short tutorial video on how to use the script to import Krita Layers as cropped images in Moho:
(the exporter even has special layer naming features to define bones in Krita, more info here on the readme of the export script here: https://github.com/DanStout/KritaToSpine)



IMPORT FROM SPINE
Short tutorial video on how to use the script to import Region Attachments (images) and their transformations at the setup pose from Spine as Moho 14 Layers:



MPORT FROM PHOTOSHOP, AFTER EFFECTS, GIMP AND MORE
There are Spine JSON exporters around for Photoshop, After Effects, Gimp and other software too. So basically any software you have and has an export script to export to Spine JSON fileformat is with this script now able to export to Moho. Esoteric Software, the creators of Spine, have a repository with some exporter scripts for several programs here: https://github.com/EsotericSoftware/spine-scripts

[mohgirl]

amazing！

[mmmaarten]

amazing！

Thanks! Hope you enjoy it!

[Daxel]

very cool! thanks for sharing.

[mmmaarten]

very cool! thanks for sharing.

Thanks Daxel! Nice to hear from you!

[mmmaarten]

Alright! Got it working here! If there is bone data in the file, like exports from Spine, the next version of the Import from Spine.JSON script will also import the bones and create the same skeleton in Moho

The only things that won't be supported on the bones:
- shearing on bones --> this concept doesn't exist in Moho
- different bone scaling on x and y --> Moho only supports a single scale per bone (equal for x and y). It imports, but will use the x-scale of a bone as bone scale in moho.

I consider those rare cases tho. In normal situations all bones should import fine now.

It imports the bone tree completely with hierarchy/parenting, hierarcal transforms/positions, rotations and scale!

[mmmaarten]

Version 1.1.0 with the bones support is live now on mohoscripts.com

[mmmaarten]

For those working with Krita; I've just created a quick tutorial video on how to import layers from Krita now too (see opening post), including instructions on how to install the Krita-To-Spine Krita script

BTW you can even define special naming in your Krita layers like [bone]MyBone that the Krita-To-Spine script recognises and converts to actual bone data that the Moho importer than uses to create bones! Not sure if very useful in Moho and I think it's easier to just draw bones in Moho in that case, but just so you know that that works too with the importer (more info on that on the page of the exporter here: https://github.com/DanStout/KritaToSpine)

[Daxel]

that's impressive! Again thanks for sharing.

As I'm getting interested in the gaming industry I wonder if these could be used somehow to import moho files into spine, because spine has plugins for both unity and godot so it could act like a bridge to use our moho rigs in these game engines. I guess I'm dreaming too much.

[mmmaarten]

that's impressive! Again thanks for sharing.

As I'm getting interested in the gaming industry I wonder if these could be used somehow to import moho files into spine, because spine has plugins for both unity and godot so it could act like a bridge to use our moho rigs in these game engines. I guess I'm dreaming too much.

Always good to dream!
However, the script doesn't export from Moho to Spine but from spine JSON fileformat to Moho. This way you can import from all programs that are able to produce this Spine JSON file format. Like Affinity Photo, Affinity Designer, Krita, Spine and more software having scripts to export to Spine JSON, like Photoshop, Gimp etc.

Going from Moho to Spine could never been fully done, because of the way Moho works. Moho and Spine work completely different. Among other things Moho doesn't have a real and single relationship between the image layers and the bones. These are two separated instances and trees. There's a group layer with whatever structure of image layers etc. underneight, which don't have a 1-on-1 relationship with the bone tree/skeleton per se. Yes you can bind images to bones, but it works way differently. Also you can bind all image layers to all bones at the same time or any combination or mixture of that. That could never be converted to Spine where images are always bound to bones and always have a 1-on-1 relationship to a single bone (unless there's a mesh involved, but that's yet a whole other story).

Converting only the bone tree to spine JSON to import it in Spine could be created with a script. But that would be about it. Not very useful and beneficial for the amount of work that goes into writing such a script and the low chance that anybody would ever use it. It was already quite a lot of work to figure out and convert the Spine bone tree to Moho's bone tree and layers tree (which I did for free and took a lot of time), because both systems work completely different and it was quite a puzzle. So I have no plans on doing the same the other way around. Especially because I don't think anybody would really use it.

Also, the Moho fileformat itself is already a zipped JSON file. So all data of the Moho fileformat is already easily readable and parseble by any script, just like a Spine JSON file. So why create another exporter if it's already in the moho file?

The script I wrote now however IS very useful for a lot of people; users of Affinity Photo, Designer, Krita, Spine, Photoshop, AfterEffects etc. could all benefit and this wasn't possible yet. And it makes setting up a character in Moho a breath of fresh air when designed in one of those programs, compared to how many hours the same thing took without the script. Where we needed to import and create layers per image and than position all these images manually one by one.

Hope this makes sense!

BTW good luck in the gaming industry!

[Daxel]

I understood half of what you said but I get the idea. I didn't want it to sound like a request, I'm just interested in the idea of using Moho rigs in game engines. But now I think it doesn't actually make much sense because it would be two steps, two conversions, from Moho to Spine and from Spine to Godot/Unity, when the ideal solution would be to have a single Moho to game engine converter like the official FBX one but working nicely.

I see many interesting open source plugins and tools make arround Godot, maybe one day someone will make one to convert Moho files to glTF, that will be mantained by the community. But I'm not sure if that is even possible to do from just the Moho file.

[mmmaarten]

I understood half of what you said but I get the idea. I didn't want it to sound like a request, I'm just interested in the idea of using Moho rigs in game engines. But now I think it doesn't actually make much sense because it would be two steps, two conversions, from Moho to Spine and from Spine to Godot/Unity, when the ideal solution would be to have a single Moho to game engine converter like the official FBX one but working nicely.

I see many interesting open source plugins and tools make arround Godot, maybe one day someone will make one to convert Moho files to glTF, that will be mantained by the community. But I'm not sure if that is even possible to do from just the Moho file.

No worries. I didn't think you made a request. I was just explaining why it doesn't export from Moho. Sorry if I didn't explain well.

With respect tho; it looks like you're missing what Spine is about. Spine is especially made for games and you normally create animations for games that use spine runtimes in the Spine editor. It doesn't make sense to make animations in Moho for games at all because Moho outputs video, which not only uses too much performance in games, it's also static, so not dynamic. It has no interactive data.

Spine outputs data of the rig and animation (etc.) to let the game engine code interpret that data and replay the animation in real time and even change everything in the animation at real time. Spine output is therefor not only dynamic and realtime, it's also way more optimized because it only needs a few images to setup the rig at runtime, instead of loading a complete video of a thousand frames. And therefor is able to adjust to states in games instantly, change positions/transformations etc. to cursors, other characters in the game, view directions etc.. It can also use the same rigs and/or animations for different characters/skins (even switch between them), is able to seamlessly morph/mix from one animation to the next (like from an idle animation to a jump or run animation) at any given time without any visible stutter or jump etc. Things that Moho could never do, simply because of the way it's (purposefully) built. Moho doesn't need all that. But therefor it's also (logically) impossible to create such setups and animations in Moho, even if we had a spine.json output.

The Spine editor you use to create 2d or 2,5d animations for games. It has a lot of specialistic options for creating seamless loops with overlaps etc. and you can attach boundingboxes, masks etc. to bones to use all this live in games and the next version will have very special physics that are repeatable. Moho doesn't have all that. And doesn't need it, because it's not made for games. Moho is built for animation videos and movies and has a different toolbox for that and is having features for that purpose and can do a lot that Spine cannot, because movies have other needs. Like fbf animation etc. So long story short; if you want to work in the game industry where Spine runtimes are uesd; learn the Spine editor.

This goes a bit offtopic in this thread tho (which is my bad).

Hope this makes sense and helps tho. Have a nice weekend!

[Daxel]

I've used spine time ago, and previously flash that can work dynamically too, I tried dragonbones (the open source spine) and have also made some animations using Unity's and Godot's 2D bone and animation systems.

I usually tend to prefer using a powerful animation program like Moho to make more complex animations as sprites, but I also like the interactivity and blending capabilities of skeletal in-game systems so I like to make like a hybrid between those two, using mostly sprites but also interactive features when they are strictly needed, and many times that doesn't even imply using the skeletal system, but just a function to point your "arm with gun" sprite layer to the mouse cursor and things like that.

I haven't experienced an important difference in performance between pure sprite or pure 2D skeletal in-game systems. With modern graphic apis like Vulkan (Godot) draw calls are super cheap and with less modern apis (for mobile or web) we make sure to use atlasses that have all the sprites on the same image so the rendering cost is close to nothing. Dynamic skeletal systems use less images but much more calculations for the skeletal system and interactive features like collisions, "point at", etc, so I think in the end dynamic animation has a slightly higher cost in performance, but a way smaller size on disk which is actually relevant sometimes (web and mobile).

Moho can export to FBX which can be imported in game engines to be used dynamically. It never supported every Moho feature, but at least the basics: all the drawings and the skeleton and the animations. And that's what I am interested in. But sadly it doesn't work well so currently there is no way to use Moho rigs directly in a game engine, dynamically. I think that's a pity because it could take a piece of Spine's marketshare.

Have a nice weekend too!

[mohgirl]

nice!

[Steve Matthew]

I've used spine time ago, and previously flash that can work dynamically too, I tried dragonbones (the open source spine) and have also made some animations using Unity's and Godot's 2D bone and animation systems.

I usually tend to prefer using a powerful animation program like Moho to make more complex animations as sprites, but I also like the interactivity and blending capabilities of skeletal in-game systems so I like to make like a hybrid between those two, using mostly sprites but also interactive features when they are strictly needed, and many times that doesn't even imply using the skeletal system, but just a function to point your "arm with gun" sprite layer to the mouse cursor and things like that.

I haven't experienced an important difference in performance between pure sprite or pure 2D skeletal in-game systems. With modern graphic apis like Vulkan (Godot) draw calls are super cheap and with less modern apis (for mobile or web) we make sure to use atlasses that have all the sprites on the same image so the rendering cost is close to nothing. Dynamic skeletal systems use less images but much more calculations for the skeletal system and interactive features like collisions, "point at", etc, so I think in the end dynamic animation has a slightly higher cost in performance, but a way smaller size on disk which is actually relevant sometimes (web and mobile).

Moho can export to FBX which can be imported in game engines to be used dynamically. It never supported every Moho feature, but at least the basics: all the drawings and the skeleton and the animations. And that's what I am interested in. But sadly it doesn't work well so currently there is no way to use Moho rigs directly in a game engine, dynamically. I think that's a pity because it could take a piece of Spine's marketshare.

Have a nice weekend too!

It's fascinating to hear about your diverse experience with animation tools! I totally get the appeal of a hybrid approach, combining the best of both sprite and skeletal systems. The balance between interactivity and performance optimization is crucial.