Additionally, change the minimum `tonemap_white` parameter to `1.0`; users can increase `tonemap_exposure` for a similar effect to decreasing `tonemap_white` below `1.0`.
Co-authored-by: Hei <40064911+Lielay9@users.noreply.github.com>
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
GLOBAL_GET is an expensive operation which should not be used each frame / tick.
This PR adds macros which do a cheaper revision check, and only call the expensive GLOBAL_GET when project settings have changed.
Co-authored-by: Lukas Tenbrink <lukas.tenbrink@gmail.com>
Technical implementation notes:
- Moved linearization step to before the outset matrix is applied and
changed polynomial contrast curve approximation.
- This does *not* implement Blender's chroma rotation to address hue shift.
This hue rotation was found to have a significant performance impact.
- Improved performance by combining the AgX outset matrix with the Rec 2020 matrix.
Co-authored-by: Allen Pestaluky <allenpestaluky@gmail.com>
Co-authored-by: Clay John <claynjohn@gmail.com>
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
"less" should be used for quantity, rather than "lesser".
Existing scripts that use `or_lesser` in `_get_property_list()`
will need to be updated to account for this change.
Values lower than 1.0 can be used to make the fog rendering not fully
obstruct the sky. This can be desired when using fog as a purely
atmospheric effect, without intending to use fog for open world fog
fading.
When set to 0.0, fog rendering behavior will be similar to Godot 3.x
where sky rendering was never affected by fog.
This allows light sources to be specified in physical light units in addition to the regular energy multiplier. In order to avoid loss of precision at high values, brightness values are premultiplied by an exposure normalization value.
In support of Physical Light Units this PR also renames CameraEffects to CameraAttributes.
- Add `positive_only` property hint to disallow using negative presets.
These values are clamped in several places in the editor already,
so this avoids displaying presets that don't work.
- Move the Zero preset at the end of the positive list to match
the custom property editor. It's also used less often than Linear,
Ease In and Ease Out.
- Rename presets to be consistent between the easing property editor
and custom property editor.
- Remove unused `inout` hint which was redundant since it was already
the default.
The value is already clamped in the editor, but it wasn't being
clamped when the value was set via code. Values outside the [0.0; 1.0]
range can result in broken rendering.
- Enable Read Sky Light to get proper outdoors lighting out of the box.
- Set bounce feedback to 0.5 by default to get a better quality result.
- Higher values may cause infinite feedback with bright surfaces.
- Increase the number of frames to converge to improve quality
at the cost of latency. Most scenes are fairly static after all.
- Use 75% Y scale by default as most scenes are not highly vertical.
- Reorder the Y scale enum to go from the lowest Y scale to the highest.
Also rename the "Disabled" setting to "100%" for clarity.
This provides more flexibility between performance and quality
adjustments, especially when using SDFGI for small-scale levels
(which can be useful for procedurally generated scenes).
Values below 0.5 will cause constant flickering in most situations,
and values above 0.99 take a very long time to fully update
(10+ seconds at high framerates).
