Qt3D-Animation-Framework

En Ar Bg De El Es Fa Fi Fr Hi Hu It Ja Kn Ko Ms Nl Pl Pt Ru Sq Th Tr Uk Zh

Details

• Summary: Add efficient support for various kinds of animation to Qt 3D
• Project lead: Antti Maatta & Kevin Ottens (ervin)
• Project participant: Antti Määttä (anmaatta)
• Branch: wip/animation

Goals

• Perform animations on the backend of Qt 3D for more throughput and to free up the main thread
• Support key frame animation
• Support morph target animation
• Support Qt Quick style animation elements

Details

Here are some random thoughts on long term features. Not all of this needs to be in 5.9 by a long shot and may reach out as far as 5.11 or beyond. We can introduce various features over several versions. Driver animations are likely the simplest to implement.

Key frame animation is well described in the Game Engine Architecture book, including for joints. In particular take note of the layering and interactions with other typical subsystems such as inverse kinematics, rag-doll, constraints and state machines. For 5.9 I'd suggest we get the basic animation pipeline in place and extend it to higher levels and more interactions in 5.10 and beyond.

The Blender docs also have some nice documentation about animation features used in Blender which we may wish to support: https://www.blender.org/manual/en/animation/index.html

• Key frame animation
  • F-Curves
    • Key framed values
    • Interpolation
      • Discrete
      • Linear
      • Bezier
    • Extrapolation
      • Constant
      • Linear
  • Skeletal animation (maybe for 5.10?)
    • Joints, Skeletons, Poses
    • Animation aspect calculates matrix palette
    • Skinning done in renderer
  • Blending of animations
    • Weighted flat list
    • Blend tree
    • Both of the above?
  • Post animation tweaks:
    • Inverse kinematics (maybe for 5.10?)
    • Rag doll (requires physics aspect)
  • Driver animation
    • Properties updated by user-provided functions or from a preset list of options
    • For user-provided, possibly use functor approach as per texture image data
    • Implemented on backend
  • Markers
    • Events in the timeline
    • Could be used to indicate when to switch between cameras or when to play another animation clip etc
  • Constraints (separate aspect maybe)
    • Easier for some types of animation, e.g. animating a camera along a path defined by a curve