Since we cannot upload a depth buffer, this test works by first drawing
a triangle into COLOR + DEPTH, copying them both to a new render target,
then drawing a slightly larger triangle just underneath the first one.
One of Filament's Linux clients at Google wishes to specify a special
path to the SwiftShader library that proffers Vulkan entry points, and
this path can only be determined at run time.
An environment variable seems like the easiest way to support this
functionality. To prevent a security hazard, the env var is checked only
if a special build-time flag is enabled.
According to the portability spec: "If this extension is supported by
the Vulkan implementation, the application must enable this extension."
On my 2019 MacBook, enabling this extension triggers errors relating to
depth comparison samplers which I believe to be bogus, so I filed a
LunarG bug. For now we silence this specific error message.
When running semantic analysis on a material, we were arbitrarily choosing the first code gen permutation to analyze. So, running matc with arguments --api metal versus --api all would run analysis on slightly different shader code. This causes bugs when flags passed to glslang differ during semantic analysis. This change updates all semantic analysis to always use the same shader code.
This fixes some OpenGL non-compliance (as per "Rendering Feedback
Loops" in the spec), as well as validation errors with Vulkan.
I'm hopeful this can be automatic in the new frame graph. :)
This prevents an "Invalid VkImageView Object" error that would occur
after disabling bloom.
This was caused by the fact that we do not bother zeroing out all the
descriptor slots that are not used by the current draw call.
This fixes `GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE` caused by the
following spec clause being violated:
```
The value of RENDERBUFFER_SAMPLES [must be] the same for all
attached renderbuffers and, if the attached images are a mix of
renderbuffers and textures, the value of RENDERBUFFER_SAMPLES
is zero.
```
Tested on Chrome with Triangle and Helmet demos (after enabling MSAA).
Also tried running the automation suite in a debug build on macOS.
Fixes#3128.
This adds setMinMaxLevels to the DriverAPI and calls it from
PostProcessManager and the new unit test. The allows us to be compliant
to the OpenGL specification. The new unit test now looks much better on
Intel GPUs. Chrome still gives an INVALID_OPERATION.
Unfortunately the actual bloom effect still has issues on my Intel GPU,
even though the test passes. So, we need to keep the ping-pong
implementation both for Chrome and for Intel.
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.
