I noticed that our slerp function sometimes produces a jolt in
animation, but only when the time delta is very small, and only when the
two operands have completely opposing signs.
For example, let's say you are slerping from <0.76, 0.39, 0.51, 0.19>
to <-0.72, -0.45, -0.49, -0.17>.
These quats are actually quite near to each other because the total
negation of the second quat is similar to the first quat.
We were already doing the short path check in the proper slerp path, but
not when falling back to lerp due to a small angle.
MaterialGenerator selects a custom blend mode for transmissive models,
therefore the AssetLoader should look at the material's blend mode when
it sets up properties, not the one requested by the glTF file.
Fixes#3444.
* 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>
Recall that we now use shared_ptr to simplify lifetime management of
cgltf source data (#3413).
Before this commit, we were only using shared_ptr to retain the source
data during buffer uploads. After this commit, we are using it to retain
source data during texture decoding.
Fixes#3428.
* Add swap() methods to Allocator.h
This allows StructureOfArraysBase's move constructor to compile.
Removed an apparent workaround in SingleInstanceComponentManager.
* swap can be noexcept
* Add swap() methods to Allocator.h
This allows StructureOfArraysBase's move constructor to compile.
Co-authored-by: Mathias Agopian <pixelflinger@gmail.com>
I tested this by viewing CesiumMan with our `gltf_instances` sample app.
There is now a need for some general refactoring in gltfio. I feel that
the high-level objects have become too tightly coupled to each other.
Fixes#3137.
- add darwin-aarch64 support to bluegl
- remove all aarch64 conditions in our cmakefiles, the architecture
is better handled in the source files (to allow fat binaries later)
The gltfio API allows users to destroy ResourceLoader or FilamentAsset
even when various asynchronous work (e.g. uploading buffers to the GPU)
has not yet been completed. This was achieved in an error-prone manner
using manual reference counting and an internal management object called
AssetPool.
This PR refactors gltfio by wrapping cgltf_data in shared_ptr, which I
usually try to avoid. However in this case it provides the precisely the
functionality that is needed.
I tested this PR for memory leaks and crashes by hacking gltf_viewer
and monitoring memory usage in Activity Monitor.
This fixes#3383 and makes it easier to implement some missing features,
such as animation support for instanced assets.
Bad texture files would cause the background decoder thread to never
finish and would generate textures with 0x0 dimensions, which eventually
triggers GL_INVALID_VALUE.
To recap, gltfio texture loading has two phases: the first phase is
synchronous and uses stbi_info to gather texture info. The second phase
is asynchronous and uses stbi_load to do the actual decoding.
During the first phase, we now check the return code from stbi_info
rather than assuming that it worked. :)
Fixes#3344
* Add support for sheenColor and sheenRoughness
This work is necessary to support the glTF extension KHR_materials_sheen.
This change effectively adds the specular lobe from the cloth material
model to the base material model. The cloth model remains useful for
its extra subsurface color feature but also because it's cheaper.
* Add support for KHR_materials_sheen to gltfio
* Update documentation
* Document default shading values
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.
