I was surprised by this but then maybe I’m using AnimComposer “wrong”. So I decided to see how the community is doing these things.
I have a case where I will setup blendable actions any put them in a layer that masks off part of the rig. Think, an action to blend between looking up and looking down while still walking. The “Look” blend action will mask off the relevant bones in its layer and then the app can set the blend to look up or down.
So far this works ok even if setup might be a bit awkward sometimes.
But if you save the j3o, none of this is saved. Only AnimClips are saved.
This makes it seem like AnimComposer only cares about AnimClips and anything else is “runtime temporary data”. This is why I thought that maybe I’m using AnimComposer incorrectly. (Also may be why we cannot ask for the action names on an AnimComposer.)
However, given that setting up things like blended actions, action sequences, etc. can be quite a bit of code that is then otherwise accessible just by name, it’s a shame that this setup is not saved.
Well, there was a discussion on this but it concluded that tweens are not the things we want to save but we do need to have a set of objects (i.e TweenBuilder things) that are savable and are used to build the tweens at runtime, or else we should create them in code for example in groovy or pure java.
I tried to follow TweenBuilder things in my editor but it turned out to be complicated and I found creating them in code is much easier.
I just needed to enable the code Hot Reload feature in IDE so there was no need for an editor even;)
Yeah… savable tweens. In the general case turns out to be quite complicated even if in the “anim composer” case it would be within reason.
I thought about hacking action and tween “savability” into my local JME fork but it does turn out to be quite a deep hole. And as it turns out, because of other reasons (and JME limitations) I already wrapped the JME stuff in a separate Rig class that I serialize. To that I can add whatever other definitions that I want and create the real actions on load.
It’s just a shame because there is quite a bit of very skeleton-specific code involved in wiring these up. This is a bit different than adding sparks + sound to a blade swing.
Also another case where we’d have more options of JME had just used the perfectly good serialization already built into Java instead of rolling its own.