Hey! I love this tool. The turntable feature is awesome and I'm attempting to make use of it for a tower-defense thing I haven't yet really thought out.
While working on that, I set up a neat little script that automates importing these animations into godot using the .json Super super super handy to have that! If this project goes well I might think about making that a standalone addon for godot. It'd... probably need some quality of life changes to really be usable in any arbitrary project though.
Here's some feature requests if you're interested:
- Some way of denoting loops in the json might be nice? Right now I'm using animation names to work that out, ending them in "-loop" and checking it on import. This is similar to how blender imports work in godot which is fine.
- Arbitrary rotations for the turntable mode. If I were to want to make an isometric game, I imagine I'd want slightly different angles for the 4/8 rotations. Or, if I were making a hexagonal top down game, even weirder angles than that. Maybe some combo of rotation_count and rotation_offset, or even more flexible, just a straight array list of rotations to use (with presets for the most common).
- Option to disable diffuse_path/normal_path in json output, or make them relative. This one's more for working with a team, as other members probably won't have my exact file system to use that file path, and I may not want to share my system username or something weird like that.
- Per-animation FPS. This is admittedly fancy, but some animations require more frames than others and having a universal frame rate can make things feel a bit weird. Running vs idle for example.
- Culling duplicate frames. This requires per-frame fps data, so very tricky and a massive ask. If I were to make an animation that holds several frames (via like, no interpolation of frames in blender), this will create duplicate frames in the animation. sometimes those frames are like, just a few pixels off though so I imagine this might be a tricky problem to solve. Doing it manually kind of messes up the importing, so I've opted to just... not do this, but I think it would really open up the use cases a ton.
Aside from that, an oddity I've noticed that might just be my own lack of understanding on how animations work and all that: An animation that moves the root bone can cause animations that play after it be offset by the root motion. I think this is because the transforms aren't reset between animations, and that might be intended, but it can cause some funky behavior. It seems to require keyframing everything at the beginning of animations to really resolve that, and that might be a good idea anyway, I'm unsure what the standard is for that kind of thing but I'm new to it so