* gltfio: Add internal MorphHelper, enable up to 255 targets.
Previously, gltfio could not animate models with more than 4 morph
targets. Now we can handle up to 255 targets, as long as no more than
4 targets are ever used simultaneously. This allows us to handle
many more models, such as those exported by Modo, and the horse model
in #1852.
We do this by picking the highest 4 weights. The indices for these
weights are called the "primary indices", and we construct a new
VertexBuffer for each unique set of primary indices.
In the near future this will be made more efficient by adding a new
VertexBuffer API to the Filament core.
Fixes#1487.
* Code review fixups.
Note that this API is on the loader rather than the asset. This is
because the loader knows how to create Filament entities by traversing
a cgltf node hierarchy.
Animation on dynamically added instances is not yet supported.
We did not add destroyInstance() because gltfio favors flat arrays for
long term storage of entity lists and instance lists, which would be
slow to shift. We also wish to discourage create/destroy churn since it
is more efficient to pre-allocate instances and selectively add them
into the scene.
Fixes#3137.
This introduces the `viewer::Settings` struct, and a JSON reader /
writer.
This will be used for automated testing and for client / server
communication.
Note that `viewer::Settings` is closely associated with the
`filament::View` API; when updating the latter we will often need to
update the former, as well as some serialization code. This increases
the maintenance burden and I think we should consider using a parser
library like libclang or a macro-based reflection utility.
This PR also migrates SimpleViewer into libs/viewer and un-inlines its
implementation. It does not belong in gltfio because it has an imgui
dependency.
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.
This removes (rather than deprecates) all public constructors that
take a native pointer without an accompanying Engine.
Most notably, MaterialInstance had a public pointer constructor which
is now package private. This means that FilamentAsset needs an Engine,
so it now takes the one from AssetLoader.
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).
This needs a bit more testing before merging, but I wanted to put up the
PR for review. I will look into supporting Android after we land this.
Fixes#1932.
This is 466 KB insted of the usual 850 KB. It assumes that users do not
need spec-gloss, non-lit, or a special transparency mode.
(uncompressed SO size on arm64)
We can add a new maven project for this next week.
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.
In my first attempt I kept the multiple project-level dependencies in
each sample's `build.gradle` but that resulted in a gradle error
concerning multiple copies of the same SO file. To work around this
we now append to "srcDirs" to bring in Java dependencies rather than
using project-level dependencies.
The new APK contents are now much more reasonably sized:
libfilament-jni.so 981 KB
libgltfio-jni.so 817 KB
libfilament-utils-jni.so 96 KB
Previously this was:
libfilament-utils-jni.so 1.8 MB
libgltfio-jni.so 1.8 MB (unused)
libfilament-jni.so 1 MB (unused)
Fixes#2070
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().
* Rewrite Maven publish tasks to support multiple flavors
* Don't build filamat with an unused CMake option
* Don't compiler debug in release mode
* ... for real
* Link to BUILDING.md
Romain Guy
Philip Rideout
Pixelflinger
Ben Doherty
Alexey Pelykh