jgltf-model not portable to Android

[WizzerWorks]

The jgltf-model implementation uses JDK 1.8 language constructs that are not portable to Android yet. It would be nice if this was a cross-platform implementation.

[javagl]

Thanks for this hint. I didn't have Android on the screen for this yet, but it certainly is an interesting option, and I'd like to make the JglTF libraries available for Android if this is possible with reasonable effort and changes.

Simply setting the source compatibilty to Java 1.7 in Eclipse produces the expected set of errors:

• Many missing finals from the "effectively final" concept in Java 8: Trivial to fix
• Several uses of lambdas and method references: Simple to fix, although a bit ugly
• Few uses of Optional: May be trivial or hard to fix. I'll have to review where these might affect the interface

However, from the list at https://developer.android.com/guide/platform/j8-jack.html it looks like, for example, lambdas and method handles are supposed to be supported. Is there any easy way to figure out what exactly would have to be changed for Android compatibility?

I'll give it a try in Android Studio, but haven't used this extensively, so don't hold your breath...

[javagl]

So, I've had a look at this, and after several hours of downloads etc., it seems that at least the latest versions ("API level 24") seem to be able to understand and compile all the Java 8 language constructs, as well as the classes and interfaces from java.util.functional.

@WizzerWorks Can you confirm this?

However, there are still some classes and methods that are not contained in the Android SDK. From the first bunch of error messages, these are

• Byte.toUnsignedInt, Short.toUnsignedInt and Integer.toUnsignedLong - trivial to replace
• java.nio.file.Paths - a bit of fiddling around, but still easy to replace
• java.util.Base64 - this is a bit unfortunate. At least, there is a android.util.Base64
• java.awt.image.BufferedImage and javax.imageio.ImageIO and other image-related classes.

The latter are probably the most "difficult" to replace, as BufferedImage is currently used in interfaces.

There may be different options for solving this (in fact, I have pulled an "ImageData" class out of another library also for making it Android compatible). In doubt, I might have to create two different versions of the jgltf-model package, or one with two add-ons, like jgltf-model-desktop and jgltf-model-android, with some refactoring of the current one.

Any ideas or general recommendations here?

[ghost]

Maybe you can use JOGL AWT-free image API to load JPEG and PNG, look at com.jogamp.opengl.util.texture.TextureIO.

[javagl]

A first ("pragmatic") step was to define a simple interface https://github.com/javagl/JglTF/blob/master/jgltf-viewer/src/main/java/de/javagl/jgltf/viewer/PixelData.java#L31 that represents the pixel data that may either be obtained from a BufferedImage or from "any" other image class. To actually use it (and create a jgltf-viewer-android is till on my TODO list, though...

[azmuar]

Quick note, I have ported main parts of jglTF to Android, the way to go is to create jgltf-viewer-gles (GlContexGles and GlViewerGles) which operate with native android.opengl.GLES20.* methods (very very similar to OpenGL), then image buffer can be replaced with native Android Bitmap class and lastly all that need to be integrated trough GLSurfaceView.Renderer where all magic happens!
So no AWT, no JOGL, no JLWGL required on Android, just native functions which can fit in few MB APP.

[javagl]

Thanks @azmuar for the heads-up. I hoped that most parts of JglTF should now be portable to Android. I even started some basic tests a year ago, but still had been far from an actual viewer implementation.

Did you encounter any further issues, or necessary changes to the jgltf-model-classes?

Maybe we could collaborate in offering the results as a jgltf-viewer-android project, ideally together with some build/project files. I think that many people could be interested in having an Android-based viewer for glTF!

[ghost]

@azmuar By the way, JOGL works on Android.

[azmuar]

Hi @javagl, tnx for reply. In general I made lot of changes around the code to get JglTF working on Android and current code is in some working stage but not yet perfect, still need to fix several issues.

I'm interested to collaborate and help on jgltf-viewer-android project as already have Android Studio files so we can combine all that into one source and add those missing parts which are required for Android.

Currently have some major issue with Alpha Blending support, probably caused by refactored Bitmap/ImageBuffer related code but that is something I'm working on and hope I will fix that soon.

@gouessej tnx also for info. I have some problems installing JOGL so I decide to go without it and try to integrate JglTF natively if possible and luckily it's possible.

[LionisIAm]

@azmuar Can you provide your branch? Its gonna be easier if somebody has already started to implement and others will help.

[javagl]

@azmuar Indeed, it would be great to have an overview of the changes that have been required for Android.

For example, after this issue was opened originally, I created the https://github.com/javagl/JglTF/blob/master/jgltf-viewer/src/main/java/de/javagl/jgltf/viewer/PixelData.java#L31 class as a possible abstraction layer, to get rid of the BufferedImage dependency on android. I assume that there will have to be a jgltf-desktop library/project that contains all the stuff that is not portable to Android (and maybe a jgltf-android library - although the contents of this library could probably be part of the jgltf-viewer-android library for now).

I'm asking because I'm currently working (on a branch, locally) that aims at creating glTF models programmatically (basically a jgltf-model-builder project). Similar questions come up there, and I've already started refactoring around the PixelData class.

I'd like to avoid "diverging" too far from the state that you created for Android - otherwise, merging the two states may be a hassle.

In doubt, you can just drop your modified sources as a ZIP file somewhere, even if it is not yet final or still has issues. Then I'd try to allocate some time to sort it out, maybe create the dedicated jgltf-viewer-android project (with attributions going to you, of course!).

[azmuar]

@javagl Please understand me, currently code have "700" permission, I still waiting on "777" from my PM and I hope will get it soon, It's not up to me.
I'm developer as you and understand how much some working code can help.
I will help actively as soon as I get 777.

[mikikg]

@javagl Hi Marko, here is the source code for the Android APK with a ported jglTF library.
Please check that and propose future steps to integrate those changes into a single source tree.
https://github.com/mikikg/AndroidJgltfViewer

[javagl]

Thanks for the pointer @mikikg ! I'm rather short on time right now, but will try to allocate some time to have a closer look at this during the coming week!

[javagl]

Android support is a question that comes up occasionally. I'm not entirely up to date here, but it seems like the capabilities of Android are "overtaking" JglTF. I'll close this issue (because it's outdated). If there are more specific changes that are required for Android support, this can be tracked separately. I opened #117 to keep track of this.