Open ricardolpd opened 11 years ago
Anything that makes the pipeline more robust is of course welcome. :)
Question, in ardor3D methods classes like matrix3,vector3 and matrix4,vector4 tend to have the same methods, will it be necessary to create an orthogonalise method for matrix3 class also?
If so what about the transform class and flags about non-rotational matrices, maybe these flags should be updated to indicate that there is a method that can force orthogonalisation?
I would imagine in this case that a similar method for matrix3 is possible and desirable. As for Transform, I am uncertain... Either we say that you are responsible for passing in rotational matrices (should that be the desire) or we could perhaps add code to optionally enforce such on the fly. I am not sure though if there could be unintended mathematical consequences to the latter?
Adding code to enforce orthogonalisation is not a good thing, as the end result might not be close enough and therefore give unexpected results since we cannot know if the matrix was supposed to be orthornormal in the first place. So I leave the Transform flag messages alone (my intention to this was to alert ardor3d devs of an alternative). And yes it is possible to put it in a matrix3 and not too hard to achieve this.
@Rensanse, why is the scale ignored in the transform class in method fromHomogeneousMatrix method ?? The solution is implemented, but with mixed results (which doesn't make much sense yet).
This issue occurs problem occurred after the transform was created from Matrix4 from import. most/all of the matrix4 that come in the collada are not orthonormal (which after i looked at it, it makes sense because of the first three elements in the last row).
Scale is ignored there because we have not implemented a reliable way to decompose scale from the matrix. (Perhaps QR decomposition?)
As an aside, have you tried exporting to Collada with "Bake Matrices" unchecked just to see if that changes anything?
So thats something to look at also. Regarding the Gram-schmidt algorithm, i implemented it, and i can't find any mistakes in the implementation, but the results are not stable enough, it converts the matrices to rotation but with some bones i get excellent approximations with others i get rubbish results.
I don't how i could solve this to be honest. There are several other algorithms that attempt to create smaller approximations in Gram-Schmidt but my maths aren't up to scratch for those yet.
Gram-schmidt will not work at import time because we get the inverse matrix of each joint. when i put them in the jointChannels to the animation managers it works fine.
Related to QR decomposition, i see on the wikipedia for this that it can be done using Gram-schmidt.
Do you know which method to get QR decomposition is best?
Sorry I lost track of this. I don't have an idea which method is best... I'm under the impression all methods can be unreliable depending on the specific matrix?
Regarding QR, i can have a look at this if you think it is necessary.
Regarding the original subject of this ticket, i got Gram-schmidt working at import time, the issue before was that was applying it to the inverse pose in the joints rather than in the local transforms, by applying it to the local transforms all the warnings disappear and and its all fine, instead of putting these in the animation manager.
I haven't submitted a patch yet as i was hoping that the guys with jdom2 would submit a fix so i can merge my changes with latest version, as this doesn't seem to happen i will download the latest version, clone it with my computer and submit a pull request.
what
Hi guys, is there anything new about this issue? I'm trying to import and execute "ColladaExample" but it's not working. What I get is a lot of "[..] supplied transform with non-rotational matrices. May have unexpected results." and a static render which is looks like a frame of my animation.
cheers, pietro
@pietro909 ricardolpd implemented Gram-schmidt, maybe he has a clean fix for this bug.
oh, thank you @gouessej : at the moment that project lies somewhere in my HD :-) I'll try to check it out soon.
This issue has been raised in this forum topic before by me, here: http://ardor3d.com/forums/viewtopic.php?f=10&t=5919
This issue seems to be constant and quite random depending on changes i do to my mode in 3D Max(It also occurs from versions 2009 to 2013 of the fbx exporter). I also know now that if autodesk fbx collada exporter knows that it has non-rotational matrices the export issues a warning about it. This issue seems to caused by because of the rounding of decimal values, which makes sense since there quite a few decimal points in my model.
Since i am fed up with this issue, as both autodesk fbx collada and opencollada give the same results, i would like to attempt to solve it by implementing an iterative gram-schmidt to orthogonalise the matrix at import time before it is modified into a Transform.
And to get a permanent fix that will suit the integration with ardor3d and possibly help others, i would like to know if integrating a new method in Matrix4.java to orthogonalise it where the three steps to do this process will be done for this type of matrix.
this method will test at the end if the process worked or not (and will return a Warning flag about it).
I will attempt to do this right before a Transform object is created from Matrix4 during import in collada.
I would suggest to turn this method on and off by using a boolean flag. This method depends on a k value which must be below one, would it be necessary to create a flag method to allow this value to change?
Sources for this method can be found here: http://gamemath.com/powerpoint/6%20More%20on%20Matrices.pptx slide 59
If there is no interest in having this solution implemented in ardor please cancel this issue:).
I think as a community maybe creating an fbx importer using their python wrapper would be the best solution i really don't like collada:S, (Maybe thats another story).
Thanks.