[fixed]Animated DirectX file not working

[harkathmaker]

I've had some problems with this before, I've come back to them now...

The DirectX animated mesh is broken. Whenever I try to call getAbsolutePosition() for one of the bones, it gives values that are different from the bone's actual position. I've verified this visually. Why does it not work??

What is the file format most people typically use for animated characters? If the case is that DirectX is not supported because people don't use it, I'd like to know what the better alternative is.

[CuteAlien]

Do you have an example where we can reproduce the problem?
There might be something wrong, but I don't know about any bugreport about that currently (but if they are not in the bugtracker they sometimes get lost in the noise).

Another format used for animations is b3d. But your problem sounds rather like a problem with bones, so not sure if it would be fixed by switching the format.

[harkathmaker]

Here's an example and a picture:
http://harkath.com/irrlicht/DirectXBug.zip


I tried exporting the model using the b3d format as well. There are other problems there... many of the triangles are not properly placed, and there are about 43 materials instead of 2, but the bone location showed up properly some of the time.

I'm fairly certain the problem isn't with the model itself, as I exported it to the OGRE engine and the bone worked perfectly.

[CuteAlien]

Thanks for the test, I can reproduce it here (also on GL) and it looks very much like a bug. I'm not yet that familiar with the bone animation system, so I've just moved it to the bug forum for now hoping someone else in the team knows more about this problem. You can also put this bug on the bugtracker to make it more visible.

[harkathmaker]

I've never put a bug on the bugtracker before, how should I go about doing that? Is there a URL to go to?

[CuteAlien]

Seeing the newest bug entry I guess you found it already ;-)

So to link back to the tracker entry: http://sourceforge.net/tracker/?func=de ... tid=540676

[CuteAlien]

I spend a few hours yesterday on getting into the animation system and looking for this. No solution yet and I have to do other stuff today, but some findings in case anyone can else takes that bug over.

First some minor modifications to the code example. It did not set the JointMode and I first suspected this to be the reason. But unfortunately this did not fix the bug. Then I added debug-output which shows that the bones used in the mesh-drawing are clearly correct. Another test with animating joints manually shows that this is also failing and also gives some further hints for the bug.

So here the new example (still using the model from the zip above):

Code: Select all

#include <irrlicht.h>

using namespace irr;

using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;

#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
#endif

int main() 
{
	stringw debug_string;

	IrrlichtDevice *device =createDevice( video::EDT_OPENGL, dimension2d<u32>(640, 480), 16,false, false, false, 0);
	if (!device)
		return 1;

	device->setWindowCaption(L"Bone Bug");

	IVideoDriver* driver = device->getVideoDriver();
	ISceneManager* smgr = device->getSceneManager();
	IGUIEnvironment* guienv = device->getGUIEnvironment();

	IGUIStaticText* text = guienv->addStaticText(L">.<",
		rect<s32>(10,10,260,64), true);

	//The main model.
	IAnimatedMesh* mesh = smgr->getMesh("models/block_rig.x");
	if (!mesh) {
		device->drop();
		return 1;
	}
	IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode( mesh );
	node->setAnimationSpeed(12);
	node->setMaterialFlag(EMF_LIGHTING,false);
	node->setJointMode(EJUOR_READ);
	node->setDebugDataVisible(scene::EDS_SKELETON);
	//node->setJointMode(EJUOR_CONTROL );

	//The bone being accessed is the left hand.
	IBoneSceneNode* bone = node->getJointNode("handL");

	//This axe shows where the function is returning the absolute position (the handle is at that position).
	IMeshSceneNode * sphere = smgr->addSphereSceneNode (.1f, 16);
	sphere->getMaterial(0).Lighting = false;

	smgr->addCameraSceneNode(0, vector3df(0,3,-4), vector3df(0,1,0));

	while(device->run())
	{
		debug_string = L"Bone absolute position does not correspond to where it is drawn.";
		debug_string += L"\nBone X: ";
		debug_string += stringw(bone->getAbsolutePosition().X);
		debug_string += L"\nBone Y: ";
		debug_string += stringw(bone->getAbsolutePosition().Y);
		debug_string += L"\nBone Z: ";
		debug_string += stringw(bone->getAbsolutePosition().Z);
		text->setText(debug_string.c_str());

		driver->beginScene(true, true, SColor(255,100,101,140));

		smgr->drawAll();
		guienv->drawAll();

		driver->endScene();
		
		//		node->animateJoints();
		sphere->setPosition(bone->getAbsolutePosition());		
	}

	device->drop();

	return 0;
}

I suppose the function that fails is CSkinnedMesh::recoverJointsFromMesh. And seeing the comments in there it's something on which someone else already worked for some time. It seems to me that we have the correct matrix for relative and absolute transformations in the joint already. But we can't seem to just use them in the SceneNode because we work with euler angles there and so we try to recover the values from the relative transformation matrix in recoverJointsFromMesh and then do re-calculate the absolute matrix once more. And seeing that getScale is outcommented this might be the problem (and it's only getting more complicated from there on). I see no obvious solution for this so far, although I learned a lot more about matrix math yesterday.

Some workaround for the engine I could think of (not yet tested) would be copying the matrices of the joint (or maybe only the relative transformation matrix) directly into the bonescenenode. Maybe for read-only access, so the information can just be read by the user.

A workaround without changing the engine, but which works probably only when you don't have more than one instance of a mesh is that you can probably get the transformations for now from the mesh and it's joints directly.

[hybrid]

I've added some test code to the test suite (for now disabled, as it's not going through). Ok, that indeed fixed the bug. The test now goes through, I guess that most bones should be at the correct position now

[harkathmaker]

Cool! Has it been implemented in the SVN?

[hybrid]

Yes, for now only the 1.7 branch, but will go into trunk soon. Bones are correctly placed. Just make sure you either render the node before getting the bones, or updateAbsolutePosition on it. Otherwise the bones are offset.

[harkathmaker]

I'm assuming this is still to be implemented in 1.7 (doesn't seem to work in 1.6.1)...

On another note, I believe the rotation matrix is also off for the bone scene nodes. When I attach nodes to the bones, it's not only the position that is wrong but also the rotation. Has this been fixed as well, or does it still need to be?

[Lonesome Ducky]

If you need 1.7 from SVN, there is a site here that builds the most current version

[hybrid]

Yes, for now only the 1.7 branch, but will go into trunk soon.

This means that it's in the 1.7 branch already, and will be available in later versions as well (which are prepared in trunk). There's no chance to get this into 1.6.1 (as it's out already) or 1.6.2 (as it changes too much of the existing stuff which we cannot asure won't do any harm to other things).

[harkathmaker]

Could you post the code for an example that gives the absolute coordinates correctly? I have tried calling updateAbsolutePosition() for both the bone and the node, but it doesn't seem to give the correct coordinates.

[hybrid]

If you have access to SVN (or use SF SVN browser) check the b3dAnimation test. It renders small cubes to all joint positions of the ninja mesh.