1.3 slowdown due to animated scene nodes

George · Post by **George** » Wed Mar 21, 2007 11:37 pm

Hi there,

I have been using Irrlicht for a number of projects for over a year, but since I upgraded to 1.3 in the last couple of days I have noticed a significant slowdown in performance (fps) down to about a 1/3 of what 1.2 achieved. I am only testing in DX9.

I have tried everything I could think of so far to try to up the speed, but always with the same results.

When drawing only 2D to screen the performance is comparable but when adding 3D objects to the scene manager in the same way that I have always done, the performance drops significantly. I have almost identical code (with the exception of a few minor API changes needed to recompile using 1.3) and I get 53fps with 1.3 and 140fps with 1.2. The scene renders in exactly the same way.

There is another thread about ubuntu linux having a similar problem with 1.3, but the suggestions there didn't help.

Have others had a similar experience, or could offer suggestions?

I am running WinXP, Intel Core 2 6300, and a Geforce 7600 GS, latest drivers are installed. I compile all code with VS 2005.

Thanks

- George

hybrid · Post by **hybrid** » Wed Mar 21, 2007 11:54 pm

I just did a pretty complete benchmark with the last three versions of Irrlicht and all examples from the SDK. All tests performed under Windows, with a WHQL NVidia driver.
The results (to be put into the Wiki soon) is just as the ones I posted before for Linux versions: Irrlicht 1.3 is about 10% faster than 1.2 with two exceptions: The Collision and MeshViewer. Since the quake map (example 2) is not slower I still think that the problem is with animated meshes (double animation of each node each frame) and maybe problems with the new font implementation for MeshViewer (but that's only a very blind guess).
So describe your scene setup to check the most probable reasons for your application. Anyway, these two things will definitely be worked on in the future.

George · Post by **George** » Thu Mar 22, 2007 12:42 am

Thanks for the prompt reply Hybrid,

I am also suspecting it is the animated meshes. I also did the plain vanilla out-of-the-box comparisons between 1.2 and 1.3 and for me the collision example was:

1.3 = 207 fps and
1.2 = 338 fps.

The lighting did look a little different though (I'm not sure if render quality setttings are different between the two demos). In the rest of the demos, 1.3 did indeed run faster than 1.2.

I use .X text files to import my animated meshes. The scene consists of about 20 models each having in the order of 1500-2000 polys.

Even setting the animation speed to 0 for the models made no difference. I'll have a look where the animation happens in the irrlicht source code and try to see if things are getting called multiple times as you suggest.

One thing I did change in the Irrlicht source was to take out the piece of code that calls optimizeFrames() in parseFile() in CXFileReader.cpp, as it was interfering with how meshes were transformed. That problem is caused by un-named frames in the .X file. By removing the code, all the correct transformations happen. We use the Quest3D exporter for Max, but it generates unnamed frames in the hierarchy. It was easier to remove the code from irricht or have to manually name some frames each time we exported a model. Putting this code back in made no difference in the frame rate, things still appeared but not correctly oriented.

Cheers

- George

George · Post by **George** » Thu Mar 22, 2007 3:21 am

Okay I have been tracking down the problem in a debug build of irrlicht and it does look like it is an animated mesh scene node problem.

When I removed the Animation Set { } section from .X files, the frame rate increased significantly back to where it should be. I have not been animating the models using the animation data in this example, but obviously it was still processing the animation set.

One of the reasons we have been including animation data in the exporter (although the object was not animated) was that the model's transforms (scaling, rotation, translation etc.) were not correct unless the animation data was included.

Removing the animation set from the .X file fixed the frame rate problem, however, the models now have the wrong transforms again. It seems that the animation data had to run at least once to set the initial transforms?? Could someone shed some light on this?

I think the underlying problem with the frame rate is still there when you need an animated mesh though. We do use the model animation data in other projects.

Perhaps someone can point me in the right direction in further investigation? thanks

- George

hybrid · Post by **hybrid** » Thu Mar 22, 2007 8:31 am

The change of OnAnimation/OnPostRender to the new scheme seems to require another update of the animation data in its current layout. So you basically get all animation transformation applied twice (without noticeable effects usually, except for the FPS drop). This has to be fixed somehow, but I guess that it will have to be done together with the new animation framework so a quick fix might be worse than developing a proper new animation system. But it should be fixed one or the other way for the next release.
I'll move to bug forum and rename this thread as a reminder.

Luke · Post by **Luke** » Thu Mar 22, 2007 9:18 am

yeah, with the new animation system this will not be a problem, as the mesh can be skinned and animated with different calls.

but for now a quick fix by moving the updateboundingbox function to render, and removing that extra getMesh call seems fine.