* 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
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.
Philip Rideout
Romain GuyandPhilip Rideout
Ben Doherty
Adrian PerezandMathias Agopian
Mathias Agopian
ritwik
cjsliuj
dsternfeld7