- move the control code out of FrameInfo and into
View itself. FrameInfo now just gathers information about the
frames instead of also doing part of the control.
- the control code has been refactored into a more formal PIDController.
- a few bugs were fixed in the control loop and default parameters
tuned.
The control loop itself now outputs a relative scale factor instead
of an absolute one. The relative scale factor seems easier to
control and is less jittery, and doesn't have to rely on the "integral"
term of the PID.
It's possible that more tuning is needed, but the scaling is now
more stable.
- defaults to 31 history points instead of 3, this gives a much better
estimate of the frame rate.
- make sure the calculations work for any definition of our internal
duration<> (it's useful to use milliseconds when dealing with
refresh periods).
- don't round to 8 pixels if the scale factor is exactly 1
- fix a few comments and warnings
Java callbacks are now directly dispatched to their handler, instead
of first going through filament's opportunistic dispatch, reducing
callback latency.
A new Engine::pumpMessageQueues() method can be used to trigger all
pending user callbacks right away. This can help reducing latency
of certain callbacks such as picking queries.
This is typically called once before calculating the next frame's
parameters (e.g. object positions or appearance that may depend on a
callback result).
Fix some comments and documentation.
This is a pixel accurate implementation of picking. Picking queries
can be created on view, and upon completion a user provided callback
is called with the Entity of the renderable at the queried coordinates
in the viewport.
Picking queries typically have 1 or 2 frame of latency and may impact
performance on some drivers.
It is mostly intended for use by editors, or when latency is not a major
concern. This api should not be used for dragging/moving objects, it is
intended for initial picking only.
Picking is implemented in the structure pass.
The depth buffer value is retrieved and the fragment coordinate is
reconstructed and passed to PickingQueryResult. This can be used in
turn to calculate the view and/or world space position.
Now that FSR scaling is cheap enough on mobile, we use it for quality
levels MEDIUM to ULTRA.
MEDIUM and HIGH use the mobile optimized version, which has a slightly
lower quality, ULTRA uses the original version.
Additionally the RCAS sharpening pass can always be disabled by setting
the sharpen value to 0.
In low-light conditions, peak luminance sensitivity of the eye shifts
toward the blue end of the visible spectrum. This effect called the
Purkinje effect occurs during the transition from photopic (cone-based)
vision to scotopic (rod-based) vision. Because the rods and cones use the
same neural pathways, a color shift is introduced as the rods take over to
improve low-light perception.
This function aims to (somewhat) replicate this color shift and peak
luminance sensitivity increase to more faithfully reproduce scenes in
low-light conditions as they would be perceived by a human observer
(as opposed to an artificial observer such as a camera sensor).
The night adaptation can be controlled using a 0..1 factor for artistic
reasons: `ColorGrading::Builder::nightAdaptation()`.
* Use wide gamut color grading and gamut mapping
This change introduces a new API on ColorGrading to enable or disable gamut mapping at will. This feature is currently off by default and while useful and recommended, it isn't cheap and we need to figure out what we want our defaults to be especially on mobile targets.
Gamut mapping can be combined with luminance scaling to properly control hue skews.
* Small cleanup
* More precise Rec.2020 conversion
Augment the TransformManager so it can maintain the 4th column as
double precision; we accomplish this by storing an extra float3 per matrix.
It's calculated as `doubleTranslation - float3{doubleTranslation}`.
We also add methods to set and get a transform as mat4, internally only
the 4th column is kept as double precision.
Finally when we calculate the worldTransform, we take this extra data into
account, but only for calculating the new 4th column, so the extra work
is small.
The new default values match almost exactly the filmic tone mapper which
is itself a close approximation of ACES. This result in a slightly more
contrasty and pleasing image out of the box.
Camera::getProjectionMatrix and Camera::getCullingProjectionMatrix used
to return the projection matrix modified by scaling and shift, instead
they should return the value set by the user, especially when
setCustomProjection() is used.
Currently there are 8 light channels, both renderables and lights can
be associated to one or several light channel, lighting occurs when
at least one channel is active on both the light and the renderable.
Fixes#4275
We now have an option for evaluating the bent normals from SSAO.
This is used to improve specular AO.
Currently these bent normals are not used for diffuse lighting because
they're "flat" (face normals), which is too distracting.
The bent normal buffer is stored in the SSAO texture, in a separate
layer. This is the first post processing effect that uses 2D array
in order to limit our sampler usage.
This CL also changes how we handle SPECULAR_AO_BENT_NORMALS when
material bent normals are not available: we're now using the "Cones"
algorithm with the regular normal, instead of Lagarde's approximation.
This can have a dramatic effect on SSAO and needs
to be adjusted based on the scene's scale/units.
The default value used to be about 6cm, and has
been changed to 5mm.
* WIP New tone mapper API
* Implement tone mapper constructors and destructors
* Add new genertic tone mapper
* Make the generic tone mapper available in our sample UIs
* Fix warnings and crashes
* Fix generic tone mapper and graph mappers in the UI
* Add Java APIs for ToneMapper
* Implement copy/move operators for GenericToneMapper
The API now allows to create a standalone SkinningBuffer containing
Bones for skinning. This SkinningBuffer can even be very large and
contain bone data for several renderables.
New APIs on RenderableManager allow to switch to skinning buffer mode
and to set the SkinningBuffer (and window into it) to use.
Fixes#3238
* Generalize luminance scaling in color grading
Previously the luminance scaling step was tied to a specific tone
mapping operator, called "EVILS" in the API. This was however
somewhat misleading as EVILS really is a color handling system
that's independent of what we call tone mapping.
This change splits the luminance scaling step from the tone mapping
step, allowing the use of luminance scaling (the LICH part of EVILS)
with any tone mapping operator.
As a result, the operator known as EVILS is currently mapped to the
linear operator and renamed to "RESERVED" until it is replaced by
a proper — configurable — operator.
* Update release notes
* Fix web build
* Add new sample app: image_viewer
This app shows how to load and visualize images. It's also useful to work
on color grading and other post-processing effects by just loading an HDR
or EXR image as a reference.
This change also adds a new exposure setting to the color grading LUT.
* Fix comments and build
* Fix Metal
* Use high precision for the UV coordinates
* Fix refactoring issue
* Remove support for Java/desktop builds
These builds are never tested nor used on our end. We cannot
guarantee their proper support. It should also be possible
for an app to handle this itself.
* Remove Tungsten since it cannot be compiled anymore
This adds some significant JNI glue in order to make the Java API for
gltfio materials much more consistent with C++, and create feature
parity between the two languages.
The motivation is to allow Java clients to provide their own
ubershader-based solution or filamat-based solution.
- The `MaterialProvider` Java class is now an interface.
- The `UbershaderLoader` Java class is now a concrete implementation.
- Users can now write their own provider class using Java / Kotlin.
To streamline the amount of JNI work that occurs at run time, the
MaterialProvider Java interface uses ints in a couple spots instead
of enums. This sacrafices some readability for Java clients who wish
to write their own provider, but makes the JNI much simpler.
This replaces #3975.
- the clear color was broken since we switched dot EVSM
- use the scissor instead of the viewport, it makes it easier to compute
the uv-scale.
- the min/max lod level wasn't reset properly
- also clamp the minimum shadowmap size to 8, and document it.
This is still somewhat work-in-progress, but good enough to be useful.
Some caveats:
- large blurs don't work well with cascades
- the implementation uses more memory than it could
- use EVSM (exponential VSM), helps a lot with light bleeding
- don't apply shadow biases with VSM
- improve VSM user settings: added more controls, expose to java
- minor code cleanups:
- rename some structures
- remove unused parameters
- remove unused uniforms
This reworks how we compute the bloom buffer size. The main changes are:
- The BloomOptions.resolution is changed to height instead of minor axis.
This keeps a consistant look of the bloom regardless of the viewport.
- The anamorphism setting now dilates the bloom rather than to compress
it (in the other direction), which maintains the same amount of bloom.
However, the resolution decreases meaning that the user might need to
adjust resolution and/or levels.
- limit the resolution do 2048 which is gles minspec.
(1)
The C++ RenderTarget API might be used by an external Android library
such as filament-utils-android and therefore needs to be in the map
file.
(2)
Texture, Skybox, and IndirectLight each had two "nativeObject"
constructors which exist for the benefit of filament-utils-android,
but each of these classes only need one nativeObject constructor.
deprecate Stream::stream(intptr_t).
This method was needed for ARCore back in the days, but there is now a
zero-copy way to achieve the same thing. This API shouldn't be used anymore.
* New experimental tone mapper
The new tone mapper proposed in this change replaces Uchimura (see
below) and is composed of two distinct algorithms:
- The first is the customizable compression curve from Timothy Lotte
(from GDC 2015). The curve's default parameters were chosen to
match the overall appearance (contrast) of the ACES curves used
as our current default tone mapper. This was done to provide a
good migration path to making this new solution the default in
a future version of Filament.
The compression curve can be customized via its contrast, shoulder,
input middle gray, output middle gray, and maximum "HDR value"
(scene referred).
It is important to note that the compression is only applied to
the luminance of the input scene referred value.
- The second is a novel approach by Troy Sobotka called Exposure
Value Invariant Luminance Scaling (or EVILS). This solution works
on the largest chromatic channel of the input value as opposed
to mapping all RGB channels as we do in our other tone mappers.
The algorithm effectively scales all channel by a ratio that
depends on both the compressed luminance from the first stage
and the luminance of input value normalized by the largest
channel.
This new solution offers important benefits as it manages to
preserve chromaticity for high input values. It is also designed
to provide a desirable rolloff to white on overexposure. This
means that even without gamut mapping, this solution avoids many
hue skews (red to orange, blue to purple, etc.). The results
provided by this solution are much more natural and make using
other color grading tools much easier.
* Use std::pow instead of pow
* Fix Web builds
Fixes issue seen with Vulkan + the quantized version of Avocado.
We already support the quantized glTF extension, which is when this
comes up. Technically this is only needed for Vulkan but gltfio does
not (and should not) know which backend is being used, so we simply
apply these transformations assuming the worst.
In practice this code usually won't be activated, and if even when it
is, it won't hurt loading time as much as other things like large
textures.