Api level is now enforced when generating code by appending #defines of client requested and unstable apis.
This ensures that the client can only use unstable apis when they explicitly add `apiLevel` in their .mat file.
FIXES=468340631
This change adds support for the KHR_materials_dispersion glTF extension, which introduces a dispersion property for refractive materials.
The dispersion property controls the angular separation of colors transmitting through a refractive object, allowing for more realistic rendering of materials like glass and diamonds.
Changes include:
- Added a dispersion property to the material definition.
- Updated the shaders to incorporate the dispersion effect in the refraction calculations.
- Added a new test case for dispersion.
- Updated the material documentation to include the new dispersion property.
The record buffer is were we store the light indices, its maximum
size is 65536 entries, but is often limited to 16384 on about 30%
of Android devices because of the 16KB UBO limit.
This PR makes the record buffer use up to 64K entries when allowed
but the h/w.
The record buffer can be a limiting factor when many lights are used
with many froxels. With the minimum of 4096 froxels and a 16KB record
buffer we get an average of 4 lights per froxel. With our maximum of
8192 froxels and a 64KB record buffer we get 8 lights in average per
froxel.
The new `linearFog` material property, when set to `true` enables a
simplified fog calculation. The fog equation becomes linear which is
unrealistic, but more efficient to compute. In some situations with
a shallow fog range, it doesn't make a huge difference visually.
In this mode, height falloff and in-scattering are ignored.
The linear equation slope is calculated from the regular parameters to
match the slope of the real equation at a camera height. If
`heightFalloff` is disabled, set to 0, the `density` parameter
exactly corresponds to the slope of the equation in [1/m] units.
* Materials can now specify a shadow strength factor
Materials have a new property: shadowStrength that can be used to
attenuate all shadows received by this material. e.g.:
```
void material(inout MaterialInputs material) {
prepareMaterial(material);
material. shadowStrength = 0.1;
}
```
FIXES=[391663042]
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
Subpasses should not be used anyways due to the result of WebGPUDriver::isFrameBufferFetchSupported. However, we need to make sure the GLSL is not generated for WebGPU, or Tint is unable to convert.
The definition of the froxel buffer sizes were spread across
multiple places and for different use cases (including
allocating the buffer, setting to a descriptor set, and adjusting
the relevant spec constant). In this commit, we try to unify
the size definitions into Froxelizer::getFroxelBufferByteCount().
We also remove the vulkan-only special case for froxel buffer
UBO. This case was introduced because spec constant couldn't be
used to size arrays for some drivers in the past, but we introduced a
workaround that replaced spec constants with constants.
When targeting Vulkan with multiview, the shader
code generator was using the OpenGL extension
and built-in variables, which are not supported on
Vulkan.
Changed it to use GL_EXT_multiview instead of
GL_OVR_multiview2 when the target API is Vulkan.
This commit renames all shader snippet files to conform to the newly
introduced naming convention outlined in README.md.
The new naming convention uses a `prefix_name.suffix` format to clearly
indicate the purpose and target shader stage of each snippet. This
improves the overall organization and readability of the shader code,
making it easier to understand how each snippet contributes to the
shader generation process.
No functional changes were made to the shader code itself or source
code. This is purely a refactoring for clarity and maintainability.
The number of SH bands used for the indirect light irradiance
computations can be set to 1, 2 or 3 (default) in Material::Builder.
For e.g. in lower-end devices w/ non HDR content, it might be
beneficial to set this value to 2.
BUGS=[341971013]
- Add option to build.sh to build for paritcular stereo
techniques (default to NONE). Only applies to samples.
- Consoldiate viewer checkbox for debugging stereo rendering
- Add DriverConfig flag for stereoscopic type so that it can
be used to determine availability of the feature and
(to be completed) enable corresponding GPU features.
Co-authored-by: Mathias Agopian <mathias@google.com>
This adds a new material property (float postLightingMixFactor) which
is used to mix the original color with the post-lighting blended color.
The default value is 1.0, which keeps the current behavior.
FIXES=[328498606]
* Add a new material param, stereoscopicType
This new parameter allows us to specify which implementation of
stereoscopic rendering Filament uses for the material.
This change just includes material parameter addition and shader code
changes, so it doesn't affect the current rendering behavior.
These changes will follow as separate commits.
- render pipeline changes
- material parameter override via matc parameter
- material document update
We're going to add a new implementation of stereoscopic rendering using
multiview. Thus we want to remove the word `Instanced` from all methods
and properties.
The CL introducing the ESSL 1.0 chunk in materials inadvertently disabled
optimizations for said code. This commit reintroduces those optimizations and
fixes associated bugs which manifested. In particular, spirv-cross was
generating uints for bools; this has been fixed with a hack. Additionally,
spirv-cross is now compiled with exceptions enabled so that matc can gracefully
fail and show the code which failed to compile rather than abruptly aborting.
Since #7358 is blocked by an upstream spirv-cross issue, we can at least do a
bit of preprocessor optimization for ESSL 1.0 code in the meantime and introduce
the FILAMENT_EFFECTIVE_VERSION preprocessor definitions.
First, this commit introduces some very simple bugfixes regarding ES2
compatibility related to postprocessing.
Second, this commit adds support for creating textures specified as R8, SRGB8,
and SRGB8_A8 in ES2. R8 is trivial: just use GL_LUMINANCE instead. The sRGB
formats, however, are maybe a bit more controversial. As implemented, they
instead just use the equivalent non-sRGB formats. This is of course technically
incorrect. There are a few approaches to how to add sRGB compatibility for ES2
that I can think of.
1. Do a bunch of complex shader nonsense in matc. Maybe even traversing the AST
and ensuring any texture lookup of a texture flagged as sRGB uses some
compatibility function. This would require static analysis to track if samplers
are reassigned to another variable, for example. This of course also breaks down
if you don't know at compile time if the shader will receive an RGB or an sRGB
sampler, or if the shader should be able to support both RGB or sRGB samplers.
Really only worth mentioning here for the sake of completion.
2. You could also generate simple compatibility functions to look up each
sampler, which would only apply to FL0 materials.
First, we would have to extend the material format to be able to explicitly
"color" a sampler as sRGB or not, like:
```
parameters : [
{
type : sampler2d,
name : albedo,
precision : medium,
colorSpace : srgb,
},
{
type : sampler2d,
name : normal,
precision : medium,
colorSpace : linear,
}
],
```
Then, the following GLSL code would be generated.
```glsl
\#if __VERSION__ == 100
vec4 texture_albedo(vec2 position) {
return sRGBtoLinear(texture2D(materialParams_albedo, position));
}
vec4 texture_normal(vec2 position) {
return texture2D(materialParams_albedo, position);
}
\#else
vec4 texture_albedo(vec2 position) {
return texture(materialParams_albedo, position);
}
vec4 texture_normal(vec2 normal) {
return texture(materialParams_normal, position);
}
\#endif
```
Finally, at runtime, if a sampler is "colored" one way or the other, we would
verify that only the appropriate kinds of samplers are bound.
I'm actually very partial to this solution. Since sRGB compatibility is only a
concern on ES2, we can generate this code only for FL0 shaders, which already
require GLSL shader authors to care about ESSL 1.0 compatibility by calling the
appropriate `textureXX` functions. Additionally, it provides a layer of
high-level validation that texture lookups are correct, even if a real ES2
context is not available on the device being tested.
3. Leave it entirely up to the client. (What this commit does.) This leaves
client code ripe for making mistakes, but luckily, we can go back and do
solution 2 whenever. If specifying a color space for a sampler remains optional,
then if this feature is retrofitted in the future, client code will continue to
compile.
This change hard-codes writing the post process output at index 0 (i.e. color)
to gl_FragColor when generating ESSL 1.0 shaders. Any other outputs (besides
depth) are discarded with a warning, but as far as I can tell, no such cases yet
exist in Filament.
Fix edge case where an empty struct could be generated in an ESSL 1.0 shader.
Include _maskThreshold and _doubleSided in ESSL 1.0 shaders.
Add GL_OES_standard_derivatives extension to ESSL 1.0 shaders. According to
gpuinfo.org, this has 96% device coverage and supports both Mali-400 and Adreno
(TM) 304.
Remove 3D sampler support from ESSL 1.0 shaders. This extension is only
supported by 62% of devices.
Change filagui material to a FL0 material.
* debugging PCF mode
This mode always uses a hard PCF and takes a
slightly slower code path.
* dynamic shadowmap visualization
The directional shadowmap visualizer is implemented behind a
specialization constant. Add the DebugRegistry infrastructure to be
able to update the spec-constant at runtime and have a subset of
all materials invalidated.
This allows to toggle the visualization at runtime using a debug
property.
This is also a proof of concept that we can update spec-constants
at runtime; we could probably leverage this work for engine-wide
shader configurations.
* Update main.fs
* Update filament/src/details/Material.cpp
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
these materials would not generate proper structure or shadow buffer,
because they used a special variant that in most case removed the
user code.
now when the user code writes the depth or calls discard, the user
shader is kept.
Previously, when a material was expilicitly built for feature level 0, it was
necessary to write ESSL 1.0 code which was incompatible with the OpenGL feature
level 1 implementation in Filament. Rather than adjust the Filament
implementation so that feature level 1 uses the same workarounds as feature
level 0 to emulate GLES 3.0+ features, it's more runtime-efficient to have matc
embed ESSL 1.0 and 3.0 shaders as separate chunks and load the corresponding
one based on the active feature level.
Feature level 0 material shaders must still be written in what is effectively
ESSL 1.0. To assist with this, a small set of compatibility definitions are
introduced when building the ESSL 3.0 variant. These are virtually all
textureXXX() functions, and end up either optimized out or inlined by glslang.
One final effect of this change is that external and 3D samplers are now
properly supported in feature level 0 materials.
This PR sets up the ability for shaders to use `gl_ClipDistance`, which will be needed in the future. Desktop GL supports this natively. OpenGL ES requires the EXT_clip_cull_distance extension.
Unfortunately glslang does not support this extension, so we have to employ a workaround for mobile when going through glslang. We instead write to `filament_gl_ClipDistance`, and then modify the SPIR-V to decorate this as `gl_ClipDistance`. See the comment in SpirvFixup.h.
Note this PR does not actually use `gl_ClipDistance` yet, so there should be no change to shaders.
the math needs to be maintained in highp, including during the blur
pass.
we add the ability to specify a "precision" qualifier to the "output"
of a post-process material.
we also remove the mediump clamping we used to do on mobile, it shouldn't
be done automatically behind the scenes, it's up to the shaders to do
it if it makes sense.
* froxelizer doesn't use textures anymore
All data is stored in UBOs.
Additionally, the buffer size is no longer hardcoded at compile time.
This CL cuts in half the numbers of froxels to accommodate devices
limited to 16KiB,
* Use a specialization constant to adjust the size of froxel UBO
This really only affects OpenGL in practice because metal supports 256MB
minimum and only 3% of android devices support less than 32K, which is
what we need.
Powei Feng
yein
Nemi
Mathias Agopian
Juan Caldas
Andy Hovingh
Konrad Piascik
bridgewaterrobbie
Syed Idris Shah
Rafael Dominguez
Sungun Park
Eliza Velasquez