So I’ve been doing a bit of digging about in the Assimp source, and it seems that, for the core library at least, the only dependency is on zlib – which it builds in your solution on Windows. My next possible step, then, could be to move the code from this zlib project over to a Windows Runtime Component project. However, I’m a little reticent to do this, since the System.IO.Compression namespace can do all the compression stuff, and to an extent it depends on whether it is easier to port zlib, or modify Assimp so that it doesn’t use zlib. My hope is that I can keep my changes to Assimp isolated to a fairly low level in the codebase, so that it is reasonably easy to keep in harmony with their continuing efforts, and porting zlib seems more likely to achieve that goal.
Digging further, I have found that at present, the zlib functionality is only called by the ‘unzip’ library that also comes with Assimp, which itself is currently only used by the Q3BSPZipArchive class. So, I think I might put in an alternate code-path in either the unzip code, or perhaps even the Q3BSPZipArchive to use the Windows Runtime code. I suspect that modifying unzip.c would be the best approach, because then anyone who writes a custom importer using the Q3BSP one as a template will be able to use my functionality.
It’s settled then, I’ll make an alternate unzip.c (or pre-compiler path therein) which uses the native Windows Runtime API to handle the unzipping. Not tonight though.
guysherman.com 