Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (805)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LWJGL 3 - Assimp bindings  (Read 20813 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Posted 2016-11-27 09:43:35 »

The latest LWJGL snapshot (3.1.1 build 5) includes bindings to Assimp, a library to import and export various well-known 3D model formats in a uniform manner. It also features various post processing tools, including frequently-needed operations such as computing normal and tangent vectors, ACMR optimization, etc.

The build that comes with LWJGL includes all supported file formats (about 40 of them), so the shared libraries are bigger than usual. Assimp supports cmake, so you can easily create a custom build that includes only the formats you need, making it much smaller. You can then drop it in LWJGL and it will work just fine.

The bindings were contributed by SHC, many thanks to him!
Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #1 - Posted 2016-11-28 08:11:49 »

Best news this year Smiley I want to give a big THANK YOU to everyone who contributed to this. Can't wait to migrate to LWJGL3...I'm a bit late ^^"
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #2 - Posted 2016-11-28 21:00:53 »

Cant wait till this works into LibGDX, knowing the team it'll have some crazy uses x.x

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2016-11-28 21:15:28 »

Looks nice, but forgive my skepticism... 3D models are a nightmare. I'm worried that writing a converter to my own format will essentially be the same amount of work as writing an importer for one of the big formats, like .blend, .fbx or something. That's impossible enough to do for one format, but I'll look into it when I have the time, AKA not soon. =/

Myomyomyo.
Offline ShadedVertex
« Reply #4 - Posted 2016-11-29 07:52:51 »

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?
Offline SHC
« Reply #5 - Posted 2016-11-29 08:20:39 »

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?

Thanks, and no, jAssimp is still the goto for Android.

Offline pateman

Senior Newbie


Exp: 6 years



« Reply #6 - Posted 2016-11-29 20:59:20 »

This is pure awesomeness. Keep up the great work, guys! Smiley
Offline elect

JGO Knight


Medals: 76



« Reply #7 - Posted 2016-11-30 08:12:50 »

Good job guys!

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?

Well, let's say it's good to have alternatives, because each solution has its pro and vs

A binding is relatively fast to implement and is almost change independent

but a pure port has three main advantages, you are under the optimization of the jvm, your whole memory is being managed by the garbage collector and it is available for all those who don't use lwjgl 3.1.1 build5 +. On the other side, of course, it's slower to implement and you need to keep it up with the cpp version, although most of the changes are being done on the last formats
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2016-11-30 09:36:52 »

I'm in favour of pure Java implementations meself.

Cas Smiley

Offline Spasi
« Reply #9 - Posted 2016-11-30 12:41:32 »

Good job guys!

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?

Well, let's say it's good to have alternatives, because each solution has its pro and vs

A binding is relatively fast to implement and is almost change independent

but a pure port has three main advantages, you are under the optimization of the jvm, your whole memory is being managed by the garbage collector and it is available for all those who don't use lwjgl 3.1.1 build5 +. On the other side, of course, it's slower to implement and you need to keep it up with the cpp version, although most of the changes are being done on the last formats

I personally didn't know jAssimp was being worked on. I, too, would love to be able to use a Java library given the choice, especially one written in Kotlin (my language of choice these days). Where it makes sense. IMHO it makes zero sense in this case. There's only one advantage to using a Java library for loading 3D scenes:

- The API is nicer.

OK, so what? Is this the bottleneck when developing a graphics app or game? How much time you'll spend writing your model loading code? The disadvantages:

- You have to write a ton of code to create a replica of something that already exists.
- You have to spend countless hours designing the API and fixing bugs in your implementation.
- You have to do a ton of work to maintain it after it's done.
- If you do add new features, you're doing a disservice to the open source community. If you contributed to the original project instead, all downstream users would benefit.
- Hotspot is magic and GC is magic and we love them both, but doing IO and loading resources is exactly the workload where there's absolutely no benefit to using a JIT and managed memory. All resources associated with a native loader are gone when you're done, but with a Java implementation the JVM has loaded a lot of Java code, has wasted a lot of time optimizing it... and then it's just stays there. Besides, do you really think it's easy to beat a native implementation (in both CPU time and especially memory overhead) with pure Java? Not saying it's impossible, but is this the best use of a developer's time?

Finally, I'd like to address the comment on availability. You don't have to "use LWJGL" to use LWJGL's assimp bindings. The library is now modular, you can choose to use the set of bindings you need and nothing else. If that means assimp only, then yes, that works fine.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #10 - Posted 2016-11-30 13:57:15 »

Hi

do you really think it's easy to beat a native implementation (in both CPU time and especially memory overhead) with pure Java?
It's not easy to me as assimp supports numerous formats but there are numerous importers and exporters for several scenegraph APIs, engines and frameworks decently optimized to avoid memory leak and you can modify the settings of the JVM to unload unused classes. If you want to compete with MeshLab, you'll need the 40 formats but I doubt that all are needed for a game or even for the tool set of a game in which you may use a few editor formats (.blend, .max, ...), a few interchange formats (Collada, U3D, ...) and a runtime asset delivery format (gltf, ...) or your own one. In my humble opinion, some popular formats are already supported enough by the existing Java ecosystem to drive such a binding not very appealing in certain particular cases but I agree with elect "it's good to have alternatives" and this binding can be very useful in some use cases.

I remind that using a "foreign" API to load models in a scenegraph API may add some overhead to convert the models in the object model of this API into the object model of the scenegraph API.

Personally, I've read tons of "loaders" in various programming languages and I advise you all to be very careful as I've found numerous APIs supporting tons of formats having numerous caveats or limitations. Sometimes, those limitations are commented only in the source code and not mentioned in the documentation.

Assimp supports Modo (.lxo). As far as I know, there is no free or open source Java importer supporting this format. This binding is then welcome to load files in this format  Smiley

Good job and keep up the good work.

Julien Gouesse | Personal blog | Website | Jogamp
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2016-11-30 14:02:06 »

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.

Cas Smiley

Offline elect

JGO Knight


Medals: 76



« Reply #12 - Posted 2016-11-30 14:20:28 »

How much time you'll spend writing your model loading code?

Considerably more than the binding of course, but I'd say not so much as you may think

The disadvantages:

- You have to write a ton of code to create a replica of something that already exists.

True, but kotlin helps to reduce a lot of the boilerplate (and make it cool)

- You have to spend countless hours designing the API and fixing bugs in your implementation.

Nes (no+yes) :p

We are focusing to stick close as much as possible to the cpp version in order to minimize API designing (if you want to call it so, since we are "simply" translating, but also exploting some cool stuff jvm offers)

- You have to do a ton of work to maintain it after it's done.

True, but the same strategy also alleviates the manteinance.

- If you do add new features, you're doing a disservice to the open source community. If you contributed to the original project instead, all downstream users would benefit.

I wrote so far stl and obj importers, I found 2 small bugs and a type, all pulled, accepted. Everything smooth everything nice Smiley

Anyway, what kind of feature are you thinking of? Because as a simple compiler, I dont have any idea of any feature assimp would need that it doesn't already have, and if I'd ever have I'll discuss first with them because maybe they already have a solution for that or a reason why they don't have that yet, you never know.

Again, the same strategy mentioned before helps to keep everything in sync


- Hotspot is magic and GC is magic and we love them both, but doing IO and loading resources is exactly the workload where there's absolutely no benefit to using a JIT and managed memory. All resources associated with a native loader are gone when you're done, but with a Java implementation the JVM has loaded a lot of Java code, has wasted a lot of time optimizing it... and then it's just stays there.

Not all resources are gone, there is something you should free manually when using a binding, I know for sure the scene is one of these for example.

However, it depends, if you look at the material management in assimp is kind of crap, they also themselves say that "(it's an ugly macro for historical reasons, don't ask)". If you want to say it, that's really the only redesigning I really made.
The java/kotlin side is much smaller and nicer in comparison.

The binding adds on top of cpp performances, the binding calls plus the java side. On java you only have.. java, the whole code of your is optimized by the jvm, to determine if this is more or less than the first option, you should profile that.

Howver, let me underline, again, Spasi, that performance is absolutely not one of the main reason to do this port. But if you are touching this point, I can show you that also on cpp the performances aspect is not so much a priority it as looks like from here (this, for example)
Assimp is a very old project, and some decisions about performance have been postponed because of retro-compatibility.

Besides, do you really think it's easy to beat a native implementation (in both CPU time and especially memory overhead) with pure Java?

I don't know, I don't care (or at least as far as they are comparable, which I truly believe), but If I have to answer that, CPU maybe, we have a chance, memory overhead forget it (but I can bet any moment we are nowhere more than an order of difference).

I dont have any serious metric since it was never the point, but once, writing the test case of gli, I can tell you java was barely faster in cleaning a texture than the cpp in debug mode, this kind of surpriced me nicely.

Not saying it's impossible, but is this the best use of a developer's time?

No, of course, but do we always use our time at the best? If you do, good for you, because I don't  Cheesy

Jokes apart, one of the reasons I do this is because I think there is a need for it (not vital, but still) and thinking that I can also do something for the others gives personal satisfaction.

I read continuosly, from time to time, a lot of people joking/despise the java developers because they use a toy language, but also a lot of people that when asked why the went c/c++, they complains there are no tools on the java side so they simply stick with that.

Well, I also want to prove this is wrong. I think java language is a serious medium for game/graphic business and the community is big enough to have its own porting  Smiley

All your points are kind of valid, Spasi, but it's a long term project and hopefully, if more and more people get involved, we can accelerate the developing, at the end, it's "mostly" a matter of translating importer by importer, that's really 80% of the work.

Finally, I'd like to address the comment on availability. You don't have to "use LWJGL" to use LWJGL's assimp bindings. The library is now modular, you can choose to use the set of bindings you need and nothing else. If that means assimp only, then yes, that works fine.

Good to know, I didn't know that.
Offline CoDi^R
« Reply #13 - Posted 2016-11-30 16:17:26 »

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.

Cas Smiley

 Pointing Enjoy your medal, because this! Grin

Robotality - steamworks4j - @code_disaster - codi^r @ #java-gaming
Offline theagentd
« Reply #14 - Posted 2016-11-30 16:40:54 »

Assimp is slow. Converting the same thing to Java is still slow. If you're loading random file formats into your final game build, you're doing it wrong. Just convert your models to your own internal format and load those instead. Much much faster, no unnecessary data, no library asset --> game asset converting overhead, etc. IMO, we don't need a pure Java implementation of an offline tool.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #15 - Posted 2016-11-30 16:59:22 »

There are the two attitudes:
a) give me something that works and which I can use without having to put much effort into it; vs.
b) I have unlimited time and money to put effort into developing the optimal solution.
And correspondingly people being somewhere between these two extremes.
Assimp clearly targets more towards a), whereas you are likely at b).
Offline elect

