Just a heads up for AssimpNet development and to let you all know that it’s not been forgotten. I’ve made lots of ground with the trunk version – a total revamp of marshalling to allow both native to managed and back to native was no small feat. However development has somewhat slowed as I drew more focus on the graphics engine.

I have basically three major tasks left for the AssimpNet 3.3 release:

1. Clean up logging.
2. Write the exporter, and separate out convert API into its own converter object.
3. Better mono support.

The first task has to do with the AssimpNet LogStream API. The current implementation has these guys used in conjunction with an AssimpImporter. For every new import done, the log streams are attached, then after detached. This is a stale design choice that is posing problems now. Before the 3.0 release (coinciding with the current Assimp 3.0 release) the C-API wasn’t exactly thread safe with how configurations were setup. Now it is.

The goal is to move attaching/detatching logstreams to a singleton called AssimpLogger. So for all importers, exporters, and converters there’s a single place to attach your logging or turn verbose logging. With that change, the importers will no longer employ (coarse) synchronization locks, enabling a whole heck lot better multithreaded model loading. The current importer implementation is thread safe, but it’s not concurrent.

The second task is fairly self-explanatory in mirroring the importer capability with exporting. As a stop-gap measure with the last release, I had a convert API in the importer. Since we now have true export capabilities, since you can now marshal the AssimpNet managed data structure to its unmanaged equivalent, the convert API is somewhat diminished. It still can be useful if you simply want to do file-to-file conversion and not have to bother with loading anything, so it’ll be moved. So we’ll have three main objects: AssimpImporter, AssimpExporter, and AssimpConverter.

The third task is a bit trickier. We have AnyCPU support, we have dynamic loading of DLLs, but we’re still utilizing some Win32-only functions in the interop with the unmanaged DLL (getting at the unmanaged function pointers for the delegates). My intention is to generalize that and have a few different platform implementations for Linux/Mac.

So that’s about it, other than bug fixing. All the other major functionality features are there (100% coverage of the unmanaged C API, native-to-managed round tripping, etc). The next release will be a bit of a doozy if you think about how far it’s come from the last release. AssimpNet will be ubiquitous , and that’s pretty darn cool!

I saw that the last release has seen over 400 downloads and it’s being used by some of the major graphics APIs out there (SharpDX and MonoGame that I know of). I’m really proud that the wrapper is being found useful!