Instead of passing the level and layer explicitly to gaussianBlurPass,
we rely on the information already contained in the handle. i.e. we
honor the "subresource" part of the handle (if it has one).
In other words, it's now possible to pass a subresource (e.g. a layer)
to generateGaussianMipmap or gaussianBlurPass and things should work as
expected.
The problem here would happen when forwarding a subresource (i.e.
replacing an existing resource by a subresource) and the existing
resource had been written to. In this situation, the subresource's
parent needs to depend on the subresource (i.e. as if it was written to
by it). This would normally happen during write() but in this situation,
the write had already happened.
the dependency graph would be incorrectly severed in the situation where
a subresource was written to and later its parent was read from.
In this situation, the parent node is in fact a new version of the
original parent node, so we need a "read" dependency of the orginal to
the copy (otherwise the orginal node is not a dependent of anyone
and gets culled).
Some clients need to link against both Filament and OpenGL. This can lead to symbol clashes under certain circumstances. As a fix, prefix all of our `bluegl` symbols with `bluegl_`. Previously we made this naming change for Windows, but now we'll do it on all platforms for simplicity.
The existing behavior was surprising for users who draw opaque objects
into a semitransparent views, and this was especially evident with
the labels in `TextureLinearInterpolationTest`.
We now disable blending for MASKED, which is what our existing materials
documentation already says. We also now set the fragment alpha to 1 when
the fragment is not discarded, which prevents the "punch through"
effect. This is consistent with ThreeJS.
Fixes#4576.
We were decrementing activeJobCount after removing the job from the
queue, which could cause other threads in the pool to preempt us before
the decrement, causing them to spin forever trying to get a non-existant
job, until the decrement actually happened.
Now we always decrement first and fix-up the count if we couldn't get
a job from the queues. The race is inverted, and doesn't cause threads
to spin a long time.
fixes b/201100123
This removes some special handling of the default render target lifetime
that is no longer needed, and renames "surface" to "swapChain" where it
is appropriate to do so.
This is a gltfio API change (!)
Jave clients now need to call destroy on MaterialProvider.
Previously, the Java AssetLoader took over ownership of a native
material provider upon construction, but this was neither documented
nor consistent with the C++ layer. (This is historical; in the past we
did not expose MaterialProvider to Java.)
One motivation for this (aside from API consistency) is that users may
wish to preserve the material cache from one run to another.
Fixes#5132.
We now have a single varyings.glsl containing our varyings for both
the vertex and fragment shader. This file is included with the right
definition of VARYING as `in` or `out`.
inputs.vs is now renamed attributes.vs
This changes the WebGL and desktop glTF viewers so that they always
call `updateBoneMatrices`, even when there are 0 animations. Note
that our Android sample was already doing this correctly.
When combined with #5301, this fixes#5299, although users would need to
use the `recomputeBoundingBoxes` feature in gltfio (`-r` in the desktop
viewer) for this model to be scaled to fill the viewport, since its
embedded bounds are quite large.
In the past there was an API gotcha because users had to "get" the
animator before releasing the glTF source data. This could have been
surprising because it was a getter method, not a factory method.
This was due to overeager optimization on my part, I wanted to avoid
animator overhead for non-animated models, when in fact it has very
little overhead.
Moreover, the animator is conceivably useful even when there are no
pre-supplied animations (e.g. for applying skins), so let's just create
it unconditionally.
Motivated by #5299.
Two changes:
1) Khronos has moved from "master" to "main".
2) BlueVK was attempting to generate reasonable "operator<<" support for
bit flags but this was buggy due to type aliases. Since we weren't using
it anyway, I simply removed this functionality from BlueVK.
Instead of having 2 fields we're following the vulkan convention of
having only the layer field.
The layer/face convention is still maintained in the public APIs.
fixes#5273
Dragging a zip file into the Remote Viewer page would fail if it
contained a glTF with `./` prefixes in the `images` section. The best
fix is to use Java's proper URI object rather than trying to parse the
string.
The JSON response to /api/active became malformed after #4465 because
raw hex strings need to be enclosed by quotes.
This commit changes the variant format in the /api/materials response
to be consistent with one used for /api/active. By using integers
instead of strings, we're avoiding the need to parse integers at run
time.
The JSON error did not appear in the Chrome console because it was being
silenced as a hack to appease "matinfo --web-server". I fix this by
removing the hack and simply emitting a valid response when there's
no live backend.
Also fixed the display of materials, which were always being marked
as active even when they had no active variants.
We held a reference to a cache item after potentially clearing it due to
pool growth. I was able to trigger an error only after enabling ASAN and
loading a large model. Many thanks to @jeanlemotan for catching this.
