Animated .x mesh long loading times

[ichtyander]

Hi, I have an animated character model with about 5000 frames in the .x format and the loading times are pretty long (~23 seconds). DxViewer loads the file almost instantly.

The animation is done in Maya, transfered to 3DS Max, then exported to FBX, loaded the FBX in Fragmotion and finally exported to the .x format. This is a process that's given the best results after a long time of testing various export methods.

Since 20 seconds is quite a lot in this situation, is there a way to shorten the loading times? Are baked keyframes an issue? Perhaps there is something I'm missing in the export process that can drastically expand loading times, but I'm a bit confused since DxViewer loads the file instantly.

Here's a download link to the animated mesh in question (both in binary and text format) so you can take a look at the files:
https://drive.google.com/file/d/0B82zDr ... sp=sharing

I'd really appreciate any pointers and ideas you may have, thanks.

[wing64]

Maybe this help you, Try disable optimize and check keyframes in CSkinnedMesh.cpp line 946.
Load in release mode < 1 sec and debug mode

Code: Select all

Time to load binary X file: 9005ms
Loaded mesh: C:/character_bin.x

[CuteAlien]

Too many identical key-frames (especially for scaling in this case). Irrlicht is erasing them one-by-one in CSkinnedMesh::finalize() which is too slow. Can probably be rewritten to be faster - but if you have a way to kick them out before export then you can also speed it up.

[CuteAlien]

It's now a lot faster in svn trunk revision 4622 (less than 1 second now). Thanks for the report and the nice testcase!

[hendu]

I commend you for that elegance. In-place, and with less copies than a straightforward "copy OK elements to another array" implementation. Quite possibly the best possible choice.

Shamelessly stolen from somewhere, or invented on the spot?

[CuteAlien]

Thanks, very cool when you go the extra mile and someone notices it! Copy ok elements was also my first idea, but then I realized it would add a memory allocation for "nice" models which are cleaned up beforehand. And not stolen, just rewritten all afternoon long ;-)

[CuteAlien]

Argh, now I looked again and found a bug in dropBadKeys (j and n mixed up in one place ...) . That's the risk of clever code :-( Too tired already, will fix that tomorrow.

[hendu]

Where? I don't see that.

One thing to note, as array.size() isn't changing, that's a few thousand pointless function calls (or if the compiler manages to inline, pointless checks through a pointer). You should move it outside the loop in these cases.

[CuteAlien]

dropBadKeys checks for the previous frame, not the previous frame used (frame 10 , 5, 7, 11 should be 10->11 not 10, 7, 11). Works mostly... (edit: fix checked in now)

array.size() is inlined, so only a little slower in debug, in release you don't get overhead for this with any modern compiler (I checked both variants with a little test program and the resulting asm was identical). So no more need for adding unnecessary local variables - compiler is clever enough already. Note that this is only the case because size() is a simple getter - otherwise you would be right.

[hendu]

You're right, the asm is the same in this case. I've just been bitten by that many times before, and there's little harm in being safe vs testing each container if it happens to be inlined.