COLLADA exports animations values for Location in world space instead of local space
Closed, ResolvedPublic

Description

System Information
N/A

Blender Version
Broken: 2.75 c6b042b
Worked: NO

Short description of error
DAE/COLLADA exporter generates animation curve output values for Location in world space coordinates instead of local space coordinates.

It seem this bug affects only the Location (i.e. "location.X", "location.Y", "location.Z") components for non-bones objets, the Rotation values seem to be correctly exported in local space (i don't have tested Scale components).

This bug does not affects the "matrix" type animations (commonly used for bones's animations) which are correctly exported in local space.

This is NOT an importation-side problem (this is obvious but i prefer to point that) since even Blender don't correctly import the file he just exported and the problem is the same in any other DAE viewer or 3D software.

This bug is old, i mentioned it few years ago, but it seem nobody to took me seriously. I don't think it is hard to correct this bug, this is a little bug, but corrupts all (COLLADA) animation data exported by Blender.

Exact steps for others to reproduce the error

  1. Create a scene with animated objects where some are parented to others
  2. Export as COLLADA
  3. Check the firsts output key values for Localtion.X, Y and Z in the DAE file, compare with the transformations data of the <node>: There is obviously a problem.

3-bis) Look the original animation in Blender, re-import the DAE file just created, and look again the animation.

Details

Type
Bug
Eric (Sedenion42) updated the task description. (Show Details)
Eric (Sedenion42) raised the priority of this task from to Needs Triage.
Eric (Sedenion42) added a project: Collada.
Eric (Sedenion42) set Type to Bug.
Sergey Sharybin (sergey) triaged this task as Normal priority.Aug 6 2015, 12:38 PM

i looked to blender's source code and strangely i don't see where is the problem (from what i understand of blender source code) since the exporter just puts the BezTriple.vec content in the DAE file... so, i can see only two possible mistakes: blender keep animation curves in world space (which seem strange to me) or the wrong fcurve is selected for exportation... Unfortunatly the Blender's architecture is relatively opaque to me...

@Sergey Sharybin (sergey): sure i am available.
@Eric (Sedenion42): i remember something strange goes on when using transformation type TransRotLock while it works when using transformation type Matrix (in the collada export options). it might be related.

i can take a look at this next week (if nobody else is faster).

@Gaia Clary (gaiaclary) Note that Matrix animation export works only for bones. I don't know if it's a feature or a bug, but whatever you select in the export options, the animations for non-bones objects are exported in TransRotLoc way.

It looks like the matrix_parent_inverse information gets lost during export.

I made the following test:

  • exported the 3 objects to collada
  • imported the objects back into the same blend file
  • copied the matrix_parent_inverse values from the original objects to the reimported objects.

Now the animation works again as expected.

As far as i know Collada does not support the concept of "matrix_parent_inverse". So the exported objects all have their matrix_parent_inverse "applied" to preserve the correct object locations in world space. But the animation curves are exported without applying the matrix_parent_inverse

So i guess the fix is to apply the matrix_parent_inverse also to the animation curves during export (if that makes sense)...

That make sens to me yes... and the "inverse parent" matrix has, to me, nothing to do in the transformations informations... ( I was forced to adapt my importer to properly compute this strange matrice by multiplying it by the local matrix ).

In my knowledge The "matrix_parent_inverse" is an exclusivity of blender. As far as i know, objects usually just have two main matrices, the local one, and the world-matrix, which is the result of the successive multiplications of parent's world-matrix with the local one (which give the final world transformation).

"world_matrix = local_matrix * parent->world_matrix" si what i do, and i'm not sur, but i think everybody (except blender it seems) do like that...

In fact, all matrices and transformations should be "local" to object in the exported file... the world transformations are computed later, in the engine (whatever the engine) who multiply naturally the local matrix with parent matrix (except for root objects).

I have started a rework of the animation exporter. The fix in D3070 already solves the issue, but it needs some refinement and further testing.

The reworked animation exporter/importer is now in master

And now it is also in Blender 2.8

Gaia Clary (gaiaclary) closed this task as Resolved.Feb 25 2018, 10:24 AM