There’s also an old project to translate Assimp into Kotlin, which I believe should make it easily accessible to JVM apps such as JMonkeyEngine, with appropriate glue.
I realize JME already has a decent importer for glTF/glb, and that’s the backbone of our recommended asset pipeline for most projects. However, it seems likely we could leverage Assimp to support formats like FBX, OBJ, and Blend better than we currently do.
So … does anyone have practical experience in this area?
I have used assimp and lwjgl3 in my own playground. should be kind of easy to convert it to jme. i have working models but no animations as far i remember.
The problem is imho the tight coupling with lwjgl3 and i don’t know what happens if people trie to use lwjgl3 and lwjgl2 in the same project.
I have been using assimp both with jme and without it (raw LWJGL and c++) for several years.
One of the most difficult issues to work around is their material system. They attempt to standardize the material as it is imported, so it can be difficult to figure out what the actual material on the model is.
I personally use it for only things other than gltf, with gltf I use my own importer. And with assimp, most of my code is correcting the materials.
I decided to pursue the idea importing 3-D models into JME via Assimp. My goal is to create an open-source add-on library (or maybe 2) that can import a wide variety of model assets, as an alternative to jme3-plugins, jme3-blender, and RyzomConverter.
I’m working with the lwjgl-assimp bindings for now.
As with Minie, I don’t envision this becoming part of the Engine any time soon.
I’ve got code that works for meshes and materials in Ogre and OBJ formats—at least the handful I’ve tested so far.
My to-do list:
Establish a public repo at GitHub just as soon as I settle on a name for the project. (The current front-runner is “MonkeyWrench”, with “ImpStar” as the runner-up.)
Deal with rigs and animations.
Test many more models in various formats.
Try using the Kotlin translation of Assimp and compare with the LWJGL bindings.
Compare with jme3-plugins.
I’m also interested in using Assimp to export JME scenes into formats other than J3O and JME-XML, though I don’t have a use case in mind.
Working directly with LWJGL has made me more aware of its capabilities. It also provides bindings for:
FreeType, a font-rendering library that might provide a good alternative to jME-TTF
Opus, an audio codec that might provide a good alternative to j-ogg-all
(I also know there’s been recent interest in using its OpenXR bindings as an alternative to OpenVR.)
On the font/text rendering topic, LWJGL also has a HarfBuzz binding, which is important for a number of text rendering concerns (especially when dealing with non-Latin alphabets).
When you import goods into a country it has to go through the customs agency. Also a pun with “custom formats” I guess.
Not a lot of thought behind it really
You could play off the one part of AssImp and call it MonkeyButt. lol
Thank you for the suggestions. I’ve created a public repo at GitHub:
Naming software projects is tricky. I chose the name because:
It hints at a connection to JMonkeyEngine without suggesting that the JMonkeyEngine project has endorsed it.
A monkey wrench was an adjustable wrench (spanner) that could grip fasteners of many different sizes. The name implies versatility, since a single monkey wrench did the work of a large collection fixed-size wrenches.
For native speakers of English, it’s easy to remember, pronounce, and spell. And since it refers to a familiar concrete object, it leads naturally to a logo (in case the project ever needs one).
The logo I had in mind for “ImpStar” would’ve referenced the imperial star destroyers of the Star Wars entertainment franchise, a vivid image but perhaps not a wise choice.
If it was me I probably would have picked “jme3-assimp” or “JmeAssimp”. Besides the other benefits, it is also more “search” friendly I think. If I were to search for an assimp importer for JME, usually that is the first thing that comes to mind.
Good points. “jme3-assimp” was one of my first thoughts also.
Unfortunately “ass” has strongly negative connotations in English, which is perhaps why Assimp is so often referred to by the bland/cumbersome moniker of “the Open Asset Import Library” and also why the project’s ReadMe apologizes for the name: https://github.com/assimp/assimp#why-this-name
Baboon would have been a good name for the library. Only folks “in the know” would know it’s a reference to the first part of AssImp.
…and the person who named assimp certainly knew what he was doing at the time. Like, “gimp”, they may look at it differently today but there is no way that wasn’t on purpose originally.
Progress was slow this week due to health issues, but I believe those are resolved.
The library and test app have been committed to the public repo.
Experiments with the models in jme3-testdata (including the old 3.1.0 version) have revealed some issues:
The library hasn’t processed the “Oto” model. I let it run for over a minute, but it didn’t complete. Since the jme3-plugins loader completes in less than a second, I suspect an infinite loop in Assimp v5.2.5 . I’ll investigate further and open an issue if it seems appropriate.
A couple of the Ogre materials in jme3-testdata specify shininess using the 4th argument of the specular color, which Assimp seems to ignore. This is a minor issue, but it might warrant opening an issue or submitting a pull request.
Four of the Ogre models in jme3-testdata specify materials using “.j3m” files. Assimp never finds these materials, probably because it doesn’t understand the file format. (Hardly surprising since, as far as I know, it’s specific to JMonkeyEngine). One solution might be to add a hook for Assimp to request help reading materials from files. Another approach might be to contribute a J3M reader to Assimp.
A couple of the models in jme3-testdata have “.scene” files, which I believe are from the Ogre engine. Apparently Assimp doesn’t recognize that format.
Loading the “.blend” files from jme3-testdata:3.1.0-stable yields material properties that aren’t handled, diagnostic messages, and strange-looking results. I’ll investigate. However, I don’t want to get hung up on particular models, since the jme3-blender:3.3.2-stable library also has difficulty loading many of these.
Rigs and animations and embedded textures are still on my to-do list, as is testing FBX/glTF/IQE assets and investigating the Kotlin translation.
Rigs and animations and embedded textures are still on my to-do list
Those seem to be working now, though animations that include spatial tracks or morphs are not converted yet.
I opened Assimp issue 5242 to document a common failure mode for old “.blend” files, such as are found in jme3-testdata-3.1.0-stable. That issue was closed (rather hastily) in the wake of yesterday’s bugfix release of Assimp.
The past week has increased my appreciation for the difficulties of loading 3-D models into JME.
Rigs, animations, and embedded textures now seem to work okay. Animations include skeletal tracks, spatial transform tracks, and morphs. My code also handles cameras, point lights, and directional lights. Ambient lighting is on my TODO list.
The focus of testing has shifted from jme3-testdata to glTF-Sample-Models. These are well-known test models Assimp should be able to cope with. I look forward to testing FBX and IQE assets soon.
There are plenty of issues. Materials are problematic, at least for physically based rendering (PBR). In some cases, the metallic-roughness texture winds up in the base-color slot of the material.
The project has grown to 3600 lines of Java code (not counting blank lines and comments), of which 75% are destined to become a runtime library.
The project isn’t ready for beta testing yet, but I’m open to constructive feedback. In case you want to experiment or tinker with MonkeyWrench, I expanded the README file with instructions for building/running the test apps from scratch.
