This adds some significant JNI glue in order to make the Java API for
gltfio materials much more consistent with C++, and create feature
parity between the two languages.
The motivation is to allow Java clients to provide their own
ubershader-based solution or filamat-based solution.
- The `MaterialProvider` Java class is now an interface.
- The `UbershaderLoader` Java class is now a concrete implementation.
- Users can now write their own provider class using Java / Kotlin.
To streamline the amount of JNI work that occurs at run time, the
MaterialProvider Java interface uses ints in a couple spots instead
of enums. This sacrafices some readability for Java clients who wish
to write their own provider, but makes the JNI much simpler.
This replaces #3975.
This allows clients to obtain the extras strings for the asset and
for individual nodes. Note that extras for buffer views, accessors, etc
are not supported, although C++ clients can access the raw cgltf data
directly if they need to.
Tested in Android Studio by starting sample-gltf-viewer and typing the
following into the debugger:
modelViewer.asset!!.getFirstEntityByName("Drone_Body")
modelViewer.asset!!.getEntitiesByName("Drone_Body")
modelViewer.asset!!.getEntitiesByPrefix("Drone")
glTF assets are required to provide min/max attributes for POSITION,
so in theory we never need to compute the AABB. However the option is
still there.
This PR also makes it so that Java clients can choose this option,
previously it was hardcoded for all non-native clients.
Tested locally by hacking gltf-viewer on Android, added the following
lines to MainActivity:
```kotlin
for (mat in modelViewer.asset!!.materialInstances) {
Log.d("gltf-viewer", mat.name)
}
```
Static JNI lookups were causing issues with multiple libraries.
We now do the lookups when we need them as they are effectively
just hashmap lookups and we do them only in places where the
work we need to perform will be much larger than a simple hash
map lookup anyway.
This chane also manually registers filament-utils JNI bindings
to get rid of unnecessary symboles. We should do the same for
other Filament libraries (the symbols are pretty long and
we now have many of them).
For Android and wasm we do not use the filesystem and therefore do not
need `utils::Path`.
```
libgltfio-jni.so BEFORE 1.9 MB (693 KB gzipped)
libgltfio-jni.so AFTER 1.4 MB (542 KB gzipped)
```
This feature adds one new method to `FilamentAsset` and uses it in our
Kotlin, JavaScript, and C++ helpers:
utils::Entity popRenderable() noexcept;
This pops a ready renderable off an internal queue, or returns 0 if no
renderables have become ready. It provides a simple way for clients to
gradually add renderables to the scene as they become ready. Previously
clients could only get the entire list of entities, regardless of
whether they had Renderable components or complete textures.
To facilitate this feature, this PR adds a new internal-only class to
gltfio called `DependencyGraph`, which is a temporary object used for
bookkeeping during the asynchronous load.
`DependencyGraph` discovers ready-to-render entities by tracking the
textures that each entity depends on. This is a graph because
renderables connect to a set of material instances, which in turn
connect to a set of parameter names, which in turn connect to a set of
texture objects. These relationships are not easily inspectable using
the Filament API or ECS.
We were already using jobs for decoding PNG and JPEG files, but we were
doing a join. This add three methods to ResourceLoader that allow
clients to amortize the decoding process across multiple frames, even on
single-threaded platforms like WebGL.
This PR adds async loading to the following demos:
- samples/gltf_viewer (now shows a progress bar in the UI)
- android/sample-gltf-viewer
- web/samples/helmet.html
Fixes#1876.
Add bindings for releaseSourceAsset() and fix a double-free issue.
According to the Android Studio profiler, this makes Java memory usage
go from 18.6 MB to 6.5 MB.
We currently use static linking and will continue to do so. This means
that libfilament-jni is a subset of of libgltfio-jni, and libgltfio-jni
will become a subset of the upcoming libutils-jni.
This is a simple layer cake, but requires adding some CMake logic to the
gltfio-android CMakeLists, similar to what we already did for the
filament-android CMakeLists. This prevents an obscure CMake error about
duplicated build artifacts.
Also, previously we required clients to call AssetLoader#init(), this
is now renamed to Gltfio#init(), which is more consistent with
Filament#init().
For now this uses gltfio in the ubershader configuration in order
to avoid the filamat dependency. Note that we have not yet done a size
analysis of the `gltfio_core` library.
New Kotlin-based sample app is forthcoming.
