| Age | Commit message (Collapse) | Author |
|---|
|
light and probe elements into storage and reorganise our render_scene method.
|
|
rendering_driver. To differentiate between a driver (e.g. Vulkan or D3D12) and a renderer (e.g. clustered or mobile renderer).
|
|
|
|
|
|
|
|
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.
|
|
`shader_uniform` is now consistenly used across both per-shader
and per-instance shader uniform methods. This makes methods easier
to find in the class reference when looking for them.
|
|
|
|
renderers
|
|
Adds `header_guards.sh` bash script, used in CI to validate future
changes. Can be run locally to fix invalid header guards.
|
|
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
|
|
`rendering/quality/shadows` is now `rendering/quality/positional_shadow`
to explicitly denote that the settings only affect positional light shadows,
not directional light shadows.
Shadow atlas settings now contain the word "atlas" for easier searching.
Soft shadow quality settings were renamed to contain the word "filter".
This makes the settings appear when searching for "filter" in the
project settings dialog, like in Godot 3.x.
|
|
|
|
Split FOG
Split visibility notifier
Final cleanup of storage classes
|
|
This makes VoxelGI and SDFGI work out of the box with primitive meshes,
loaded OBJ meshes and CSG nodes.
|
|
Initial TAA support based on the implementation in Spartan Engine.
Motion vectors are correctly generated for camera and mesh movement, but there is no support for other things like particles or skeleton deformations.
|
|
* Intended to replace RBSet in most cases.
* Optimized for iteration speed
|
|
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
|
|
Didn't commit all the changes where it wants to initialize a struct
with `{}`. Should be reviewed in a separate PR.
Option `IgnoreArrays` enabled for now to be conservative, can be
disabled to see if it proposes more useful changes.
Also fixed manually a handful of other missing initializations / moved
some from constructors.
|
|
This prevents the pitfall of UB when checking if they have been
assigned something valid by comparing to nullptr.
|
|
3 options are available:
- Light and Sky (default)
- Light Only (new)
- Sky Only (equivalent to `use_in_sky_only = true`)
Co-authored by: clayjohn <claynjohn@gmail.com>
|
|
|
|
|
|
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).
|
|
Applying overlay materials into multi-surface meshes currently
requires adding a next pass material to all the surfaces, which
might be cumbersome when the material is to be applied to a range
of different geometries. This also makes it not trivial to use
AnimationPlayer to control the material in case of visual effects.
The material_override property is not an option as it works
replacing the active material for the surfaces, not adding a new pass.
This commit adds the material_overlay property to GeometryInstance3D
(and therefore MeshInstance3D), having the same reach as
material_override (that is, all surfaces) but adding a new material
pass on top of the active materials, instead of replacing them.
|
|
|
|
|
|
Happy new year to the wonderful Godot community!
|
|
This makes it more obvious that the setting only affects mesh LOD,
not manual (H)LOD achieved using visibility ranges.
|
|
|
|
|
|
|
|
Co-authored-by: Brian Semrau <brian.semrau@gmail.com>
|
|
The built-in ALPHA in spatial shaders comes pre-set with a per-instance
transparency value. Multiply by it if you want to keep it.
The transparency value of any given GeometryInstance3D is affected by:
- Its new "transparency" property.
- Its own visiblity range when the new "visibility_range_fade_mode"
property is set to "Self".
- Its parent visibility range when the parent's fade mode is
set to "Dependencies".
The "Self" mode will fade-out the instance when reaching the visibility
range limits, while the "Dependencies" mode will fade-in its
dependencies.
Per-instance transparency is only implemented in the forward clustered
renderer, support for mobile should be added in the future.
Co-authored-by: reduz <reduzio@gmail.com>
|
|
|
|
|
|
This property was intended to provide a way to have SSAO or VoxelGI
ambient occlusion with a color other than black. However, it was
dropped during the Vulkan renderer development due to the performance
overhead it caused when the feature wasn't used.
|
|
VisualServer no longer exists in the `master` branch.
|
|
* Shadow quality settings now specialization constant.
* Decal and light projector filters can be set.
* Changing those settings forces re-creation of the pipelines.
These changes should help improve performance related to shadow mapping, and allows improving performance by sacrificing decal and light projector quality.
|
|
* Keep track of when projector, softshadow or directional sofshadow were enabled.
* Enable them via specializaton constant where it makes sense.
* Re-implements soft shadows.
* Re-implements light projectors.
|
|
* Fixed and redone the process to obtain render information from a viewport
* Some stats, such as material changes are too difficult to guess on Vulkan, were removed.
* Separated visible and shadow stats, which causes confusion.
* Texture, buffer and general video memory can be queried now.
* Fixed the performance metrics too.
|
|
* Rewrote bindings for RenderingServer.
* They are now all up to date.
* Several unused methods and deprecated features were cleaned up.
|
|
* Ability to allocate empty objects in RID_Owner, so RID_PtrOwner is not needed in most cases.
* Improves cache usage, as objects are now allocated together
* Should improve performance in 2D rendering
|
|
|
|
* This is the 3D counterpart to #49632
* Implemented a bit different as 3D works using instancing
After merged, both 2D and 3D classes will most likely be renamed in a separate PR to DisplayNotifier2D/3D.
|
|
This commit adds the following properties to GeometryInstance3D: `visibility_range_begin`,
`visibility_range_begin_margin`, `visibility_range_end`, `visibility_range_end_margin`.
Together they define a range in which the GeometryInstance3D will be visible from the camera,
taking hysteresis into account for state changes. A begin or end value of 0 will be ignored,
so the visibility range can be open-ended in both directions.
This commit also adds the `visibility_parent` property to 'Node3D'.
Which defines the visibility parents of the node and its subtree (until
another parent is defined).
Visual instances with a visibility parent will only be visible when the parent, and all of its
ancestors recursively, are hidden because they are closer to the camera than their respective
`visibility_range_begin` thresholds.
Combining visibility ranges and visibility parents users can set-up a quick HLOD system
that shows high detail meshes when close (i.e buildings, trees) and merged low detail meshes
for far away groups (i.e. cities, woods).
|