This moves all Vulkan entry points into the bluevk namespace
to avoid conflicts with other Vulkan loaders.
This also updates the header files and loader code to version 1.2.159 of
the Vulkan spec, which is currently available at the following links.
https://khronos.org/registry/vulkan/specs/1.2/html/vkspec.html87451c55aa
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.
Release builds do not call cgltf_validate() so it was possible to
read out-of-bounds animation data when encountering a badly formed glTF
file with mismatched counts between sampler inputs and outputs.
This prepares for #3137 by moving the mesh cache and material instance
cache out of the loader (where they were transient anyway) and into the
actual asset. This paves the way for a `createInstance()` API.
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.
This change fixes an issue where ImGuiHelper would crash on destruction if you created more than one instance at the same time.
This crash occurred when ImGui::DestroyContext() was called, because when the second instance was destroyed there was no current context causing it to crash.
This fixes it by making ImGuiHelper store and manage it's own context.
Having two instances of ImGuiHelper is useful in cases where you want to use imgui with multiple views.
This adds a Dockerfile and a new bash script that makes it
east to invoke the appopriate Docker commands.
This does not yet enable a GitHub Action because of intermittent
issues that we have not yet ironed out.
This allows clients to build the Vulkan backend with either XLIB or XCB
support. I did a quick smoke test of the XCB option, but for now we are
continuing to default to XLIB. Note that the native window type used to
create the swap chain differs between these two API's.
The non-const getSkybox() method is especially useful to client code
that needs to change the clear color, but does not have direct
access to the Renderer object.
If hardware_concurrency() returned 2 while UTILS_HAS_HYPER_THREADING was
enabled, `mThreadCount` was resulting in zero, so jobs (such as texture
decoding) would simply never start. This problem was noticed with
GitHub Actions.
I tested this fix locally by replacing `hardware_concurrency()` with
fixed values like 1 or 2, and verified that the hang went away.
The Filament View that gets passed to tick() is retained briefly when
screenshots are enabled, but it may be destroyed by the time the
PixelBufferDescriptor callback is invoked. So, we needed a way of
notifying the AutomationEngine.
This adds a `material` key to `Settings`, as a sister to `view`.
Here's an example of an automation spec that manipulates material
parameters:
[{
"name": "metallic_vs_roughness",
"permute": {
"material.scalar.roughnessFactor": [0.0, 0.5, 1.0],
"material.scalar.metallicFactor": [0.0, 1.0]
}
}]
Currently this is limited to float, vec3, and vec4 parameters.
This adds `AutomationEngine` to libs/viewer, which iterates through
`Settings` instances that were generated from a JSON spec and applies
them to a Filament `View`. It can be configured to sleep between tests
using a time delay or a frame count.
This also adds command line arguments and user-interface elements to
`gltf_viewer` for automated testing.
This lets us generate long lists of settings permutations by writing a
simple JSON spec. For example, the following spec would generate six
`Settings` objects, all of which have SSAO enabled. See the unit test
for a larger example.
```
{
"name": "viewopts",
"base": { "view.ssao.enabled": true }
"permute": {
"view.dithering": ["NONE", "TEMPORAL"],
"view.sampleCount": [1, 4, 8]
}
}
```
