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".
Implements basic ASTC support:
* Only 4x4 and 8x8 block sizes.
* Other block sizes are too complex to handle for Godot image compression handling. May be implemented sometime in the future.
The need for ASTC is mostly for the following use cases:
* Implement a high quality compression option for textures on mobile and M1 Apple hardware.
* For this, the 4x4 is sufficient, since it uses the same size as BPTC.
ASTC supports a lot of block sizes, but the benefit of supporting most of them is slim, while the implementation complexity in Godot is very high.
Supporting only 4x4 (and 8x8) solves the real problem, which is lack of a BPTC alternative on hardware where it's missing.
Note: This does not yet support encoding on import, an ASTC encoder will need to be added.
Properly apply custom materials with CanvasGroups in the GLES3 backend
Properly blur backbuffer when using a partial rect in forward_plus and
gl_compatibility renderers
Properly set fit_margin when clear_margin is set
Fix shader error during backbuffer clear in mobile renderer
This uses a similar multipass approach to blend shapes
as Godot 3.x, the major difference here is that we
need to convert the normals and tangents to octahedral
for rendering.
Skeletons work the same as the Vulkan renderer except the bones
are stored in a texture as they were in 3.x.
This includes collision (2D SDF, Box, Sphere, Heightmap),
attraction (Box, Sphere), and all sorting modes.
This does not include 3D SDF collisions, trails, or
manual emission.
The property already has a "seconds" suffix in the inspector.
The "lifetime" term makes it more obvious that the property is
specified as time, not a distance in units.
The property hint now allows manually entering values greater than
10 seconds.
The internal rendering value's default now matches the particles
nodes' default.
This argument is now non optional, but this never hits the same bad access.
I voted to simplify the code here since the argument is never used optionally in our codebase.
Previously, only forward basis distance from the camera was used.
This means that unnecessarily high LOD levels were used for objects located to the side of the camera.
The distance from the camera origin is now used, independently of direction.
Replace all TODO uses of `#warning` by proper TODO comments, and will open
matching bug reports to keep track of them.
We don't have a great track record fixing TODOs, but I'd wager we're even
worse for fixing these "TODO #warning" so we should prohibit this usage.
Not sure why I didn't get those before, it may be due to upstream
changes (12.2.1 is a moving target, it's basically 12.3-dev), or simply
rebuilding Godot from scratch with different options.
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.
Per-light energy gives more control to the user on the final result of
volumetric fog. Specific lights can be fully excluded from volumetric fog
by setting their volumetric fog energy to 0, which improves performance
slightly. This can also be used to prevent short-lived dynamic effects
from poorly interacting with volumetric fog, as it's updated over several
frames by default unless temporal reprojection is disabled.
Volumetric fog shadows now obey Light3D's Shadow Opacity property as well.
The shadow fog fade property was removed as it had little visible impact
on the final scene's rendering.
At this time, it works best in the Vulkan Renderers as they support using multiple samplers with the same texture.
In GLES3 this feature really only allows you to use the screen texture without mipmaps if you want to save the cost of generating them.
This can be used to make shadows translucent for a specific light.
The light distance fade system also uses this to smoothly fade the shadow
when the light fade transition distance is greater than 0.
`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.
Particles won't move or rotate anymore with the node (or its parents)
by default. This new default behavior is generally more suited
to most use cases. Local coordinates can still be enabled on a per-node basis.
This affects both 2D and 3D particles, and both CPU and GPU-based particles.
- Validate format conservatively. (This is to have VRS images created regardless whether VRS attachments are supported, which avoids errors in places where the code assumes such images were created on low-spec GPUs.)
- Create a non-layered default VRS image, which is what Vulkan (and D3D12, by the way) expect.
The new default values are more usable in real world scenarios
when smooth fading of distant decals is desired for performance reasons.
The Decal distance fade property hints were adjusted based on the
GeometryInstance3D visibility range fade property hints. `or_greater`
was also added to allow specifying larger values if needed.
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.
* Moved preprocessor to Shader and ShaderInclude
* Clean up RenderingServer side
* Preprocessor is separate from parser now, but it emits tokens with include location hints.
* Improved ShaderEditor validation code
* Added include file code completion
* Added notification for all files affected by a broken include.
* 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!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
These typedefs don't save much typing compared to the full `Ref<Resource>`
and `Ref<RefCounted>`, yet they sometimes introduce confusion among
new contributors.
