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 fixes a slew of validation warnings and errors seen when multiple
subpasses are enabled, starting with:
Attachment 1 not written by fragment shader; undefined values will
be written to attachment
The Vulkan driver was using the same color attachment list for both
subpasses, so the first subpass had unused attachments.
Note that Vulkan makes a distinction between color attachments and input
attachments and requires separate lists to be supplied for each subpass,
but our Driver API consolidates everything into a single list. This
should perhaps be refactored at a later date.
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.
This makes it so that the PixelBufferDescriptor callback triggers at a
time consistent with other backends.
ReadPixels is still asynchronous in the sense that the callback is
triggered on the main thread. However, it is now guaranteed to trigger
during (or before) flushAndWait(), which is less surprising behavior.
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 avoids the following validation error when clients create then
immediately destroy vertex buffers, index buffers, and uniform buffers.
VUID-vkDestroyBuffer-buffer-00922
Cannot free VkBuffer that is in use by a command buffer.
Buffers that are used across multiple frames were fine, but
create-and-destroy scenarios were problematic.
This fixes a regression introduced by 548b28c6e manifesting as
intermittent assertions. The VulkanDisposer gc() should only be called
from the driver thread.
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 support for more format conversions and removes a bogus
assert that prevented ReadPixels within beginFrame / endFrame.
This was tested with:
backend_test_mac --api vulkan --gtest_filter=BackendTest.ReadPixels
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.
