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.
Negatively scaled objects should be mirrored. This is already implemented, but it breaks when mirrored and non-mirrored instances of the same object are visible together.
It turns out that the code that skips-over repeats in `RenderForwardClustered::_render_list_template` also skips the code that accounts for the culling mode of mirrored objects.
The solution here is to consider the `mirror` flag when determining repeats. This might result in more draw commands than necessary since a mirrored object can split a group of non-mirrored instances in two.
This problem doesn't appear in the mobile renderer because the repeat optimization isn't implemented there yet.
The problem still appears in MultiMeshInstance3D in *all* renderers.
Fixes#62879 and #58546.
The flag INSTANCE_DATA_FLAG_MULTIMESH is used for both multimesh and particles instances, this commit adds a new INSTANCE_DATA_FLAG_PARTICLES flag to discriminate between them.
This flag will also be used in the future to properly support TAA in particles.
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.
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.
`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.
This is consistent with the BaseMaterial3D filtering options.
It can be used for high-quality pixel art textures that remain sharp
when viewed at oblique angles, but prevents them from becoming grainy
thanks to mipmaps.
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.
