Hydroque:
I suggest you take a look at the source code, it’s a lot easier for both of us.
You do NOT want one class per file format. The entire point is to be able to write your own code to convert JUMIMesh to your own internal format. If you have to do that per file format anyway, then JUMI is pointless.
Profile your application (perhaps using VisualVM, which is very easy to use), and if you’re running into memory issues then look at the cause. Use the sample function. Same goes for performance problems. There’s no need to micro-optimize the structure of JUMI because it’s very unlikely that the few KBs or MBs of RAM and milliseconds of time it occupies are the source of your (potential) issues.
And if you just want everything to be 100% efficient, well, you’re using the wrong language because the garbage collector has other priorities than you do. C++ with reference counting and smart pointers would be a better fit, I think, now that compilers support C++11 the language isn’t half bad to work with.
Programmers find every excuse not to write the best code ._.
“The best” is a relative term and with all the different hardware configurations good Damn luck so…
Trolololololol
The best code is the code that does the job, is readable and doesn’t take years to write. There’s no point in optimizing something if a simpler solution is just as fast, making it the best solution.
Thread Resurrection Warning!
I’ve checked here and the GIT hud…but is this project being used and/or in development?
Working with FBX, curious to find a possible Java bridge.
Thanks
FBX remains our bugbear too… if we could reliably use FBX in Java applications as well as Unity can manage we’d be very happy bunnies.
Cas 
So JVM Open Asset Import Library (Assimp) is different from JUMI (this original thread)…Is it the successor?
Sorry I’m not familiar with Assimp but looking now.
Ok Assimp looks great and active. How is the .fbx supported since it’s closed? (we use the C++ .fbx API from Autodesk for student projects).
Grrr, I see it doesn’t WRITE .fbx only load… I need a .fbx writer…
Support for .fbx export is currently in progress. Btw, LWJGL 3 provides native Assimp bindings.
Might be interesting to some, looks like glTF 2 (also supported by Assimp) is picking up steam:
Godot - Why We Should All Support glTF 2.0
Facebook - Richer 3D Posts
Wow, LWJGL has everything.
So are you generating the bindings, like with GlueGen or something? I noticed that the other one appears to be hand coded bindings.
It never meant to be a successor, although it might be seen like that because I basically started to work on that around the same time Neoptolemus had to stop for other priorities in RL
I’m not really in licenses stuff, but specs should be freely available
Well, if you really really need that, you might want to contribute and write it. It shouldn’t be too complicate (at least the ascii version).
[quote=“shawnkendall,post:53,topic:53981”]
Yes, using a custom generator, written in Kotlin.
The Assimp project is very active, so it is recommended to stay with the LWJGL nightly/snapshot builds if you use it. You’ll get the latest updates more regularly that way.
Btw, elect not only develops kotlin-graphics/assimp, he also contributes fixes upstream to the native project. Which is awesome and the kind of thing I really appreciate in OSS development.