elect86
commented
6 years ago First, a disclaimer: I'm a complete Kotlin noob and I'm learning as I go.
Oh don't worry, everyone has to start from somewhere sooner or later :)
So, did you like it? Kotlin is generally one of the most loved language in statistics and its adoption is rising strong..
I have a Java project that requires a good way to load in models, and LWJGL's assimp bindings are kind of bare, and any tweaking to assimp itself would require doing C++ and a custom build of LWJGL, so I can't be bothered.
Glad to read that, because that's exactly my intention: having a full implementation shaped somehow for the jvm platform and the jvm developing environment.
This seems like a better option, but there was a lack of the IOSystem interface from the original library that allows for custom filesystems ( implements Open/Close read/seek/write functionality ).
Yep, that is (was) one of the points on the todo list. One further point is to move to kotlin-multiplatform (more here and here). This would easier the co-existence of desktop and Android (and iOS)
I've went ahead and added that, along with a default implementation that just uses regular File[s]. I've also modified a few importers to make use of them, but haven't yet implemented those who need random access instead of an InputStream/BufferedReader. Tests all run fine, even whose who weren't working in the master revision for some reason, even though I didn't touch that.
We'll work on that step by step, that's fine for a transition process
I've also fixed two issues with the Collada loader that would not parse files with vertex weights ( or at least, wouldn't parse mine ). The first issue was related to an ArrayList being indexed but not initialized with any capacity, I fixed it by changing it into a LongArray.
That's great, thanks
The second one was a -1 access when disabling ASSIMP_LOAD_TEXTURES ( a feature the cpp version doesn't have and I really need )
I'm glad to read that too, I wanted to (have an option to) destinate as much as possible boilerplate code to the lib and leave the application as minimal as possible
Finally, I must ask whether it is planned to drop the requirement from having LWJGL in this library's path. It's potentially causing conflicts with other version of LWJGL, and generally unwanted (the original assimp has no such dependencies). It's something that would make this library much more clean, at least in my eyes.
At the moment no, but if it's causing conflict we can take in account it.
As far as I recall, it's just a pure convenient use at the moment, nothing critical, except the gli dependency, for the texture loading (it has to do with native memory management)
Would it make sense (and would you available) to work on a brand new branch for all of those changes?
Thanks again for the huge push :)
Sylvyrfysh
Hugobros3
First, a disclaimer: I'm a complete Kotlin noob and I'm learning as I go.
I have a Java project that requires a good way to load in models, and LWJGL's assimp bindings are kind of bare, and any tweaking to assimp itself would require doing C++ and a custom build of LWJGL, so I can't be bothered. This seems like a better option, but there was a lack of the IOSystem interface from the original library that allows for custom filesystems ( implements Open/Close read/seek/write functionality ).
I've went ahead and added that, along with a default implementation that just uses regular File[s]. I've also modified a few importers to make use of them, but haven't yet implemented those who need random access instead of an InputStream/BufferedReader. Tests all run fine, even whose who weren't working in the master revision for some reason, even though I didn't touch that.
I've also fixed two issues with the Collada loader that would not parse files with vertex weights ( or at least, wouldn't parse mine ). The first issue was related to an ArrayList being indexed but not initialized with any capacity, I fixed it by changing it into a LongArray. The second one was a -1 access when disabling ASSIMP_LOAD_TEXTURES ( a feature the cpp version doesn't have and I really need )
Finally, I must ask whether it is planned to drop the requirement from having LWJGL in this library's path. It's potentially causing conflicts with other version of LWJGL, and generally unwanted (the original assimp has no such dependencies). It's something that would make this library much more clean, at least in my eyes.