At least some adreno compilers don't like returning an element of a
UBO array that is a structure in the vertex shader.
To work this around we have to copy the each of the structure fields.
Fixes#6355
Vulkan and Metal should be handled exactly the same within filament,
when it comes to texture-space and clip-space because filament
always transforms vulkan's clip-space to gl's/metal's).
Our shadow code took different paths, both equivalent though, but it's
confusing.
The race coud lead to user after free and crashes.
We now keep a list of acquired streams with pending images on the
main thread, and use that to update the streams synchronously in
beginFrame. We can then enqueue a command for the driver thread that
will look for that stream in the active list of textures with stream
attached. Race avoided.
The previous code used the later list from both threads.
When more than one view was used, only the first view was cleared with
the ClearOption. This was actually intended when the views are rendering
into the swapchain (e.g. post process disabled), but that's incorrect
when the views render into intermediate buffers.
The clear flags are now associated with the actual rendertarget.
* Add new outputColorSpace() API to ColorGrading
This allows the application to select the desired output color space.
The default is set to Rec709-sRGB-D65 ("sRGB") but can be changed to
Rec709-Linear-D65.
Currently only the transfer function is taken into account and must
be either sRGB or Linear. Future updates will add support for
different gamuts and white points.
* Update release notes
WebGL complained about:
Precisions of uniform block 'ShadowUniforms' member
'ShadowUniforms.shadows.texelSizeAtOneMeter' differ between VERTEX and
FRAGMENT shaders.
this field didn't have a precision qualifier, this might be specific to
WebGL or a Chrome bug, unsure. Either we fix it by specifying all
qualifiers.
Since cmake 3.25 LINUX is automatically set based on CMAKE_SYSTEM_NAME,
which the android cmake files are setting to "Linux". This created an
inconsistant state in our build system.
Use a much more precise way to calculate the directional shadow frustum.
With very large scenes, we were losing the precision on the direction
of the light, and in some case even producing NaN in the matrix.
This partially addresses #6293
All shadow maps need a 1-px border for different reasons.
The directional shadow needs a "not in shadow" border because it uses
the intersection of receivers and casters in light-space.
Other shadow types need a border because of bilinear access at the
edges. Until now, the spot/point shadow border was handled with the
sampler's CLAMP.
Instead, now, we always generate a border and in one case we fill it
with "not in shadow" (by not rendering into it), in the other cases we
render the 2px larger shadowmap so we get completely correct bilinear
filter.
Additionally, for PCF, DPCF and PCSS we use a large filter kernel which
accesses data outside the texture, until now this was handled with CLAMP,
but that failed (2 of the edges were not handled in the same way) when
the shadowmap was smaller than the texture.
We fix this by clamping manually the texture coordinates.
The real motivation for these changes is to allow the use of a
shadow Atlas later.
When width/height is converted to GLSizei, which is signed, it can
become negative, which happened with a "full" viewport.
On some GL implementation, this resulted in a failure.
