User:Phabtar/Improve COLLADA constrained animations and Morph animation support.

From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Improve COLLADA constrained animations and Morph animation support

Project Proposal.

>> Current State :- Community Bonding period has finished. Started working on the project. Assessing the project tasks.

>> Diary.

>> GraphicAll build of the Bratwurst Branch

Additional Links

Project Details

With the project I did for last year’s GSoC, many improvements for the COLLADA features in animation were introduced. By the project I was able to enable support for exporting and importing rigged skeletal animation. The implementation is somewhat buggy still, so first of all it would be desirable to stabilize the code. Through that further modifications related other constrained animation support can be achieved. IK constrained animation support and IK chain animation support is requested from industry users, especially users in robotics arena. With their support the best way to approach can be found out.

The current COLLADA system supports skin controller data substantially, but morph controller data is not yet supported in Blender. This is also requested from people in the industry. Blender handles Morph Controller data in the form of Shape keys. Therefore Data transitions between Blender and COLLADA, related to morph controller data, must be done through handling Shape keys.

The current COLLADA initiative inside Blender is focused on Having a COLLADA core in Blender using the interfaces presented by Opencollada and having application specific scripts, so that data loss is minimal, and bugs can be reduced. The Developments of the project will try to follow this guideline as much as possible. Second Life will be used to test exports, because currently it is the app in focus used in blender for testing the new approaches.

There is also discussion on having other COLLADA profile support, like the profile_GLES, instead of defaulting to profile_COMMON as always. Because that will add more flexibility and less roundtrip data loss for blender. If feasible this will also be added in to the developments.

ToDo

  • done
     export of constrained animations
    • done
       Export Track-To Constraints animations
      • in progress Inprogress100.jpg 80%
         Blender Profile for constraint information in nodes
      • done
         Export Bake Animation in Common profile
  • done
     Import of constrained animations
    • on hold
       Import Track-To Constraints
    • done
       Test exported baked constraint animations
  • on hold
     Other constraint Animation support
  • done
     Armature nodes export
  • done
     Armature nodes import with correct orientation of leaf bones
  • done
     Armature Animation im/export fixes
  • done
     IK-chain animation export
  • done
     Morph Constraints support
  • on hold
     Morph Constrained animation support.
  • Bugs

Completed

Export of constrained animations

As discussed below, it was decided to export constraint information of Blender in a <extra> tag for technique_profile = blender. Objects with constraints on them are filtered in the writeNodes() function in SceneExporter. After those objects are identified, extra parameters are added for the relevant information for each constraint the object has, using the factory methods given by the Node class.

Export of Track-To constraint animations

It was necessary to export animations resulting with constraints on other objects as separate animation curves, so that other software can pick out the constraint animations, because the constraint data is within the blender profile. To do this first of all it was attempted to convert the python script described here, in to C++ code in the exporter. But later found out this was not necessary at all, because after inspection, found out nice methods to use in object.c and anim_sys.c.

When exporting animations each object is subjected to the export_object_constraint_animation() method. In that method, if the object has constraints, the target objects are taken from the constraint data. Keyframes are taken from the animation data of each target object. Those keyframes are used to evaluate animations of the constraint object. All this would seem as an additional step because it would be preferable to just export animation curves after baking procedure on every frame, instead of just the keyframes the target object(s) are animated on. Then using a similar method as used in exporting baked bone animations, Object transformations are found out at each frame. In creating the output sources of the animations, first the target objects are evaluated and solved at each frame. Then the constrained object is solved for that frame. The object matrix is derived from the current position then exported as a transform matrix animation.

Currently tested with a simple track-to constraint animation.

(Constraint animation support demo)

Armature node Export

Previously when exporting armatures and bones as JOINT nodes into COLLADA, the bones pose channels pose matrix was exported. Since the Pose Matrix is of the object space, the local space matrix needs to be derived, by dividing the pose matrix by the parent pose matrix. Details about those calculations will be discussed here. But the pose matrix doesn't convey information about the rest positions of bones. Because of that, it was decided to export the bone->arm_mat, since it has the information about the bones rest matrix in armature space. This matrix needs to be divided by the parent matrix also because, since it is in armature space. When exporting to second life there are some additional calculations been made. These calculations seems unnecessary with the new modifications.

Armature node Import

Previously the imported matrix is used to derive the bones head, bones tail and the roll of the bone. The roll of the bone was calculated correctly before, but there was some modifications necessary because, as I understand there was some misconceptions about the relative spaces of the imported data. Tested Armature import and export from simplest cases to more complex scenarios. They are: 1. Single bone. 2. Two bones with changes poses. 3. Four Bones system with animations. 4. A Bone system with IK constraint Applied. 5. A fully rigged skeleton.

