Keyframe-based animation support #191
Commits on Aug 4, 2018
-
-
Animation: make interpolation result type non-implicit.
TrackView can, for example, have quaternions encoded as a 10-10-10-2 integer, but the result should still be a Quaternion.
-
-
Animation: added Interpolation enum and interpolatorFor() helper.
Will be used to supply general desired interpolation method to tracks to make it possible for the user to decide about a particular interpolator function for given type.
-
-
Animation: make it possible to specify Track interpolator via an enum.
Or via an enum + func ptr. Main goal of this is to provide a hint to users who want to supply their own interpolator (for example with a different perf/correctness tradeoff, or a optimized/inlined/batch version etc.).
-
-
Trade: convenience default constructor for AnimationTrackData.
Otherwise one would need to use a NoInit Array constructor and that would cause dangling deleter function pointer call after the plugin gets unloaded.
-
Doxygen. Doxygen IS BROKEN BEYOND REPAIR.
I introduced *strong* enum with values, in a subnamespace, that have the same name as completely unrelated typedefs. Guess what?! It breaks ALL LINKS TO THOSE TYPEDEFS! **EVERYWHERE!!!**
-
-
-
-
Animation: TrackViewStorage doesn't need to be *that* type-erased.
Moreover, this will prevent from passing e.g. integer-based keys to Trade::AnimationData. And this also now allows me to add duration() to Trade::AnimationData. I also moved all accessors that don't need a concrete value type to this base class.
-
Trade: provide untyped access to tracks in AnimationData.
This reduces the templated code a bit, as I moved the index assertion to the *.cpp file. Also the function now returns a reference to avoid needless copies -- it's a view, but still quite a heavy view.
-
Animation: make TrackView constructors implicit.
For consistency with all other views such as Containers::ArrayView as these are all relatively light types and so the construction should be lightweight as well. OTOH, Track constructors are still explicit because they're heavy and the user should experience the heaviness firsthand.
-
Animation: benchmark TrackView to verify my performance assumptions.
Turns out my performance assumptions were correct! :)
-
-
Animation: added Player::addRawCallback().
Provides some further optimization opportunities.
-
Trade: make it possible to use all vector type variations for animati…
…ons. Note that I don't mean all possible underlying types, just all possible vector classes. This is needed for splines etc. which may be templated and have result type a generic vector, for example.
-
-
Animation: Player move is not noexcept because compilers are weird to…
…day. I managed to work around that for Emscripten 1.38.5 by adding an explicit definition of noexcept Player::Track copy constructor/assignment, but that didn't solve anything for Emscripten, iOS or Android. Since I can't reproduce that on *anything* I have on this machine and it seems that the problem somehow just goes away when using a more recent Clang, I decided to just remove the noexcept specifier altogether. I had a temptation to make it noexcept everywhere except Clang, but that might add potential portability issues (code that works with GCC would suddenly break on Clang without any clear reason).
-
Animation: put a reminder for myself.
At the moment, with the major use case, which is playing back glTF animations, one can't use atStrict() because there Extrapolation is specified to be always Constant. The atStrict() function behaves as Extrapolate and one would need to patch the imported tracks to add explicit keyframes at the beginning/end of the duration that emulate the Constant behavior.
-
Animation: properly handle Player with empty duration.
Turns out with current design we can allow fun things even for empty durations. I like this.
-
Animation: make Player usable on MSVC.
MSVC 2015 and 2017 is clueless when it comes to trying to deduce the template parameters (C2893: Failed to specialize function template). It works when calling add<V, R> explicitly, but that makes the API hard to use and inconsistent between platforms. The only possible workaround is to make add() take *anything*, casting it to proper TrackView type and then calling add() with explicit template parameters. This also neatly resolves the Track/TrackView overload, as the static_cast is either a no-op or it invokes the conversion operator on Track. The original code also reportedly makes the Intellisense freezing like hell and adding this overload fixes the freezes. Three birds with one stone. The Player class definition is now full of typedefs, with the amount of comments about why the typedefs are there much bigger than the actual code. Oh well.
-
-
Animation: work around an ICE involving std::chrono on MSVC 2017.
I lost two hours on pinpointing this one. Gah.
-
-
doc: disable a problematic code snippet on WinRT.
It has warnings-as-errors and thus doesn't like that one uninitialized object. I need the ELLIPSIS macro already.
