I am absolutely convinced that the use of pre-packaged animations in a graphics program (blender or 3ds Max) is much cheaper, in terms of speed of execution, rather than the definition of the bones of a model as a "joint" and the command of their movement with Javascript code.
It seems to me that the animation contains (already calculated) the coordinates in which to show the model's meches and their appearance deformed by the movement, while the movement commands through the script call up routines in order to define the deformation of the meches in real time and therefore require more "work" from the GPU.
But ... getting "beautiful" animations is not as easy as it might seem ...
It is not enough to put one foot after another ... there is a small amount of refinement necessary to create a "realistic" movement that is discovered only when the first tests are started ...
To find out that, in the laboratories of software-house video games, and in film studios, it is preferable to record the movements of real actors in black suit and white balls in the joints reveals the difficulty of this work.
Of course, our ambitions are amateur, so we suppose we managed to create enough animations for our purpose.
The next step is to import the animation into Outerra.
From my tests I think it is important that the model has a UNIQUE armature and that all the bones have a common origin (and they are all linked together).
It's also important that the animation stays within 200-250 frames (longer animations have always caused me a loading error).
By building the FBX (I have kept the default settings in Blender) you should get a file that can be successfully interpreted by the FBX importer of Outerra.
(An eventual passage in the "Autodesk Fbx Converter" can help).
Browsing through the "hero.js" file (program "script" folder) I learned the commands to insert one or more animations on the Outerra stack and execute them.
A rock that I could not overcome is the possibility to delete the stack to enter a new animation and continue to alternate the animations to get different and appropriate movements.
Perhaps a more in-depth study could solve even if ... at this point ... a little bit of indications from angrypig would definitely be more useful ...
Now, however, I would like to deepen the other animation system that can be used in Outerra: the definition of the bones of an armature as a "joint" and the command of movements using the "rotate_joint" and "move_joint" methods of the geomob.
I consider this system to be hugely broader than the use of pre-constructed animations.
Being amateurs, therefore unrelated to the need for professional speed performance, we can afford to explore the use of this method that offers us the ability to program every type of movement and adapt it to any kind of circumstances!
I imagine a program in which there is a function for each bone to move ... this function limits the movement of the bone within the physiological limits of the joint (as in reality) ... receives incoming values (and is recalled) from the function of movement of the bone on which it depends ... possesses (possibly) a short neural sub-routine that refines, over time, the coefficients of the movement choosing the most efficient ones based on experience ...
All dreams, of course, easy to propose but much less easy to achieve, yet ... full of enormous charm.
But it is precisely the possibility that offers Outerra to be able to achieve something like this and the consideration of being able to "play" with these ideas without the apprehension of having to produce "professional results" that leads me to think that this method of "total programming" it would have to be explored and deepened more in the pre-constructed (more limiting) method of animations.