JGO Knight


Medals: 76



« Reply #16 - Posted 2016-11-30 17:13:03 »

Exactly, or to put in another way

a) flexibility <-----> b) performance

You are clearly not the target, theagenttd
Offline theagentd
« Reply #17 - Posted 2016-11-30 18:46:49 »

You are clearly not the target, theagenttd
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.

Example: I don't want to have 30 different light types (or any lights at all), crazy quaternion interpolation bézier parameters, complete scene graphs with interleaved mesh "nodes" and skeleton "nodes" and texture "nodes" with 637 different matrices in each node used for different purposes with no clear explanation for what does what, support for four different animation systems, baked in textures in the model file, and even more shit. I just want a number of meshes grouped by material (1 mesh per material), simple key framed skeleton animation support and that's it.

Unless you've written a rendering system on the level of Blender or Maya or something like that, 75% of all 3D file formats are so much overkill and/or stores the data in a completely different much more complicated way that it'll make you cry yourself to sleep for months after trying (and failing) to implement them (assuming implementing the rendering system itself didn't already break you), and such a rendering system would perform so badly for a game that it'd be completely useless. The other 25% of 3D formats don't support skeleton animation and are useless to me.

Since all 3D model formats are overkill and/or not immediately compatible with my rendering systems, I need to do a lot of conversion. This means implementing a crapload of very complicated functionality: Flattening a scene graph and merging mesh nodes based on material but not the ones that are separately animated, make up material names, figuring out how this particular model format f**ked up bone matrices, bone-vertex mappings, bone indices, etc, baking the IK-joints into the normal joints, implementing advanced joint/quaternion interpolation that exactly matches whatever the program used to generate the file format uses, etc. This takes months if not years to implement for a complete model format, and it's slow as f**k to do every time you import something. If you are ever planning on releasing anything to the general public, you NEED to use a custom file format that only contains what you need in the right format already, or you're looking at several minutes of load times for each level.

Nobody has unlimited time or money, no matter what their goal is. This is not something that will improve my games if I do it "right". I just want something that works (as in does everything I need it to do) with the minimal amount of work invested by me. Investing more time isn't gonna make my games better. Currently, my by far simplest solution was to skip working with existing 3D model formats completely and just writing a Blender plugin that extracts what I need and generates a file in my custom model format. It took me around 2 weeks to get the essentials working.

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.


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.


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.

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2016-11-30 19:12:03 »

A rant worthy of a medal.

As for the Java vs native discussion - there is no such thing as time "wasted" on a Java implementation. I like things being in Java because they're easy to debug, easy to build, easy to maintain, easy to fix, easy to steal bits of code from. Native code adds a thick layer of impedance over all of that. And native code is pretty frequently fraught with the exact sorts of bugs that we switched to Java to avoid in the first place.

Cas Smiley

Offline theagentd
« Reply #19 - Posted 2016-11-30 19:15:42 »

A rant worthy of a medal.

As for the Java vs native discussion - there is no such thing as time "wasted" on a Java implementation. I like things being in Java because they're easy to debug, easy to build, easy to maintain, easy to fix, easy to steal bits of code from. Native code adds a thick layer of impedance over all of that. And native code is pretty frequently fraught with the exact sorts of bugs that we switched to Java to avoid in the first place.

Cas Smiley

Thanks. =P

That's a good point, and I agree with that opinion 100%. However, in this case we're talking about replicating existing functionality in Java. I'm assuming that Assimp has its fair number of users already, so most bugs should be fixed by now. Manually converting the whole thing to Java would just add an extra layer of possible bugs on top of the original code, and cause my engine to rely on even more people that I have no real influence over. I see no real benefit in this situation from a Java version of jAssimp.

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2016-11-30 19:32:03 »

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  Kiss

Cas Smiley

Offline elect

JGO Knight


Medals: 76



« Reply #21 - Posted 2016-11-30 19:37:32 »

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

Example: I don't want to have 30 different light types (or any lights at all), crazy quaternion interpolation bézier parameters, complete scene graphs with interleaved mesh "nodes" and skeleton "nodes" and texture "nodes" with 637 different matrices in each node used for different purposes with no clear explanation for what does what, support for four different animation systems, baked in textures in the model file, and even more shit. I just want a number of meshes grouped by material (1 mesh per material), simple key framed skeleton animation support and that's it.

Unless you've written a rendering system on the level of Blender or Maya or something like that, 75% of all 3D file formats are so much overkill and/or stores the data in a completely different much more complicated way that it'll make you cry yourself to sleep for months after trying (and failing) to implement them (assuming implementing the rendering system itself didn't already break you), and such a rendering system would perform so badly for a game that it'd be completely useless.

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.

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

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  Wink

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  Wink

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.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #22 - Posted 2016-11-30 19:48:06 »

.. and there is alot native code in jassimp

https://github.com/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.
Offline theagentd
« Reply #23 - Posted 2016-11-30 20:27:09 »

@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.

Myomyomyo.
Offline gouessej
« Reply #24 - Posted 2016-12-01 12:42:14 »

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?

.. 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:
https://github.com/java-graphics/assimp/tree/master/src/main

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.

Julien Gouesse | Personal blog | Website | Jogamp
Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #25 - Posted 2016-12-01 15:40:24 »

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.
Offline gouessej
« Reply #26 - Posted 2016-12-01 19:36:44 »

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.

Julien Gouesse | Personal blog | Website | Jogamp
Offline elect

JGO Knight


Medals: 76



« Reply #27 - Posted 2016-12-06 19:43:48 »

@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

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  Cheesy

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..
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (585 views)
2019-09-04 15:33:17

hadezbladez (5526 views)
2018-11-16 13:46:03

hadezbladez (2407 views)
2018-11-16 13:41:33

hadezbladez (5788 views)
2018-11-16 13:35:35

hadezbladez (1228 views)
2018-11-16 13:32:03

EgonOlsen (4667 views)
2018-06-10 19:43:48

EgonOlsen (5685 views)
2018-06-10 19:43:44

EgonOlsen (3200 views)
2018-06-10 19:43:20

DesertCoockie (4102 views)
2018-05-13 18:23:11

nelsongames (5118 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!