Hi,

I was trying to work with assimp-all.jar on an android project supporting API 21 and above. When I added this jar and tried to build the project, I get an error saying required mindSdkVersion >= 26. Since it was not mentioned on the README page, I am trying to confirm the same here. Also, if true, are there any plans for backward compatibility?

I'm still working on it but I thought I might as well create the pr now, so that this is visible. There are still a few tests failing. I'm not sure if this is due to the fact that some tests fail on master or that some of the Importers are still trying to access files on the drive directly as I have not yet looked at those tests.

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.

hi, good initiative to wrap assimp for kotlin!

I implemented 'com.github.kotlin-graphics:assimp:v4.0-beta15' (also tried it with beta14) and did a val scene = Importer().readFile("spider.fbx") followed by println("scene has ${scene!!.numMeshes} meshes") yet, that returns 0... hence it also does not load any vertex data in further loading stages as I assume you loop with numMeshes to create each AiMesh. It does seem to count numLights and numCameras correctly. Also, loading an .obj, it all works fine in terms of getting the right vertex data for my buffers. (obviously spider.fbx is the one in your test data)

Any clue what's with that? Oh and a second question, any way to turn the built-in logger more (and less) verbose? e.g. repress material warnings when you don't supply a .mtl and stuff :)

hello，can you help me？ I use android studio to build examples and rely on this project，it occured this error --->Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find com.github.kotlin-graphics:uno-sdk:v0.7.3.

Hi there,

there also seems to be missing a dependency on GLM: AiMesh has e.g. the vertices attribute, which is an ArrayList of AiVector3D, which in turn is a typemap to Vec3, and that is coming from GLM, which is not declared as a dependency in build.gradle.

Hi there!

Some release versions, e.g. 4.0, have SNAPSHOT dependencies in the gradle-created POM, which kind of jeopardizes build stability:

    <dependency>
      <groupId>org.lwjgl</groupId>
      <artifactId>lwjgl-opengl</artifactId>
      <version>3.1.4-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.lwjgl</groupId>
      <artifactId>lwjgl-stb</artifactId>
      <version>3.1.4-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>

I also don't see why assimp needs to depend on lwjgl-openal, lwjgl-opengl, lwjgl-jemalloc, lwjgl-glfw and lwjgl-glfw, as they are not used anywhere. There are also explicit dependencies on the Linux natives, e.g.

<dependency>
      <groupId>org.lwjgl</groupId>
      <artifactId>lwjgl-openal</artifactId>
      <version>3.1.4-SNAPSHOT</version>
      <classifier>natives-linux</classifier>
      <scope>runtime</scope>
 </dependency>

It'd be great if that could be fixed, I'm also more than happy to contribute a PR if that's wanted 👍

cheers!

Hi, after a long break im back. Just tried to clone your changes and unfortunately im missing some classes so im unable to compile.

AiVector3D

Also i have mistakenly deleted the invite to slack could you invite me again so we can try and resolve the issues ive been having?

thanks.

As a newbie to Kotlin, kotlin-graphics/assimp, and Assimp in general, any guidance on what is needed, how things are done, is appreciated.

commit 301d1ae014c7263db1f911285cf130f624d3acc3 Repair readMaterialLibrary's handling of duplicate names. The native Assimp's ColladaParser::ReadMaterialLibrary has, to my mind, an excessive use of high power machinery obscuring both the intent and the actual action. The initial translation to Kotlin missed a bit of syntactic cleverness, resulting in an array bounds exception. If three Collada elements have name="Mary", the action is to name the material library entries "Mary, "Mary 1", and "Mary 2". Test by manually editing a Collada .dae file and just duplicate one of the elements.

commit 15bae1130907d04ca2cc145beca5a01db89c9153 Repair fallback texture CHANNEL guess. This failure was exposed by a Collada file that actually fell to this fallback calculation of the texture channel number. But the coding resulted in the ASCII code for '0'.

