Hi,

We’re currently using the FBX SDK 2009.3 in our game toolchain and because of several memory leaks I’d like to upgrade to the latest version (2012.1). The leaks indeed disappeared thanks to this migration (hurray!). However, I’m now having some critical performance regressions with this release. In particular, with some of our character animation FBXs (100 bones, 120 takes, 45MB), KFbxScene::Destroy() can take up to 5 minutes. For testing purposes, I tried to disable animation import using the IMP_FBX_ANIMATION import flag, and this fixes the problem, but obviously this is not a solution. About a year ago I already tried to upgrade our version (it was SDK 2011 at the time) and I already had the exact same problem, so it does not seem to be a recent regression.

Am I hitting a known issue here?

Thanks

Jean

Edit: I just tested with another FBX with roughly the same size and spent nearly 25 minutes within a call to Destroy().

With the changes we did on animation curves in 2011.x version, and the many fixes to memory leaks, it happens very often that scenes with lot of animation en-up taking that much time to deallocate, because there is probably hundreds of thousands objects to delete from memory.

The issue is more visible in 2011.x or more because we have to manage connections between objects when we delete them, and we also changed curves and curve nodes to be objects in FBX, allowing them to be instanced anywhere and re-used.

We haven’t found a solution for users that have files with so many animations in them yet, except for a special function that we added on the KFbxScene object, named ForceKill, in version 2012.1. That function should be used with care since it disable connection notify and can lead to crashes if used with complex scenes, or if some objects weren’t deleted for various reasons.

Robert Goulet, FBX Dev Lead

Hi Robert,

Thanks a lot for the clarification.

Jean

Hi,

I tried plugging in our own memory allocator to improve allocation/deallocation performance (I expect significant gain for small allocations), but I seem to get calls to my implementations of free(), realloc() or msize() for memory buffers which weren’t allocated through my allocator. Is this a known issue or a scenario a custom allocator is supposed to handle?

Jean

Edit: my bad, I was actually calling SetMemoryAllocator after creating the SdkManager. It seems to work fine now.

Yes, it did significantly enhance the performance (we have a small heap based allocator, so small allocations are very fast). I still have to perform some more detailed profiling to tell you if I reached the same performance as with the 2009 SDK, but for now it should be OK, and the leaks did disappeared.

Hello,
Does everyone here use the custom memory allocator found in the SDK example ExportScene05?
Why would this be any different than not having one?

What’s the point of using a custom memory allocator if you’re not using it as a debugging tool?

Wouldn’t the default allocator work the same way?  (malloc,calloc,realloc,free,etc...)

There are plenty of reasons outside of debugging.
My custom memory manager, which is used in commercial game engines, is in every case at least double the speed of ::malloc(), ::realloc(), ::free(), and friends.
In most cases, it is 25 times faster.

Naturally, a custom memory manager must also have superior debugging features in debug mode (and it should have its own switch for that, not _DEBUG), but debugging is far from the only reason to use a custom memory manager.

Aside from speed, any decent manager will also have alignment support, trashable heaps, etc.

L. Spiro