they only need to parse the JUMI format (which will be thoroughly documented) because JUMI itself will worry about the specifics of FBX, OBJ, MD2 etc.
Ok but an interchange format (like U3D, OpenGEX, xbuf, Collada) doesn't have the same constraint than a runtime asset format (GLTF
). Then, you'll have to make a decision.
I talked about using your library as a source of inspiration for engines because I thought that in this case, using the abstractions of an engine reduces the overhead. Actually, you will write lots of classes that we typically find in a 3D framework or engine. In my humble opinion, as a programmer responsible for engine support in the JogAmp community, I would be reluctant to put a third party library into an engine knowing that there is a lot of duplication.
Obviously that's a big undertaking, so for now I'm just working on one format at a time. What I would like help with is understanding what the data should look like for animation. I understand the basic concepts of skeletal animation, but I could really use some help designing a data model that people will instantly recognise and is intuitive.
There is an example of model using skeletal animation here
Then I'd just convert whatever animation system the source format uses to that bespoke design. For older formats that don't use skeletal animation (like MDL, MD2 etc.), JUMI would probably represent the keyframes as morph targets.
Take care of basing your design on something flexible enough to support several formats. Designing a "better" format to use as an intermediary is very difficult too. Collada has become very complicated, especially since its version 1.4.
PS: I also want to handle exports too. By using that single data structure, it should then be easy to reverse the process and write back into any of the supported formats.
You're right, this is what I did in JogAmp's Ardor3D Continuation to export the meshes in WaveFront OBJ. I'm just a bit worried because some projects like MeshLab and Assimp are very time consuming, lots of people work on them. JMonkeyEngine 2 supports lots of formats but some importers weren't correctly maintained. Why would you succeed in doing something that numerous motivated developers failed? I don't try to discourage you but I see some pitfalls in your plan.
To sum up, if you don't succeed in convincing the developers to use your "super" format (similar to the approach of OpenCTM), you'll have to convince them to embed your library as is (similar to the approach of Assimp). If you fail, it will still be a good candidate to implement a viewing application similar to MeshLab but you can't compete with 3D engines and frameworks developed by numerous developers except if you're a genius. In my humble opinion, sticking to something less ambitious is more viable, for example by avoiding to design a "better" format than the Khronos Group, Adobe and the others, and by keeping your library extremely lightweight so that you have at least a vanishingly small chance to convince engine maintainers to use it (a very few Java developers use their own engines in 3D applications on the long term).
Another solution consists in contributing to those middle and high level APIs instead of working on a separate library. The developers of Unlicense-lib would be very glad to get some help to support much more formats. JogAmp's Ardor3D Continuation is still compatible with ardor3d-openctm...