The first instance helped to derive the best ways to get the bone lengths and orientations right. We can derive the normalized vector for imported bones orientation. To derive the length it is a bit of an issue. This is discussed more on the discussions section.

The second instance helped to get the parenting bones orientations right. As before the parent bone lengths can be accurately derived using the child bone's head. By testing on the third instance it was designed a way to derive the lengths of the leaf bones. As before the leaf bone length will be of the shortest length of the bone in the armature which it is possible to get a length. The orientation of the leaf bones are derived as an improvement.

There was little modification to be done with the animation system for armatures after the previous years project. Tested and confirmed that it is working as expected.

IK Constraint Animation support

IK constraints are widely used in areas such as character animations. So having good IK constraint support is essential. We can't have specific support for IK chains in COLLADA. Because there are no element defined in the specification to do so. But the animations including IK constraints should reflect the constraints imposed by the IK chains. So when exporting IK constraints the animation should be as if, the bones or components are individually animated. Therefore a baking procedure is needed to bake the animations to each bone. This is done with the animations exporter. Each bone is solved including the IK constraint solving to find there respective positions in each frame. Then the pose values are exported corresponding to that frame.

The support was tested using a simple IK chain and it was a success.

Morph Controller Support

Morph Controller support have been personally requested from me at times. So as expected off the project it is implemented. The blender equivalent of Morph controllers are shape keys. So data about shape keys need to be converted to morph controller data in exporting, and morph controller data needs to be properly translated to shape keys in importing as well.

The COLLADA specifications for morph controller support defines 2 major elements, the morph targets array and the morph weights array. The source mesh of the morph is defined as an attribute of the controller. The targets point to the unique Ids of geometries or meshes in library geometries. Therefore the morph targets need to be exported separately as well. The Morph weights array has the corresponding weight of each morph target on the source mesh. The only relationship between the weights and the targets is the order they are in.

In implementing the morph controller support first the target meshes need to be exported. This is done by reading the GeometryExporter by identifying if a mesh object has keys applied to it and then exporting the key data as a separate mesh. After that the controller data is exported. The controller exporter was refactored to a new source file to separate them from the armature exporter code, where it was before. If Objects have a key then the morph controller export is called. The ids of the morph targets to export are derived the same way as they are when exporting meshes. The weights are derived from the key data.

When importing a morph controller, First the data relevant to controllers and the meshes needs to be stored for applying the shape keys later, in the finish() stage of the importing process. So in writeController() the controller data is stored in a separate vector. In the finish() method in DocumentImporter the key assigning function make_shape_keys() is called. In there for each morph controller, the target meshes are taken from the uid_mesh_map by using the morph_target ids in the controller data. Then those meshes are inserted as shape keys to the source mesh. The weights are applied in the same loop.

The support is tested by using a simple scene with two shape keys applied. The demonstrating video is below:

Discussion

COLLADA Momentum

In the application phase, Project Mentor LetterRip and I had a discussion on the current COLLADA momentum and how the COLLADA projects should be handled. kaito has addressed this in this article. As suggested there Improvements on COLLADA should involve more user feedback and testing. Because whatever we do to improve, there are still some users complaining of missing features and bugs. The current state is not all bad, but the existing features need some tweaking to get to that satisfactory level. Discussions are going on about the project in a thread in Blenderartists.org forum, and feedback is flowing in.

Constraint support in COLLADA

At first I tried to implement track to constraint animation, because it was one of the most simple. Tested with a simple scene with a moving empty and a sphere which track the movement of the empty. But as expected, only the animation of the moving empty was exported. Data related to the constraint or the movement of the sphere was not exported. This was confirmed with the re-import. So there are two approaches to overcome this issue.

  • Export Constraint related data separately in a blender specific profile, so blender can accurately rebuild the exported scene with all the constraints.
  • Bake the movement of the Animation of the tracking objects and export movement of those tracking objects as seperate animation curves. So Other Software which imports the .dae will be able to see the Animation of the track-to and tracking object both. But the constraint information will be lost in the scene.

But ultimately Gaia Clary Suggested a good method, to export constraint information in blender profile and export animation data after baking in common profile. Both in <extra> tags in nodes. Actually, I found in other discussions and forums also, that the popular alternative for exporting constraints is the helpful and multipurpose <extra> tag.

Retrieved from "https://wiki.blender.org/index.php/User:Phabtar/Improve_COLLADA_constrained_animations_and_Morph_animation_support."