LWJGL 3 - Assimp bindings

[princec]

Indeed. In fact porting from original native code is usually not a good idea anyway as it’s usually C++ centric, and they do things Wrong over there :-*

Cas

[elect]

@theagentd

Do you mean Assimp or jAssimp?

Assimp itself is perfect for my use. My problem has always been that 3D model formats contain way too much useless information that I have to sift through, and all the actually useful information is in a wrong format and extremely hard to decode unless your engine/tool uses the exact same data/object structures as the 3D model format assumes.

Both, I am not doing anything else than translating what Assimp stores in cpp in java, the same data will be stored, either you consider them useful or useless

[quote=“theagentd,post:18,topic:57969”]
I understand your frustation, but I think then you should blame the source, rather than the format itself. Or the program used, if your designer can’t custom the export that much.

@theagentd

My worry here is that if Assimp can support all of these completely crazy Blender, Maya and Autodesk that you can fit the entirety of the Toy Story 1-53 movies, their PC games, console ports of said games, music files, autographs and dinosaur fossil discoveries since the medieval ages in them, then Assimp must support essentially everything that every single model format has ever supported. This would essentially mean that Assimp’s internal objects are by far the hardest thing ever to port to your own minimal custom format. If I need a team of 10 people and 2 years to extract 5 pieces of information from it, then it doesn’t actually solve any real problems. In the end, all you need is a single solid workflow from one 3D modeling software to your game, and everything else can be funneled through that path.

Sure, but that’s the challenge when you declare support for over 40 formats

@theagentd

In light of all this, I can not agree that jAssimp is significantly more useful than Assimp in any regard. On Android, the performance/memory usage/load time argument is 10x more important so a custom file format is even more required. This means that (j)Assimp’s only real usage is in engine tools/editors running on beefy PCs used to export stuff into your own custom formats, at which point the convenience of having a pure Java implementation is far outweighed by having an automatically generated binding to a maintained project with no manual work/maintenance.

Well, you don’t have to agree. Unless your game loads assets in real time, the memory usage (the only one I am sure it’ll be worst) is relatively an issue.

Other than that, everything is always relative, I mean, if you need to squeeze to the last bit, you have to go c or cpp. But we do use java (you included I guess) because we repute its advantages valuable. I see the same in doing a pure java porting, but this, of course, is my point of view

@theagentd

EDIT: Please be aware that this is my opinion from an indie game developer perspective. If you are just making a small game for fun where you just want to be able to throw in whatever 3D model format you have lying around… you’ll still be doing 99% of the job of writing your own custom format. No matter what you use, you will be taking the data returned by (j)Assimp when it loads the file and extract the stuff you need into your own custom Model object that you can actually render. From there on, it’s a very small step to add binary serialization so you can save that Model object to disk and load it directly again.

Sure, it’s clear

My main object is to have support for few formats, such as stl, obj, ply, collada, md2, md5 and fbx. If some user want to have something I may port that as well.
Plus exploiting some cool post-processes to modify the original mesh, without reinventing the wheel.

[basil]

… and there is alot native code in jassimp

assimp/assimp/blob/master/port/jassimp/jassimp-native/src/jassimp.cpp

… interesting thoughts on the native-pure sides tho’.

my 2 cents : as always it depends on the context. for instance - it would be hell to port fmod to pure java. frequent updates render maintenance stupid. on the other hand - GLM bindings would not compete with JOML.

[theagentd]

@Elect: I’m not trying to discourage you when it comes to jAssimp; I’m just saying that I don’t think the benefits (no native code, smaller file size) outweighs the drawbacks (porting effort, maintenance as new features come out, etc).

I will be evaluating Assimp and jAssimp at some point decently soon, presumably mid-end January next year. I’m completely drowned in school work ATM and my exams are in January, but once they’re done I’m gonna try to sit down and look through the documentation and get some simple stuff working. I’m fairly sure that jAssimp will be easier to use than the huge amount of interaction with native code and data that the Assimp binding will need, so I may try jAssimp first. However, do realize that if we were to adopt jAssimp for our modeling importing we’d need pretty speedy bug fixes and possibly feature requests (not likely though).

I really don’t envy your project, man. 3D modeling formats are a frigging nightmare. That’s why I’m worried about how long you’ll be able to “last” after a couple of months of debugging why the that FBX file doesn’t look like the spec says it should look, or that .blend file is completely different when a new version of Blender comes out, or why the hell you have to implement an entire programming language parser to decode a .x 3D model file. It’s nothing about you personally; I just know that I wouldn’t be able to do that for long. >___> If you seem to be able to handle it and maintain it, jAssimp would be my first choice.

[gouessej]

@princec

Possibly the best use of it is just loading stuff and converting it to whatever proprietary format is best for your game engine. Ie. as a tool, not a deployable part of a game.

Ok but then the performance would be less important than if it was deployed inside the game, wouldn’t it?

@basil

… and there is alot native code in jassimp

basil_, you make a confusion between another library with the same name and elect’s jassimp. He talked about Kotlin, he really uses it as you can see in his source code:

kotlin-graphics/assimp

theagentd, you can use JavaBlend for Blender files and FBX is proprietary so you get what is expected from this kind of format.

By the way, there are already some Java APIs providing some importers and exporters, Unlicense supports the .x format and I was a bit wrong as it partially supports .lwo (Modo), jReality, JMonkeyEngine and JogAmp’s Ardor3D Continuation have some importers and exporters too. If elect succeeds, I’ll see his project more as a source of code to implement importers and exporters in various engines rather than something I’ll put into my projects as is. I spent about 10 days in writing an importer for the .ply format, I know that it’s time consuming.

[h.pernpeintner]

THANK YOU for mentioning JavaBlend - how is it possible that I already wasted hours of time searching for blender-java-interoperation and did not find anything.

[gouessej]

You’re welcome. I like this library. In my humble opinion, its only drawback is the lack of versioning as it would help to follow and understand the changes.

[elect]

@theagentd

@Elect: I’m not trying to discourage you when it comes to jAssimp; I’m just saying that I don’t think the benefits (no native code, smaller file size) outweighs the drawbacks (porting effort, maintenance as new features come out, etc).

Don’t worry, I know you weren’t

@theagentd

I will be evaluating Assimp and jAssimp at some point decently soon, presumably mid-end January next year. I’m completely drowned in school work ATM and my exams are in January, but once they’re done I’m gonna try to sit down and look through the documentation and get some simple stuff working. I’m fairly sure that jAssimp will be easier to use than the huge amount of interaction with native code and data that the Assimp binding will need, so I may try jAssimp first. However, do realize that if we were to adopt jAssimp for our modeling importing we’d need pretty speedy bug fixes and possibly feature requests (not likely though).

Glad to read that, however, this is an hobby project, so I can’t offer of course professional support, but I can offer some spare time of mine plus hospitaly and collaboration, pushes included

@theagentd

I really don’t envy your project, man. 3D modeling formats are a frigging nightmare. That’s why I’m worried about how long you’ll be able to “last” after a couple of months of debugging why the that FBX file doesn’t look like the spec says it should look, or that .blend file is completely different when a new version of Blender comes out, or why the hell you have to implement an entire programming language parser to decode a .x 3D model file. It’s nothing about you personally; I just know that I wouldn’t be able to do that for long. >___> If you seem to be able to handle it and maintain it, jAssimp would be my first choice.

Fbx? Well, reading the mainlist, that format is creating troubles on cpp in the first place…

However, let’s see how it turns out…