This caused a unit test failure because a StaticString constructed
from "make" had a different hash than one constructed from a literal,
even though the two strings were lexigraphically equivalent.
Having MorphTargetBuffer in FRenderPrimitive is a concept of glTF. Filament doesn't have to follow this concept. Actually the responsibility of FRenderPrimitive is to define vertex input stream because FRenderPrimitive maps to HwRenderPrimitive in Filament. If we store MorphTargetBuffer into FRenderPrimitive then it exceeds the responsibility of FRenderPrimitive. Because MorphTargetBuffer doesn't have any information on how to set up vertex input stream. So handling morphing like skinning will be better.
We were not unrolling the == loop because the generated code with
unrolling was very branchy; but that's not a good call either because
the loop has the same number of unpredicted branches.
Theoretically the compiler should be able to emit a branchless == but
it doesn't. At least we give it a chance.
When we introduced texture-based morphing, our custom depth resolver
needed to be updated to set up samplers correctly. This fixes a
validation error about shader stage access.
Every sidecar texture should have the same dimensions as its parent
texture.
Prior to this change, the sidecar texture would have the dimensions of
the RenderTarget wrapper rather than the parent texture. This was wrong
because the RenderTarget might be slightly smaller than the texture.
This caused an issue when the same texture was attached to two render
targets with different sizes, because there's only 1 cached sidecar per
texture.
We were passing the wrong texture object to VulkanDisposer::acquire().
MSAA depth sidecar textures are not managed by VulkanDisposer, but their
parent textures are.
Fixes#5217.
When we overhauled image layout transitions, we moved as many
transitions as possible into the render pass. However the transition
that we perform for "depth read only" layout needs to be applied to
multiple miplevels, so we cannot use the render pass for that.
We now handle "too many bone weights" in the same way that we handle
"too many UV sets". i.e. emit an error message and do not panic.
This change allows us to render the model in #5234 quite reasonably.
Fixes#5234.
This fixes the emscripten binding errors that we've been seeing
with the <filament-viewer> test page, which prevented us from
including web in the last few Filament releases.
The binding errors were caused by double-initializing the emscripten
module.
I fixed this by allowing clients (e.g. FilamentViewer) to call
Filament.init() more than once. We now accumulate a list of "on ready"
callbacks that get triggered after the emscripten module becomes ready.
As far as I can tell, multiple canvases were actually always broken, and
the viewer test page worked in the past only because we got lucky.
Previously, the Vulkan backend made an educated guess about the depth
write state during the start of the render pass. The logic for this
did not make any sense, so now we're replacing it with an explicit
hint that PostProcessManager sets up. In a sense this gives backends
a sneak peek into the raster state.
Philip Rideout
daemyung jang
Mathias Agopian
Benjamin Doherty
chubei-oppen
chubei-oppen