I'm an occasional contributer/junior dev for an open source 3d modeling/rendering/animation package written in java. I'm currently looking at the feasibility of plugging in Assimp as a primary way to import/export standard file formats, instead of our (limited) homegrown importers. I realize that currently, the jassimp port is not finished.
I might be able to put some effort into helping finish that, but need a little more info first. About how much needs to be done to get export capability through jassimp?
Our priorities would be:
Load from supported file formats
Export to supported file formats
We would not need any ability to manipulate/edit in memory, as we have our own internal structures that would be used for authoring or editing assets.
Given this, would we be better off trying to contribute to jassimp? Or might we find a reason to simply access the native interface through JNA/JNI?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Giuseppe, Thanks for the link. I'm thinking that a full java translation is a bigger project than I'd have time to drop into, especially since Kimmi has a partially-finished wrapper that will be easier to keep up to date when done.
Kimmi, not sure if your question was directed to myself or Giuseppe. In my case, I have not yet done any work to try using jassimp. Before I begin, I would like to have an idea of how much work completing at least export support would be. (I would be glad to help with this, but I'm a JNI newbie, so I'll be learning as I go)
I also have to consider the mapping that I would have to create between assimp meshes and our internals. For example, our native triangle mesh requires that its vertices be listed in counter-clockwise order, and we specify smoothness, to be interpreted by a subdivision algorithm, rather than face/vertex normals, as many formats seem to do.
I'm sure there are other things I'll run across, but that is one reason I'd like to plan well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi to the Assimp team!
I'm an occasional contributer/junior dev for an open source 3d modeling/rendering/animation package written in java. I'm currently looking at the feasibility of plugging in Assimp as a primary way to import/export standard file formats, instead of our (limited) homegrown importers. I realize that currently, the jassimp port is not finished.
I might be able to put some effort into helping finish that, but need a little more info first. About how much needs to be done to get export capability through jassimp?
Our priorities would be:
We would not need any ability to manipulate/edit in memory, as we have our own internal structures that would be used for authoring or editing assets.
Given this, would we be better off trying to contribute to jassimp? Or might we find a reason to simply access the native interface through JNA/JNI?
Hi Luke,
I am doing a port of Assimp, https://github.com/elect86/jAssimp
I did mostly of the core part (I'd say 60/70%).
Now it is only a matter to add each singular importer for each format, at the moment I started with MD2
You are very welcome to help :)
Ciao,
Giuseppe
Have you already tried our java port ( at port/jassimp ).
Kimmi
Hi Kimmi,
yes, I took a look, but it is a wrapper, it always relies on the C version.
I'd like to have pure java, in order to just add a unique jar to have jAssimp working
Last edit: Giuseppe Barbieri 2015-09-18
Hi Giuseppe, Thanks for the link. I'm thinking that a full java translation is a bigger project than I'd have time to drop into, especially since Kimmi has a partially-finished wrapper that will be easier to keep up to date when done.
Kimmi, not sure if your question was directed to myself or Giuseppe. In my case, I have not yet done any work to try using jassimp. Before I begin, I would like to have an idea of how much work completing at least export support would be. (I would be glad to help with this, but I'm a JNI newbie, so I'll be learning as I go)
I also have to consider the mapping that I would have to create between assimp meshes and our internals. For example, our native triangle mesh requires that its vertices be listed in counter-clockwise order, and we specify smoothness, to be interpreted by a subdivision algorithm, rather than face/vertex normals, as many formats seem to do.
I'm sure there are other things I'll run across, but that is one reason I'd like to plan well.