-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify sampled curves #141
Comments
I was able to reuse this mit licensed code. https://github.com/robertjoosten/maya-keyframe-reduction It works very well. |
There's also state of the art research here: C2 Continuity!!! |
Thanks! The problem is that glTF uses simple y=at³ + bt² + ct +d piecewise cubic polynomials. Maya's curves and the one in the papers are real 2D curves, e.g. both X and Y are function of the curve parameter t... This allows the user to have a lot of freedom creating animation curves, but it is very expensive to interpolate, e.g. to find Y for a give time X value, you first need to find the curve parameter from that X, and that is slow. Too slow for games. Actually the glTF spec explicitly mentioned this. Nevertheless the papers and code you provided look very very interesting, and I will certainly look into these. |
@ziriax As far as I'm aware currently frames are always stored for every frame - even when e.g. a part of the animation is static for a few frames. If I were to implement logic to filter out those keys that are redundant (e.g. previous + next frame are not different than current frame) where should that logic roughly be implemented? |
I think NodeAnimation.cpp, finish method. It already has a TODO for this |
When the animation is hand made, many of the curves are very smooth. Therefore, it should be possible to reduce the number of keyframes.
The exporter should fit a cubic spline to the curves, maybe using the keyframes from the artists as knob hint positions.
Maybe Maya's built-in key reducers could be used for this? See MEL's simplify command
The idea is as follows:
The fitting should start at the root node.
The small error introduced by the fitted curve should be corrected by modifying the child node local transforms in such a way that they are identical to their original world transforms.
Ideally the error is measured by applying skinning and computing the error at the vertices. However, since the same rig can be used for multiple characters, this is not a perfect approach, so it might be better to just check the errors on the world transforms (
origin
point andorigin + length*direction
point)An extension could be provided that stores the differences between the original samples and fitted curve, using very few bits. This would also work for mocap
An extension could store the logarithm of the quaternion curves (as quaternions should be linearly blended in their log space, GTLF incorrectly blend quaternions linearly). See also this code
For other approaches, see also ACL, gltfPack
I wasn't able to find a viewer for the animation curves, so add one too.
The text was updated successfully, but these errors were encountered: