Building tools separately is necessary for the existing
cross-complation usecase. We generalize this by introducing
two cmake vars that enable exporting and importing
prebuilt tools.
The intended usecase is to enable ASAN-built filament without
having to run ASAN-built matc (which is prohibitively slow).
build.sh has been modified to add a `-y` flag forprebuilding
tools.
on mobile h/w, strong highlights generated by the lighting stages can
turn into +inf and eventually to NaN if more math is performed on them.
Some h/w will kill a while tile or even primitive when that happens,
resulting in strong visual artifacts.
We fix this by clamping to MEDIUMP_FLT_MAX.
The reason for this is that according to the GLES 3.0 spec, RG32UI is
guaranteed to be supported for writing, unlike RG32F.
We also use RGBA_INTEGER / UINT for readPixels() which is also a
guaranteed format.
Attempt to Fix#8762
This new method, intended for the vertex shader, returns a matrix that
transforms vertices from view space (also known as head space) to the
current eye space.
BUGS=[441127971]
Before this change once the froxel vizualizaition was enabled via
the Engine debug framework, it applied to all views. This adds a
debug API on View to control whether the view will display this
vizualization.
If screen-space refraction was used enabled but the thickness
parameter wasn't explicitly set in the material, it would end-up
being uninitialized. Now it's initialized to 0.5 by default,
which is the value used for subsurface.
Also removed some calculations dependent on thickness being set, as
they assumed a thickness of 0.
it would automatically degrade to the 2-parameters version in
LOW_QUALITY mode, but some other code relied on the proper calculation,
in particular when specularFactor was used.
FIXES=[436866605]
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>
Now the helper function `getEyeIndex` becomes available for all shader
stages including post-processing. It used to be only accessible from
surface vertex shaders.
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.
When tangents are not supplied in a material, all "normals" related
public methods become undefined; remove access to them so we get
compile time errors instead of garbage values in the shader.
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]
The current API allowed to have a buffer for each primitive in a
renderable. We instead restrict the API so that there is a single
MorphTargetBuffer for the whole renderable, shared by all primitives.
The buffer can be shared thanks to the "offset" parameter on
setMorphTargetBufferAt().
Also
- fix FMorphTargetBuffer::updateDataAt()
- add support for the "offset" parameter of setMorphTargetBufferAt()
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.
it was incorrectly mapping the equirect image to a cubemap due to a
typo in our overload of atan2 which was swapping its parameters.
atan2 is now removed, and we use atan(y,x) instead. Also modified the
code slightly so it matches almost exactly cmgen's.
FIXES=[320856413]
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.
* 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>
Instead of a hard cutoff, we fade shadows out at
the shadowFar distance if active, fading occurs
over about 10% of the shadowFar distance.
- this works only for the directional shadow
(other lights don't use shadowFar).
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.
