Page 1 of 1
Global skinning bug with .b3d
Posted: Thu Sep 13, 2018 1:29 pm
by mant
When I set all joints to EBSS_GLOBAL using joint->setSkinningSpace, the whole scene node turns into something weird.
Local skinning space:
Global skinning space:
I consider this a very serious bug with global skinning.
Here is the file to reproduce:
https://drive.google.com/open?id=1QOfHj ... Wfb1FC0MRG
I exported using Blender and SuperTuxKart's exporter.
Re: Global skinning bug with .b3d
Posted: Fri Sep 14, 2018 9:56 am
by CuteAlien
Your model shows up correctly in the meshviewer example. Tested with Irrlicht 1.8 and svn trunk versions.
Re: Global skinning bug with .b3d
Posted: Fri Sep 14, 2018 11:39 am
by mant
Hi CuteAlien, can you try looping through all joints and setting skinning space to global? And joint mode to EJUOR_CONTROL too.
Re: Global skinning bug with .b3d
Posted: Fri Sep 14, 2018 12:32 pm
by CuteAlien
Ah that's what you meant. You can't just change the space when the values are given in another space. You would have to transform all animation data to global space. This tells Irrlicht which space it should expect from the model - it does not do any transformations. There's not much of a reasons to do that really (well, depending on situation it could speed up animation, but aside from that I can't think of anything). What are you trying to do really?
Re: Global skinning bug with .b3d
Posted: Sun Sep 16, 2018 4:40 am
by mant
I'm mapping smartbody (
http://smartbody.ict.usc.edu/)'s animation to Irrlicht joints.
Here is the global skinning with SB's global matrix (converted from right handed to left handed coordinate).
https://www.youtube.com/watch?v=4yRVi4x5Jxo
The debug joints draw is for SB's rig.
Re: Global skinning bug with .b3d
Posted: Sun Sep 16, 2018 11:34 pm
by CuteAlien
So those would be on top of b3d animations somehow? Or your b3d model has no animations but only provides the skeleton? Or does smartbody produce those b3d's?
Re: Global skinning bug with .b3d
Posted: Tue Sep 18, 2018 4:33 am
by mant
My model doesn't have animations, only skeleton. SB has an animated (mocap) BVH file with that same skeleton.
So I'm looping through joints to set transform but so far I haven't succeeded.
Here is the SB's joint class:
http://smartbody.ict.usc.edu/doxygen/ht ... joint.html
Current code that produces results in above video:
Code: Select all
irr::core::matrix4 mat;
auto getMatrix = [] (SmartBody::SBJoint* inJoint) {
float* M = inJoint->getMatrixGlobal();
irr::core::matrix4 rightHandToLeft;
constexpr float boneSizeScale = 0.5f;
constexpr float bonePosScale = 0.5f;
rightHandToLeft[0] = boneSizeScale * M[0];
rightHandToLeft[1] = boneSizeScale * M[1];
rightHandToLeft[2] = boneSizeScale * M[2];
rightHandToLeft[3] = M[3];
rightHandToLeft[4] = boneSizeScale * M[8];
rightHandToLeft[5] = boneSizeScale * M[9];
rightHandToLeft[6] = boneSizeScale * M[10];
rightHandToLeft[7] = M[11];
rightHandToLeft[8] = boneSizeScale * M[4];
rightHandToLeft[9] = boneSizeScale * M[5];
rightHandToLeft[10] = boneSizeScale * M[6];
rightHandToLeft[11] = M[7];
rightHandToLeft[12] = bonePosScale * M[12];
rightHandToLeft[13] = bonePosScale * M[14];
rightHandToLeft[14] = bonePosScale * M[13];
rightHandToLeft[15] = M[15];
return rightHandToLeft;
};
mat = getMatrix(joint);
irrJoint->setSkinningSpace(irr::scene::EBSS_GLOBAL);
auto rot = mat.getRotationDegrees();
auto scale = mat.getScale();
irrJoint->setScale({scale.X, scale.Y, scale.Z});
irrJoint->setRotation(rot);
irrJoint->setPosition(mat.getTranslation());
irrJoint->updateAbsolutePosition();
Re: Global skinning bug with .b3d
Posted: Tue Sep 18, 2018 8:40 am
by CuteAlien
What does getMatrix(joint) do? Where's that joint variable coming from? And this look like you do already stuff with SB, not just set another skinning space. I thought you could reproduce it without that?
Re: Global skinning bug with .b3d
Posted: Thu Sep 20, 2018 8:28 am
by mant
getMatrix converts a matrix from right handed to left handed coordinate.
Yeah it is quite easy to reproduce, I will take time to for that and update.
Thanks CuteAlien.
Re: Global skinning bug with .b3d
Posted: Thu Oct 15, 2020 8:21 pm
by robmar
Anyone aware that this change in quaternion.h of 1.8.4 seems to break the b3d joint loading code, the models get distorted:-
//
// Creates a matrix from this quaternion 1.7.4 *** WORKS WITH B3D
//inline matrix4 quaternion::getMatrix() const
//{
// core::matrix4 m;
// getMatrix_transposed(m);
// return m;
//}
#if !IRR_TEST_BROKEN_QUATERNION_USE
// Creates a matrix from this quaternion 1.8.4 *** BREAKS B3D LOADER
inline matrix4 quaternion::getMatrix() const
{
core::matrix4 m;
getMatrix(m);
return m;
}
#endif
Re: Global skinning bug with .b3d
Posted: Thu Oct 15, 2020 8:53 pm
by CuteAlien
I don't really expect this specific code to be the problem. It should return identical results as getMatrix has changed. I still regret how I handled that bug back then (should have deprecated old functions and used new function names probably and even removed the one constructor which was changed - I didn't dare doing that back then, but yeah - that fixed one mess and replaced by another one for people updating from older Irrlicht's).
If you got a concrete model which breaks I can test and try to find out what's breaking it. Without test-case I can do nothing.
Re: Global skinning bug with .b3d
Posted: Thu Oct 15, 2020 9:15 pm
by robmar
you're spot on of course! I was confused as hell after updating the quaternion code, doing some other stuff, then later finding the b3d was well broken!
I see that the 1.8.4 loaders now call getTransposed instead, so if you update the math files, its necessary to update the loaders to match - sorta confused me and I guess renaming a couple of functions would have avoided that, but hey, you can't do it all, all the time...
Re: Global skinning bug with .b3d
Posted: Thu Oct 15, 2020 10:23 pm
by CuteAlien
You're not the first to get confused by this. Only up-side - at some point probably no one converts pre 1.8 Irrlicht projects anymore and then the new functions will make more sense (the problem had been that matrix and quaternion rotated in different directions and converting between them thereby sometimes flipped the direction - that's now no longer the case).