This adds a WebSockets server to filament-utils-android.
Unlike my first attempt (#3599), this does not use a piping server and
is therefore much faster to use over a LAN. It also has lower user
friction because there is no need to touch a button in the app or
scan a QR code.
This adds libs/viewer to filament-utils-android and provides JNI
bindings for AutomationEngine.
This commit also changes the AutomationEngine to use PPM for screenshots
rather than PNG. The reasoning is that it is wasteful to include stb and
our two image-related libraries just to dump screenshots, especially for
a feature we might not use on Android.
Mathias noticed that the `setAcquiredImage` method was not well
documented on the C++ side. While fixing this I figured I'd try to write
up a docstring for the class itself.
* Stop using members as globals between methods
* Multi-thread shaders generation with JobSystem
* Pass JobSystem to MaterialBuilder::build()
* Fix MeshAssimp to use the new API
* Allow the Java API to pass a job system via Engine
* Update docs
* Apply suggestions from code review
Co-authored-by: Philip Rideout <philiprideout@gmail.com>
We now export only two groups of symbols: (1) JNI and (2) dynamic linker
symbols used by the companion libraries.
This commit has the following impact:
- Shrinks the arm64 so from 1024 KiB to 954 KiB.
- Shrinks the arm64 aar from 560 KiB to 538 KiB.
Note that the patterns in the map file are tested against mangled names
and therefore should not be used to match the double-colon operator.
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.
You can now build Filament with support for both X11 APIs, or neither.
If both are supported, run-time selection is achieved using a SwapChain
flag.
Supporting only one API at build time (or neither) is useful because our
list of "required" VkInstance extensions can vary according to which
API's are supported. During VkInstance creation, we do not have a priori
knowledge about what kinds of swap chains will be created. (headless vs
non-headless, XCB vs XLIB, etc)
Note that some Vulkan implementation (e.g. some builds of SwiftShader)
only support XCB.
