Animation code bug

spooky_paul · Post by **spooky_paul** » Sat Jun 09, 2007 12:14 am

I have read in a topic that due to a bug in the 1.3 version irrlicht animates each frame twice, dos giving an important performance drop.

my question is if it was fixed in the latest svn, and if not when will it be?

paul

bitplane · Post by **bitplane** » Sat Jun 09, 2007 2:13 am

yes, this is still a problem. the main problem is that you don't know the size of a mesh before skinning it and getting its bounding box. so the scene manager skins the mesh in the OnRegisterSceneNode to see if it should be rendered, then it skins it again later when it renders it.
most of the IAnimatedMesh types won't re-skin if it's building the last skinned frame (x doesn't), but that doesn't help if there are multiple nodes that use the same mesh on screen (every node is registered, then visible nodes are rendered)

Luke and I were discussing this the other day... perhaps IAnimatedMesh needs getMaximumBoundingBox or something, which could be checked to see if the mesh should be skinned. it could start off as the size of the static mesh, and then increase to hold bone positions plus the skinned mesh... or possibly just enclose a sphere with radius of the longest chain of bones, or just all the bone positions in known keyframes... or possibly have a bbox for each keyframe and interpolate.

all those sound better than what we have currently.
for a future irrlicht-specific format, the maximum size could be read from disk

the result of the box being too small would result in disappearing mesh ugliness, too large and we're skinning things that are off screen.. currently we're skinning them twice if on-screen and once if off screen, which is incredibly bad.

edit: as of revision 698, x meshes don't re-skin the mesh if the last skinned frame was requested to be skinned again. doesn't fix the main problem though.

Luke · Post by **Luke** » Sat Jun 09, 2007 2:31 am

Yeah. this bug really needs to get fixed.

the result of the box being too small would result in disappearing mesh ugliness, too large and we're skinning things that are off screen

I think a using maximum BoundingBox method is the best.

the BoundingBox should be static in the mesh and the node after creation, so it's easy for the user to change the bounding box if there are any problems. and if they are doing anything special they can add their own code to update the box.

want do you think?

edit: as of revision 698, x meshes don't re-skin the mesh if the last skinned frame was requested to be skinned again. doesn't fix the main problem though.

yeah, but this doesn't help if there as more then one mesh.

spooky_paul · Post by **spooky_paul** » Sat Jun 09, 2007 10:56 am

this is really bad news, as in my project there are at a given moment as more as 10 characters, about 5k polys each, normal mapped, and the scene dynamic lit. the way irrlicht handles animated nodes is quite a big performance drawback, and this throws off getting @30fps on medium hardware

is there any news regarding 1.4? will this be fixed in the following release?

bitplane · Post by **bitplane** » Sat Jun 09, 2007 2:47 pm

the next release will be 1.3.1, which will be mostly bug fixes and no major changes

hmm lets make IAnimatedMesh::getBoundingBox return the largest known bounding box, then perhaps we can squeeze this fix into 1.3.1 after all.

spooky_paul · Post by **spooky_paul** » Sat Jun 09, 2007 3:15 pm

this is good news. any eta on the 1.3.1 release?

bitplane · Post by **bitplane** » Sat Jun 09, 2007 10:02 pm

Niko always never advertised release dates before, that way nobody can be dissapointed if it doesn't happen when expected. I don't want to be the first one to break this tradition!
However, if you want to check out the source from svn and help find and/or fix bugs it might help towards not needing a 1.3.2 release

Here's a fix related to this topic-

CAnimatedMeshSceneNode.cpp lines 169-173

Code: Select all

		scene::IMesh *m = Mesh->getMesh(CurrentFrameNr, 255, StartFrame, EndFrame);
		if ( m )
		{
			Box = m->getBoundingBox();
		}

replace this with:

Code: Select all

		Box = Mesh->getBoundingBox();

this will fix the double-skinning thing (doesnt fix it for many render targets though), but could cause bounding box problems with animated IAnimatedMesh types (static and animated x, ms3d, b3d, md2 and md3 meshes will have to be checked). does this fix your problem? if so which mesh type are you using?

spooky_paul · Post by **spooky_paul** » Sun Jun 10, 2007 2:30 pm

thanks for the fix, i hope that it will improve performance to a certain level

paul

bitplane · Post by **bitplane** » Sun Jun 10, 2007 4:28 pm

i tried it with a few different mesh types and committed this fix last night, it was similar to this in 1.2, so I doubt it will cause too many problems.

Luke · Post by **Luke** » Wed Jun 13, 2007 12:26 pm

bitplane,

it might be better not to even have the Box = Mesh->getBoundingBox(); line in that function, because the box is already setup in setMesh. And that way the user can change the boundingbox per mesh without it being overwritten.