Previously the cache would try to keep its size below a user-settable
value. This was not effective because when that value was too small,
it would cause a lot of churn every frame without actually keeping
the memory usage below the specified value.
We now evict buffer aggressively after they've not been used
(for two frames by default), but we don't cap the size of the cache.
The cache will naturally settle at the size it needs. When dynamic
resolution is used, it might be needed to increase resources
maximum age, which is a user-settable value still.
This improves performance on mobile on many scenes because the 64MB
default value was too low, causing the crash to thrash.
This is supported only by the PlatformEGL currently. There is not much
that can be done with it either at this point. A protected swapchain is
one that can only be written by a protected context, however, there
is currently no way to create such context.
These are missing parts from the commit
111ad96134.
NDK 26.1.10909125 is used by default
Minimum API level on Android is now API 21 instead of API 19. This allows the use of OpenGL ES 3.1
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.
* 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>
* 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
We shouldn't remove the listener callbacks when a surface is destroyed
by the system (e.g. screen off/on) because then we won't know when
it comes back.
But we still need to do this when the user calls UiHelper.detach() or
when we are attaching to a new surface.
Fixes#7424
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.
- deprecate blit(), renamed to blitDEPRECATED. It's only used in one
place in copyFrame() now. We can't void it because we don't have
access to the texture from the RenderTarget.
- add a new blit() api that works with textures instead of render
targets.
- add a new resolve() api that works with textures instead of render
targets. doesn't support scaling.
- always use a shader when scaling in the framegraph
(there was only one place where we used blit)
- use the new blit() for:
- for mipmap generation on vk (fixme)
- copying the depth buffer to avoid ssao feedback loop
- use the new resolve() for:
- manually resolving MSAA color/depth
- Simplify the resolve APIs on the filament side
- implement generateMipmaps for the vulkan backend
simplify MetalBlitter
- remove metal blit workarounds
- don't issue a blit from a renderpass, this only affect Renderer::copyFrame
- We only handle a single texture now (instead of color+depth), so we
can simplify the code a lot.
Didn't touch the "slowpath" much, but it now assumes it blits color or
depth, not both.
We were not unregistering the TextureView or SurfaceHolder callbacks on
detach, so they could fire and access an null'ed RenderSurface
FIXES=[308443790]
* Add Material.compile() Java binding.
* Add Engine.flush() java binding
* Add Scene.forEach java binding
update the Android gltf-viewer sample to precompile all variants of all
materials in the scene, similarly to the desktop sample.
Moving setFrontFaceWindingInverted to MaterialInstance will enable
finer control over face inversion and aligns better with Vulkan's
pipeline definition (see VkGraphicsPipelineCreateInfo).
Enable a limited subset of materials in PostProcessManager for FL0.
Create new function Material::getFeatureLevel() in C++ and Java.
Create missing Material::getReflectionMode() method in Java.
This change does three main things. First, it adds an option to the Engine
Builder to pick the feature level at which to instantiate Filament. The only
real practical purpose of allowing this is to be able to instantiate at feature
level 0. Secondly, it allows feature level 0 to properly work on non-ES2
devices. Thirdly, it changes both Android and desktop hellotriangle samples to
explicitly opt-in to feature level 0.
Unfortunately, feature levels are used in two different, somewhat contradictory
ways presently in Filament, which can make reasoning about this change a bit
confusing. From a client perspective, feature levels refer to buckets of
capabilities which are guaranteed to be supported. Internally, there is a
separate "feature level" stored internally at the Driver subclass level which
generally corresponds to the maximum supported feature level, but is also
referenced when activating workarounds for limited devices. For example, Uniform
Buffer Objects are not supported in ES2, however, Filament supports emulating
them such that the client does not need to care at all; a supported feature is a
supported feature. But internally, Filament uses this "Driver" feature level to
determine whether or not a given workaround is needed. There were several cases
where the "active feature level" was being examined in order to activate these
workarounds rather than the "driver feature level", which was incorrect.
Why should non-ES2-only devices want to activate feature level 0? Allowing this
behavior 1. makes feature level 0 more consistent with the behavior of other
feature levels and 2. allows clients a layer of validation that their software
will work on all devices supported by Filament if they explicitly opt into it.
Consistency: Filament guarantees that any given device which supports a given
feature level will also support running on every feature level below, except for
feature level 0. This change removes that exception.
Validation: It's not perfect, and there will likely be bugs and unexpected
differences in behavior between ES2 and non-ES2 devices that crop up in the
future between two devices running on the same feature level. However, it's at
least a basic high level layer of validation that enables more rapid testing
workflows directly via desktop versions of Filament rather than having to fiddle
with something like ANGLE to get perfect GLES 2.0 compliance. Additionally, it
expands options for automated testing (with the same caveats).
This change has been tested on both the desktop and Android versions of
hellotriangle.
* prevent public classes from being created on the stack
- we used to to this by deleting operator delete, but this prevented
the internal "F" classes from being virtual; which can be useful
when using EntityManger::Listener.
now we just make the destructor protected in each class.
- EntityManger::Listener now has a virtual destructor so that
objects could be correctly destroyed from Listener*
* improve EntityManger and Component managers
- all component managers now have the same "base" API
- getComponentCount()
- empty()
- getEntity()
- getEntities()
- Scene now has getEntityCount()
- EntityManager now has getEntityCount()
- all component manager implement gc() the same way, by calling destroy()
- SingleInstanceComponentManager::gc() that calls removeComponent() has
been removed because it's dangerous. removeComponent() is often
not enough, some additional cleanup might be needed.
* 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>
