Arcore-android-sdk: The obj loader is broken

[dhruv2295]

HI, I was trying to load a fairly complex obj file using ar core obj loader.
But the render was completely messed up. This is what it rendered

while it should look somewhat like this.

Can someone please look into it. Thanks

[javagl]

Crossref: https://github.com/javagl/Obj/issues/4 (including a link to the actual model)

[javagl]

Just to summarize: The main problem here seems to be that the OBJ file basically contains >65k vertices, so that its indices do not fit into unsigned short values (which is required for rendering it with OpenGL ES 2.0).

Possible solutions are discussed in the linked issue, but I think that this issue here could be closed.

[nathanmartz]

Thanks for the bug report. That's most likely the issue, and the best fix is to simplify the model or split it into multiple pieces.

[asos-savvasdalkitsis]

Surely ARCore as a library needs to provide a simple way to load complicated models out of the box without requiring models to be manually split to multiple parts no?

This limitation is quite severe and competing solutions like ARKit don't seem to have this issue.

[javagl]

As mentioned above: The restriction is built-in for OpenGL ES 2.0. There, the largest supported type for indices is GL_UNSIGNED_SHORT, capable of representing indices up to 65k.

(From a quick Websearch, ARKit seems to use "Metal", some sort of replacement for OpenGL, but that was just a result of dumb googling. Most likely, it does not have this limitation. (I never understood why OpenGL had this in the first place, but however))

There are three workarounds that I could imagine:

• Split the OBJ. I'm still working on support for this in the Obj library, but have some time constraints - and it may be a bit fiddly to get it right, considering the "groups" and "material groups" in OBJ...
• Use this extension: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_element_index_uint.txt This is a bit brittle, because you never know for sure which target platforms support it
• Upgrade the ARCore library to target OpenGL ES 3.0. According to https://developer.android.com/guide/topics/graphics/opengl.html , this should be supported by Android 4.3 (API level 18) and higher, and thus, should be rather safe nowadays. (I'm not sure how this works, though - in the best case, it might only be necessary to change some version number in some dependency description, but I didn't yet dive deeper into Android Studio etc)

[javagl]

The OBJ library has been updated. The release is not available yet. I'll put it on Maven Central soon, and by the way, also compiled it to use Java 7, so that the repackaging (that had obviously been done for this demo) should no longer be necessary.

It now offers functions for splitting large OBJs into smaller parts, and some convenience functions for obtaining the "material groups", which simplifies the process of rendering an OBJ that refers to MTL files with different texture definitions.

The comment at https://github.com/javagl/Obj/issues/4#issuecomment-356424533 contains a very basic sketch of a ComplexObjectRenderer class, which uses (slightly modified) ObjectRenderer instances as their delegates in order to render the individual parts.

I don't have an AR-capable device, so I cannot test it in context and cannot sensibly create a PR, but wanted to drop a note here just in case anyone is interested.

[inio]

Thanks for the update!

[javagl]

The updated JAR is at https://oss.sonatype.org/content/repositories/releases/de/javagl/obj/0.3.0/obj-0.3.0.jar

It is compiled with Java 7, so it should be easier to integrate it in Android, although I'm not deeply familiar with the version constraints here...