COLLADA exports animations values for Location in world space instead of local space #45687

New Issue

Eric · 2015-08-05T17:04:41+02:00

Eric commented

2015-08-05 17:04:41 +02:00

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.

anim-test.blend

anim-test.dae

Exact steps for others to reproduce the error

Create a scene with animated objects where some are parented to others
Export as COLLADA
Check the firsts output key values for Localtion.X, Y and Z in the DAE file, compare with the transformations data of the : 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.

**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. [anim-test.blend](https://archive.blender.org/developer/F220305/anim-test.blend) [anim-test.dae](https://archive.blender.org/developer/F220306/anim-test.dae) ![test-anim-FBXreview.jpg](https://archive.blender.org/developer/F220307/test-anim-FBXreview.jpg) ![test-anim-Open3D.jpg](https://archive.blender.org/developer/F220309/test-anim-Open3D.jpg) **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.

Eric commented

2015-08-05 17:04:41 +02:00

Changed status to: 'Open'

Eric commented

2015-08-05 17:04:41 +02:00

Added subscriber: @Sedenion42

Aaron Carlisle commented

2015-08-05 19:53:17 +02:00

Added subscriber: @Blendify

Sergey Sharybin commented

2015-08-06 12:38:34 +02:00

Added subscribers: @GaiaClary, @Sergey

Gaia Clary was assigned by Sergey Sharybin

2015-08-06 12:38:34 +02:00

Sergey Sharybin commented

2015-08-06 12:38:34 +02:00

@GaiaClary, are you still around to help us with collada?

Eric commented

2015-08-06 18:24:59 +02:00

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...

Gaia Clary commented

2015-08-08 21:39:39 +02:00

@Sergey: sure i am available.
@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).

@Sergey: sure i am available. @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).

Eric commented

2015-08-09 01:33:56 +02:00

@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.

Gaia Clary commented

2015-08-25 16:55:30 +02:00

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)...

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)...

Eric commented

2015-08-25 17:19:02 +02:00

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...

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...

Eric commented

2015-08-25 17:22:58 +02:00

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).

Brendon Murphy commented

2015-09-08 04:49:14 +02:00

Closed as duplicate of #43298

Brendon Murphy closed this issue

2015-09-08 04:49:14 +02:00

Campbell Barton commented

2015-09-08 05:29:30 +02:00

Changed status from 'Duplicate' to: 'Open'

Campbell Barton reopened this issue

2015-09-08 05:29:30 +02:00

Aaron Carlisle commented

2017-04-14 21:07:31 +02:00

Removed subscriber: @Blendify

Gaia Clary commented

2018-02-19 15:50:08 +01:00

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.

I have started a rework of the animation exporter. The fix in [D3070](https://archive.blender.org/developer/D3070) already solves the issue, but it needs some refinement and further testing.

Gaia Clary commented

2018-02-24 16:00:20 +01:00

The reworked animation exporter/importer is now in master

Gaia Clary commented

2018-02-25 10:22:24 +01:00

And now it is also in Blender 2.8

Gaia Clary commented

2018-02-25 10:24:03 +01:00

Changed status from 'Open' to: 'Resolved'

Gaia Clary closed this issue

2018-02-25 10:24:03 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

COLLADA exports animations values for Location in world space instead of local space #45687