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]
cmgen mirrors environment maps by default so that the reflection map
appears un-mirrored. IBLPrefilter didn't do that.
EquirectangularToCubemap now takes a Config parameter that allows to
specify the mirroring, which is enabled by default.
FIXES=[320856413]
* 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.
This reduces resource utilisation for Views that never need shadows.
It saves a UBO, two Entities and about 10KB memory. We also lazily
allocate the debugging DataSource, which saves about 10K per View
in debug builds.
Overall this change makes "simple" Views less than 4KB heavy down from
about 24KB (debug, 14KB release).
The main changes:
- ShadowMapManager is now allocated lazily
- the ShadowMap cache object is also allocated lazily
- debug DataSource is allocated lazily
- ShadowMaps are prepared/initialized with a Builder, which makes it
clearer that some APIs are only for preparing the ShadowMap cache.
- each handle now has a 4-bits "age", meaning that handles are recycled
only after 16 alloc/free cycles.
This is used to detect double-free and use-after free.
This should also allow us to compare handles, because freeing and
reallocating an object, won't produce the same Handle (at least
for 16 rounds).
- removed "type safety" checks because it's almost impossible to
get it wrong thanks to our compile time type safety checks. This
didn't provide a useful value added.
- This feature is built on top of being able to set/get a 8 bits tag
associated with the memory block returned by the pool allocator. We
use the "extra" parameter of the allocator to allocate a "hidden"
structure containing the age of that memory block.
- Also we don't allow to compare Handle<> of different types
- update the pools sizes for metal and vulkan, which were very outdated.
- add debug code on all backends to print the size of each handle
(with a compile time switch)
The most important change is that now the 3 pools of HandleAllocator
are sized so that each can accommodate about the same amount of handles.
This makes it easier to reason about. The total amount of handles is
three times that, since there are 3 pools.
We also try to allocate the buckets so that handles are evenly
distributed, however, that's very hand wavy.
With the current setup the number of handles per pool is as follows:
- GL : 3240 / pool / MiB
- VK : 1820 / pool / MiB
- MTL: 1310 / pool / MiB
* Automatically flush CommandStream
When generating commands, we now automatically flush the CommandStream,
so that we're guaranteed to not overrun the circular buffer.
* clenaup CircularBuffer implementation and API
Also fix a bug in DEBUG mode that could corrupt the CircularBuffer, it
was due to a wrong debugging code attempting to clear the unused
area of the buffer (this was wrong because in "ashmem" mode, there are
no guaranteed unused areas).
* Fix a couple threading vs. allocations
- prepareVisibleLights was run on a dedicated thread (via JobSystem),
but was using its own local ArenaScope. This is wrong because it
could reset the root arena at any later point. This is fixed by
just not using a local ArenaScope.
- related to the above, the root Arena (LinearAllocatorArena) didn't
use a locked policy, which cause also cause problems since some
allocations are done off the main thread. We now pre-allocate the one
buffer we need.
This PR also renames some variable and types to improve readability.
* Rework RenderPass to improve allocations and API
RenderPass now is a fully immutable object that gets constructed with a
RenderPassBuilder. RenderPassBuilder can be passed around and doesn't
do any (major) allocations.
All RenderPass allocations and heavy lifting is done in
RenderPassBuilder::Build().
Additionally, RenderPass cannot be copied anymore.
Where allocations happen is now much clearer.
* new LinearAllocatorWithFallback
LinearAllocatorWithFallback is a linear allocator that can fall back
to the heap allocator. We use it for the high level command buffer to
avoid crashing when running out of memory.
FIXES=[277115740]
* Update filament/src/RenderPass.h
Co-authored-by: Powei Feng <powei@google.com>
* Update libs/utils/include/utils/Allocator.h
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
- Add methods for adding attributes to the input mesh
- Add method in TangentSpaceMesh for when user provides the
tangents
- Separate client-side Algorithm enum from implementation algorithm
(AlgorithmImpl)
- Fix CMake config for combining static libs
32 sample may be more suited to 2x upsampling, it gives 8 samples per
high-res pixel (instead of 4). This is also what FSR 2.0 is using,
which is useful for comparing.
This has caused issues and over time we have reduced the use of
spinlocks, it was only used in few places and we still have evidence
that it's causing ANRs.
We use utils::Mutex instead which is a low overhead mutex implementation
on Linux systems.
FIXES=[321101014]
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]
* Bokeh aspect ratio
new DoF option to set the bokeh aspect ratio, this can be used to
simulate anamorphic lenses
* Update android/filament-android/src/main/java/com/google/android/filament/View.java
Co-authored-by: Powei Feng <powei@google.com>
* Update web/filament-js/filament.d.ts
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
See #7415 for a more detailed description of why this change is necessary.
The remaining variants which are filtered from FL0 materials are all related to
lighting, so further hacks like this won't be necessary.
Future work involves properly supporting differing sets of variants based on
shader language.
* TAA improvements
- fix variance + AABB history clipping (we were computing the union
of both AABB instead of the intersection).
- added a setting for the variance parameter
- added a setting for the jitter pattern
- improved some default values
- fixed a few comments
- smaller code tweaks to facilitate future improvements
Material constants (a.k.a: specialization constants) can only be set
during Material creation through Material::Builder.
This change somewhat relaxes that limitation by allowing constants to
be set at runtime on Material directly.
Currently this new API is still private and only supported on FMaterial.
This feature works by invalidating the HwProgram cache of the concerned
Material, causing a shader recompile per variant; so this API is costly
and should be used only for debugging or during app/game configuration.
The TAA material is modified to use constants instead of #defines for
various settings and those are exposed in TaaOptions as well is in
ViewerGui. So with this change all aspects of the TAA material can
be changed at runtime.
Even if skinning is not fully implemented on FL0, we have clients which depend
on materials with skinning variants that otherwise could easily be converted to
FL0 materials. There are two proper ways to deal with this:
1. Support skinning/morphing in Feature Level 0.
2. Allow ESSL 1.0 code and ESSL 3.0 code to support different sets of variants.
However, the simplest solution is to just include skinning/morphing variants,
but disable codegen for ESSL 1.0 code, making them identical to the base
variants. This shouldn't increase the file size much due to the dictionary
deflation. Of course, skinning will not work correctly on FL0, but this has
always been the case. Future work here would be to properly implement one of the
two solutions described above.
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.
