search

veyvin / assimp-net

Automatically exported from code.google.com/p/assimp-net
0 stars 0 forks source link

Problems with Matrix4x4 Decompose() #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I was using Assimp 2.x for .net that was provided in the assimp project ( not 
your AssimpNet wrapper ) , and i decided to move to assimp 3 and use your 
wrapper :)

After i finished porting (very easy thankfully) , i noticed that skinned meshes 
were completely wrong ( Note that they used to work fine before ). The strange 
thing was that not all boned meshes were wrong.

After investigation i found that the problem was in the Matrix4x4.Decompose() 
function for matrices. If i used DecomposeNoScaling() and assume scaling 1 the 
meshes suddenly  improved a lot , but still had errors.

The solutions i found was to copy the matrix in a SharpDX matrix and  use that 
decomposing and everything works fine now.

I should also mention that i use DirectX with the 
PostProcessSteps.MakeLeftHanded enabled ...this will mirror matrices.. i don't 
know if this causes any problems with the decompose function but it's a 
possibility.

the revision i used is r45

Thanks :)

Original issue reported on code.google.com by virusfre...@gmail.com on 30 Oct 2012 at 10:26

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
There seems to be a discrepancy in Decompose from Assimp's source - I need to 
dive deeper into this. It looks like a confusion of row-vs-column vector 
ordering.

Have you tried the static decompose method exposed in AssimpMethods (in 
Assimp.Unmanaged namespace)? Does it give the same result?

Also, do you mind supplying some test input?

Original comment by nicholas.woodfield on 2 Nov 2012 at 12:47

GoogleCodeExporter commented 9 years ago 
I also had this problem, the decompose() function of Assimp.Net gave me very 
strange results. By copying the Assimp.Net matrix into a Mogre matrix (I use 
the Mogre library for rendering) and decomposing it using Mogre I finally got 
the expected result.

Original comment by i.schun....@gmail.com on 2 Nov 2012 at 1:56

GoogleCodeExporter commented 9 years ago 
ok.. i have been looking into this more.. this is what i got :

1) I tried Assimp.Unmanaged.AssimpMethods.DecomposeMatrix and it does not work.

2) a simple way you could try to reproduce this is by decomposing and 
re-composing the offset matrix and see if it work. for example :

Vector3D scale, pos;
Quaternion quat;

var m = aibone.OffsetMatrix;

m.Decompose(out scale, out quat, out pos);
var new_m = Matrix4x4.FromScaling(scale) * new Matrix4x4(quat.GetMatrix()) * 
Matrix4x4.FromTranslation(pos);

When you try to use new_m instead of m the result are wrong.

3) I also attach the mesh that i use for testing ( good old bob ).

4) I did a test where i take the matrix and decompose it with both Assimp and 
SharpDX to examine the differences in the results. They both seem to agree in 
the scale and translation , but they differ in the rotation quaternion !!

Original comment by virusfre...@gmail.com on 2 Nov 2012 at 9:38

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks,

Alright, I think I got to the bottom of this. There were several 
inconsistencies with converting between quaternions/matrices which seemed to be 
causing the issue in Decompose.

I also added some extra documentation for assumptions on matrix order. Note 
that Assimp (and by extension, AssimpNet) use row-major, column-vector 
matrices. APIs such as SharpDX/XNA/SlimDX (and apparently OpenTK) use 
row-major, row-vector matrices, so make sure when you convert from an Assimp 
Matrix you first transpose it. Personally, I prefer row vector matrices and 
tend to use them more often. I would recommend always using the Math library of 
your graphics API though, the AssimpNet math structures really are only the 
bare minimum.

Also worth to note, that SRT order for column vector matrices would be TRS, but 
the matrix multiplication method for Matrix3x3 and Matrix4x4 are BxA rather 
than AxB. As I said, I added documentation to highlight this (for myself, 
especially).

The changes are in r50, I'll keep the ticket open a while longer if there are 
still issues (math inconsistencies are always a pain!).

Original comment by nicholas.woodfield on 4 Nov 2012 at 7:13

GoogleCodeExporter commented 9 years ago 
That's good .. and i agree that you should always copy the matrix to your 
graphics API and use it there , something you are bound to do anyway down the 
road.

What bothers me though is this:

1) i was using assimp's decompose before (v2.x) and it worked fine (and with 
SharpDX). So unless they changed the matrix ordering from one version to the 
next (unlikely) something else must be wrong.

2) The results of the Decomposing are matrix-order-indepented . That means that 
if i use assimp.net decompose function on an assimp.net matrix , the scale 
quaternion and translation i get back should be the same as if i decompose a 
matrix in sharpdx/slimdx/...

I am not really using the decompose function anymore , but i still think 
someone might.

Thanks :)

Original comment by virusfre...@gmail.com on 4 Nov 2012 at 10:13

GoogleCodeExporter commented 9 years ago 
Oh, my apologies. I thought the commit you made was for documentation only, i 
didn't realized you had fixes.

I just checked out the r50 and gave it a try. it seems to behave correct now :)

Original comment by virusfre...@gmail.com on 4 Nov 2012 at 10:39

GoogleCodeExporter commented 9 years ago 
Excellent, closing the ticket

Original comment by nicholas.woodfield on 4 Nov 2012 at 5:50