This PR adds the capaibility to run Stroyteller studio from the command
line, rendering the result to images. This is the basic functionality,
and there are somethings that I am saving for later when we make this a
more fully fledged feature.
Limitations:
- Right now, you cannot do image output resolutions that aren't 2^n.
This is a bug I plan on tackling later.
If you have questions on how the command line works, use the --help
argument.
Let me know what you think!
---------
Co-authored-by: Danny McGee <dannymcgee@gmail.com>
This PR adds support for Mixamo FBX imports (via backend conversion to
glTF/glB) and some miscellaneous improvements to the animation systems.
### User-facing improvements
* Retargeting math has been fixed to eliminate jittering issues
* Retargeter can now handle animated bone translations when present
(generally this is only used for root motion)
### Housekeeping / Code improvements
* Animation-related components and system logic have been moved to a
dedicated `anim` module and `AnimPlugin`
* Retargeting stuff has been moved from the `bvh` module to
`anim::retargeting`
* Component-based solution for marking an entity as an animation
retargeting source makes it easy to extend the retargeting functionality
to new types of source animations
### Limitations
Currently the code assumes that there will be at most one animation
source at a time. That single animation (if present) will be retargeted
to all other skeletons in the scene. A component-based solution for
directing a specific target skeleton to use a specific source animation
is possible, but will require some additional consideration around the
implementation design for the read-only "viewer" modes.
### Test animations:
* Hip-Hop Dancing (Mixamo): ?mode=viewer&mixamo=mocap/hip-hop-dancing.gltf
* Shuffle (MocapNET): ?mode=viewer&bvh=mocap/shuffle.bvh
* Scott (MocapNET): ?mode=viewer&bvh=mocap/scott.bvh
* Scott 1 (MocapNET): ?mode=viewer&bvh=mocap/scott1.bvh
The initial BVH retargeting solution produced very jittery results. Much
of that jitter was eliminated by using linear interpolation between
frames instead of immediate stepped transitions, but some jittering
still remained, particularly noticeable in the finger motions.
This PR largely fixes remaining jitter issues by making a few changes:
#### Frame-time quantization
Previously, we had been using the `BvhAnim::timer` field incorrectly, by
manually resetting it after `Timer::just_finished` returned `true`, and
returning `0.0` as the interpolation parameter for that frame. This
resulted in a herky-jerky animation due to misalignment between the BVH
animation's frame time and the actual application refresh rate, meaning
we would lose fractions of a frame every time the timer elapsed and the
frame was incremented. This PR addresses that by never calling
`Timer::reset` and always using `Timer::percent` for the interpolation
parameter.
#### Matrix instability
This PR refactors the retargeting system to operate on `Affine3A`
matrices instead of `Mat4`s. `Affine3A` represents a SIMD-optimized 3x3
matrix + a translation vector, so using it provides a small performance
boost in addition to being slightly more numerically stable.
Additionally, we now periodically re-orthonormalize the 3x3 matrices
in-between operations to mitigate drifting due to the accumulation of
floating-point errors.
This PR adds support for BVH animation files, with a custom animation
player and retargeting solution for our Blender Rigify-based skeletal
meshes.
---------
Co-authored-by: Brooks Palin <brookspalin710@gmail.com>
Brooks Palin