commit 2ff8c8532093cd0caaf85865c5e9a7cfea4442bb Propagate Collada import failure info through to user as importer.errorString. The exception thrown because of a duplicate resulted in readFile returning scene=null, but then getErrorString() returned "", and calling from Java invoked under NetBeans, the traceback did not appear anywhere obvious. Even though that exception is now quieted, tracking it down revealed that any unexpected exception in the Collada loader would be caught in BaseImporter where the exception's message was passed to the logger but not copied through to Importer.errorString where the user could get it. My solution is to catch unexpected exceptions in the Collada loader and pass on a message that at least indicates where in the input the problem occurred, and then to put the resulting message where it gets copied to where the user expects a problem report. Checking other exceptions, from Collada loader or elsewhere, seems futile, not not on board with the directive to to the right thing with correct input and spend no significant effort on verifying compliance of the input data.

Hi guys,

I have some problems: running tests from within Idea works flawless.

But running from travis, I get one error:

assimp.obj.obj > wall FAILED
    java.lang.OutOfMemoryError at obj.kt:15

running from Gradle via console:

assimp.obj.obj > wall FAILED
    java.lang.OutOfMemoryError at obj.kt:14

assimp.obj.obj > car FAILED
    org.opentest4j.AssertionFailedError at obj.kt:17

Can someone assist me and try to find out what is going on? (I think OutOfMemoryError might be related to java heap size)

Can anyone reproduce the errors locally from the IDE?

In MemoryIOWrapper I added 2 TODOs. One is about the return value of open. The c implementation of assimp returns null, but the kotlin interface is defined as not null. I think it is ok to throw in this case, but I wasn't 100% sure so I added the TODO. Feel free to remove it.

I also had to implement an InputStream backed by a ByteBuffer. I did not find any implementations out there in any accessible lib so I just chose one from stackoverflow (I sadly forgot to write down the link). As far as I know it is correct.

Oh and I fixed a bug in the build file stoping the tests from being executed 😜

So far my texture list in an AiScene remains empty for FBX and DAE (1.4.1) formats. OBJ does seem to read the texture file names correctly. I've verified that the models do contain textures that come in alright in the assimpviewer application. I've had my artist export the same model through a variety of applications and formats and the end result is the same. Are textured materials only supported through OBJ models in the Kotlin port currently? I've attached a zip of the model in various formats I've been using for testing. Thanks. JoshTest.zip

Hi, I'm unfamiliar with kotlin.

So I download the project into my Linux Mint and then what? I assume that this can be used to generate a Jar that I'll include in my project. But how. Alternatively, via a Maven project.

Hello, I have an Android OpenGL project and am trying to use assimp to load some 3D models in my project. In my build.gradle file, I included this:

implementation "com.github.kotlin-graphics:assimp:4.0"

However, my project fails to build. The first error I see is the following:

More than one file was found with OS independent path 'libglfw.so.sha1'

Any ideas on how to workaround this? When I tried excluding this in the gradle packagingOptions (which I don't think is a good idea, but I tried anyway), I got additional More than one file was found ... errors. All in all, these are the ones that caused the conflict:

libglfw.so.sha1
liblwjgl_opengl.so.sha1
libglfw_wayland.so.sha1
liblwjgl.so.sha1
liblwjgl_stb.so.sha1
logo-mini.png
libopenal.so.sha1
libjemalloc.so.sha1

Any ideas on how to work around this?

I'm creating a POC for visualizing STP files in a Java application. I try to import the step file using the Importer().readFile() method and this gives a

Exception in thread "main" kotlin.KotlinNullPointerException
	at uno.kotlin.UtilKt.getUrl(util.kt:22)
	at uno.kotlin.UtilKt.getUri(util.kt:21)
	at assimp.Importer.readFile(Importer.kt:308)

This by only set this line of code: AiScene scene = new Importer().readFile(fileName, 0); fileName variable is the full path to the stp file.

MD3 sometimes uses relative paths to resolve shaders. It's also possible that other formats reference textures with relative paths. The MemoryIOSystem does not fully support them. It's not possible to use .. to reference the parent directory. There are 3 options to solve this:

1. A simple workaround by adjusting the name of a buffer when passing it to the ioSystem eg. "somePath/../../../scripts/object.shader" as the name for the buffer. This works for now but I don't think it's a permanent solution.
2. modify the ioSystem so that it can handle paths with ".." in them.
3. Move from using String to java.nio.file.Path to qualify the buffers in MemoryIOSystem. This way resolving paths would be trivial but it would require a full implementation of Path, FileSystem and FileSystemProvider. This is a lot of effort and I'm not sure it's worth it.

I think option 2 is the best on. It should work in all cases. Option 3 is overkill as the user should not interact with the ioSystem themself.