Add Open Asset Import Library (assimp) support

[zturtleman]

Add Open Asset Import Library (assimp) support

[m-7761]

I've actually rewritten this library for my project involving MM3D. It has some really bad problems that I could never get the maintainers to budge on, so I had to fork it. It doesn't have any kind of support for "frame" animations. I've actually heard from people who use MM3D. Generally its appeal is its morph-target feature set. That's actually what I'm mainly focused on also.

Another problem with Assimp is it uses vertex-soup representation only. And its loaders are written this way. As a result, they all have laborious logic that translates the input into the Assimp representation, instead of letting the inputs use their own representation. This means every loader reimplements this translation process. Because I wanted to add a few different formats to its repertoire I could see how boneheaded that was, and so wrote one open-ended representation that then converts into the Assimp representation, that way it only has to be done one time. In that way all of the loaders can use that more flexible model to A) retain connectivity information, critical for any real world applications, and B) reduce their algorithm down to a small human readable, easily maintainable, thing.

I think it would be a bad fit for MM3D as an importer. If you just want to pull in raw geometry data that might be a nice way to lower expectations. Noncommercial 3D software is really inadequate. I'm trying to bring together the best open-source code that currently exists, and build something more mature from it.

[zturtleman]

MM3D suffers from difficultly getting models in or out of the application. For Misfit the only way to get skeletal models out is .mm3d (nothing else supports it) or buggy .ms3d (MilkShape3D) export. Misfit is pretty much only usable to create frame animated MD3 models. (MD2 export should use a triangle strip plugin that can't be distributed as a binary because of a incompatible license.)

In Maverick I've improved the .ms3d support and added IQE (Cube 2) and SMD (Half-Life 1/2) export. I plan to add import/export for more game specific formats for some id Tech 3/4 games and IQM/IQE which allows for better control compared to assimp. For undocumated model editor specific formats I'd rather use a library that someone else maintains. (MM3D has cod, dxf, lwo, and a 3ds plugin; support for newer formats such as blend and fbx would be nice.) I don't particularly care if it's assimp or something else.

[m-7761]

I was genuinely surprised when MM3D came up in conversation with another person. I didn't think anyone used it either myself. I've never used it. I just did a review of all of the code that existed, and crossed everything else off the list for this and that reason, and ended up eyeing MM3D's code.

I didn't go into details about how I've rewritten Assimp, but basically the code I developed is what is called DAPP in this (https://www.khronos.org/collada/wiki/ColladaDOM_3) article. I've developed it to be ideal for quickly writing loaders for exotic proprietary formats. So it's geared for salvaging/browsing data from old video games and things like that which Assimp would never accept. It's also a plugin system, which is another problem with Assimp, since everything it supports is hardcoded into the library.

I've had some involvement with Assimp, and some code in the library. In fact the unimplement AnimMesh structure came about from discussing support MD3 models, but ultimately it could never move because the post-processing code (which is the valuable part of the library, that differentiates it) would have to all be overhauled to work on frames. So the maintainers just balked on the idea.

Their pipeline is fundamentally flawed in so many ways which requires a full rewrite. Anyway, the code I developed a while back is here (http://svn.swordofmoonlight.net/code/Daedalus/) and it looks different from Assimp, but if you look closely it's binary compatible, and I wrote it so that Assimp could easily use the same code by just writing a DAPP layer around it.

The main header is http://svn.swordofmoonlight.net/code/Daedalus/PreServe.h which I wrote in an unorthodox way that made it easy to transcribe Assimp. I will probably repackage it, but it's the import half of the software I'm developing. It uses the Assimp format since that's much more lightweight than COLLADA, and then converts it into COLLADA after processing.

Right now I don't know if I'm going to use MM3D's format or not--likely in a modified form if so--either short term or in the final product. I may need to use it to complete a game I'm set to release in Christmas 2020. It depends on what's easier with time constraints. I have to develop a modeler to complete the project. It's a port of this (https://en.wikipedia.org/wiki/King's_Field_II) game to From Software's RPG maker software, with VR. I've souped up the RPG maker so that it can compete in limited circumstances with the game engine heavies. So I'm developing modeling software largely to complement the maker software, since I can't in good conscience recommend Blender. It's a horrible user experience, super counterproductive for old pros like myself, and isn't really viable for low-poly morph-target animations. I want to encourage morph-target animation because A) I think it's best, and B) I guess I'm anachronistic in a lot of ways, for better or worse I don't know, but I do derive some kind of perverse pleasure from demonstrating that old ways long written off can be better ways than what is fashionable/received wisdom. Part of that is I don't find new things satisfying, so it's either something is wrong with them, or something is wrong with me. I prefer to think them.

P.S. If the coding style in the DAPP code links is alarming, know that I try to always write modules in a unique style. Because I think maybe there is no single style that is best. And maybe the module should dictate the style. And it's good experience to try different things. And if modules are too similar it's hard to see in code where one ends and another begins. It turns into illegible mishmash.

EDITED: Also, notice that DAPP is one of two similar acronyms in that article, that is largely focused on DAEP. Notice the E and the P are different. DAEP is a protocol for writing algorithms against XML Schema, like scripting in C++. It's recommended for COLLADA, but COLLADA is just XML Schema, and so isn't actually fundamentally different, and it is extensible too. 3D file formats is just a tough problem domain of special importance for its labyrinthine complexity, and historical lack of suitable noncommercial exchange formats.

[orange451]

Assimp would be very useful, as that's what I'm limited to in LWJGL for model loading.

[zturtleman]

After re-evaluation of what I want of this project this is no longer on the roadmap.

[m-7761]

Not likely what you want but I think in some form I'm about to write some MM3D-to-Assimp code. I don't know, if any already exists that would be helpful. If not I don't know if this code would be useful, but I can share it. I've already written several loaders that I couldn't get accepted into the Assimp code, so I don't know that I would take the time to try to offer the code to Assimp myself. Its crew is pretty hostile to small-fry formats. I don't know that they'd see MM3D as a welcome addition.

[m-7761]

I noticed this (https://github.com/assimp/assimp/blob/master/include/assimp/mesh.h) might suggest that Assimp is beginning to implement the morph feature.... it says just the Collada loader supports it and below is a new enum type.

I found this while looking to see if there were any new attributes in aiMesh, specifically something I find very useful is to have an index of the original vertex in the source file that can survive the post-processing steps, since that lets you reconstruct a lot of things. My current hack to do that is to add a texture coordinates since that survives all post-process steps.

What I'm curious about is if the morph animations survive post-processing or not, because if not they're still in "hack" status, but if so, that's promising.

assimp/assimp#3121

/** @brief Enumerates the methods of mesh morphing supported by Assimp.
 */
enum aiMorphingMethod {
    /** Interpolation between morph targets */
    aiMorphingMethod_VERTEX_BLEND = 0x1,

    /** Normalized morphing between morph targets  */
    aiMorphingMethod_MORPH_NORMALIZED = 0x2,

    /** Relative morphing between morph targets  */
    aiMorphingMethod_MORPH_RELATIVE = 0x3,

/** This value is not used. It is just here to force the
     *  compiler to map this enum to a 32 Bit integer.
     */
#ifndef SWIG
    _aiMorphingMethod_Force32Bit = INT_MAX
#endif
}; //! enum aiMorphingMethod

[m-7761]

EDITED: I apologize BTW! I'm almost certain I would have looked into the aiAnimMesh situation before I commented back in July... maybe I didn't find the right sources when I did. I don't remember seeing those notes if so. https://github.com/assimp/assimp/blob/206004c7d6e26bf116ebe6132380f942f2d2e832/code/JoinVerticesProcess.cpp has thorough code for the animated meshes. (Edited: Maybe the rename from aiMesh.h to mesh.h caused me to find an older source.)

[m-7761]

I remembered I have some rough code for loading MM3D into Assimp. I haven't tested it all, but it looks complete. I can share it here somehow.