glm issue

[liquidzym]

i just update your branch to OF glm, but got some issue with it,the fbx model collapsed together,do you have clue which parts might be causing this behavior? thxs

[NickHardeman]

Hi @liquidzym,

All of the vertex's locations are calculated based on their corresponding bone's location and rotation. I haven't worked with glm yet. Going to list my thought process below:

The calculation of the mesh starts in this function:
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L339

That function calls https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L642

Depending on the blend type of the bones, it will call either
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L712
or also
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L830

and those should call
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L953

The pre and post transports should be already calculated on the bone, so this is where the matrix is calculated:
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXMesh.cpp#L979-L986

But those are all FBX matrices, which shouldn't be affected by the change to glm.
So, this function is probably affected by the glm switch:
https://github.com/NickHardeman/ofxFBX/blob/master/src/ofxFBXBone.cpp#L73-L88
and the same goes for the lateUpdate function.
Most of the bone class deals with converting the fbxTransforms to ofMatrix4x4, so the problem is probably tied to that class.

Hope this helps.
Nick

[NickHardeman]

Also, I updated the new master to be the latest branch. Is that the version you are using?

[liquidzym]

yes,i'm using the latest your master branch,ok i'll look into it,cheers

[NickHardeman]

I updated the add-on to work with glm and the newer version of OF, so closing this issue.