* 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 tool makes it easy to analyze the composition of Android
applications that use Filament.
- Filament materials are shown in the treemap if `resgen --json` was
used in the build.
- The input path can be a so file, folder, or zip archive (apk or aar).
- If the path is a zip or folder, helps you find the file to analyze.
- The generated web report is a self-contained HTML file.
- Reports the gzipped size of all Filament materials.
For example, from a mac, you can generate a self-contained HTML file by
typing this from the Filament repo root:
./tools/zbloat/zbloat.py ./android/filament-android
open index.html
This tool uses Python, `nm`, and `objdump`.
The `nm` tool works slightly differently between macOS and Linux, so a
`Dockerfile` is provided that installs dependencies inside a Linux
container. This is also convenient if you do not have both versions of
Python on your system.
The easy way to use docker is to invoke the helper bash script. Simply
type `zbloat.sh [args...]` instead of `zbloat.py [args...]`. The first
time you run it, it will be slow but subsequent times will be fast.
Many thanks to Evan Martin for his interactive treemap widget.
This option embeds a small JSON string inside the resgen blob that lists
all materials and their respective sizes. This is useful when analyzing
the footprint of the binary executable.
This fixes a bug Renderer clearing a render target multiple times when the first time and back again.
Usually the default RenderTarget is unintentionally cleared/discarded in the current behavior.
1) Renderer renders a view without custom RenderTarget having full-screen viewport,
2) Renderer renders a view with custom RenderTarget
3) And Renderer renders an another view without custom RenderTarget having different viewport from 1)
You may see junk or empty pixels in outside of the viewport of the view 3), depending on ClearOptions and the backend.
This fix make Renderer put cleared RenderTargets into a set and check them to be cleared only for the first time, instead of comparing the previous RenderTarget to the current RenderTarget.
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.
When passing only 1 fence to vkWaitForFences, the `waitAll` argument
should not have any effect, but SwiftShader seems to skip the wait
when this argument is set to VK_FALSE.
More specifically, the failure to wait in `acquireWorkCommandBuffer`
causes the subsequent destruction of an in-use fence, which causes
a TSAN failure with Google's internal tests.
I am consulting with the SwiftShader team on a real fix, meanwhile
we can commit this easy workaround.
We have 5 usages of vkWaitForFences, one of which uses multiple fences
and should have used VK_TRUE anyway.
This prevents a SwiftShader crash and/or a slew of "no texture bound"
warnings that would appear when the client provides an IBL without
providing reflections texture, which should be a valid thing to do.
Note that it is okay to declare a sampler in GLSL that never gets bound,
as long as it is never sampled from. Since we always sample from the
IBL specular texture, we should always bind something to it.
With Vulkan, this warning would sometimes be a false positive. It could
trigger for internal samplers like `ssao` and `structure`, even though
they were not declared in SPIR-V.
With OpenGL, this warning would never be a false positive because it has
the luxury of calling `glGetUniformLocation`.
This adds a private attribute to our samplers called `strict` that
indicates whether or not a sampler should always have a bound texture.
For now the only strict samplers are the custom ones declared in the
user's material.
At some point I think we should consider adding `spirv-reflect` to our
tree to help with problems like this.
This fixes a bug seen with client applications that use ClearOptions
instead of Skybox, and one or more offscreen RenderTarget objects.
These apps would see junk pixels because Filament would only clear the
first render target in the frame.
The fix is to factor some the flag-setting logic in `beginFrame()` into
a private method, and call this method from `render()` each time
the user-level RenderTarget has been changed.
I wrote a simple C++ demo to reproduce the issue and to verify that
this fix works.
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
Fence.cpp:
My previous fix to the fix was insufficient because a signed integer
overflow could still occur as follows (this was observed in an internal
test at Google).
If the conditional on line 87 is true, then a clamped value is passed
into `wait`, which causes the conditional on line 133 to fail, which
causes `wait_for` to be called inappropriately, which is where an
overflow would occur.
MetalHandles.mm:
This is more theoretical, but to prevent potential integer overflow
within STL, I think we should call `wait()` rather than `wait_for()`
when an infinite timeout is desired.
This is our fourth fix to fences in since November 2; see also dcca236,
e9c9e45, and 8969416. :)
FFence::wait() has some logic that tests if "timeout" is equal to
FENCE_WAIT_FOR_EVER, which is actually impossible because it would
be modified by the clamp in this situation.
In practice I think this oversight would not cause any problems. I
noticed it while reviewing the code.
To recap why the clamp exists: according to the ISO C++ spec, the
"nanoseconds" duration in chrono is at least a signed 64-bit type, but
our sentinel constant might not (and does not) fit within this range.
