Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Minor code improvements in Node3D
|
|
a shared implementation.
|
|
Each file in Godot has had multiple contributors who co-authored it over the
years, and the information of who was the original person to create that file
is not very relevant, especially when used so inconsistently.
`git blame` is a much better way to know who initially authored or later
modified a given chunk of code, and most IDEs now have good integration to
show this information.
|
|
Decrease the default dynamic range in VoxelGIData to 2.0
|
|
|
|
Calinou/geometryinstance3d-lod-fade-node-configuration-warning
Emit node configuration warnings for GeometryInstance3D distance fade
|
|
|
|
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.
|
|
|
|
The order now goes from least to most computationally expensive:
- Disabled
- Static
- Dynamic
|
|
To make baked colors of lights equal to dynamic colors of lights they have to be
converted to linear as the colors of dynamic lights are converted to linear by
RendererSceneRenderRD.
|
|
Makes the API for forces and impulses more flexible, easier to
understand and harmonized between 2D and 3D.
Rigid bodies now have 3 sets of methods for forces and impulses:
-apply_impulse() for impulses (one-shot and time independent)
-apply_force() for forces (time dependent) applied for the current step
-add_constant_force() for forces that keeps being applied each step
Also updated the documentation to clarify the different methods and
parameters in rigid body nodes, body direct state and physics servers.
|
|
Fixed PR issues.
Update vehicle_body_3d.cpp
Apply suggestions from code review
Co-authored-by: Camille Mohr-Daurat <pouleyKetchoup@gmail.com>
|
|
|
|
|
|
|
|
Also:
- Adds two stress tests to test_string.h
- Changes to .empty() on std::strings
|
|
|
|
This reduces visible banding in indirect lighting and reflections.
Sharp reflections now match more closely the original scene.
The downside of this change is that clipping may appear in reflections
in extremely bright scenes, but this should not be a concern in most
scenes.
|
|
GPUParticles attractors and collision are currently only available in 3D.
Their 2D counterparts haven't been implemented yet, but they will use
separate nodes.
|
|
|
|
|
|
|
|
Works with 2D and 3D GPU Particles
|
|
|
|
|
|
We prefer to prevent using chained assignment (`T a = b = c = T();`) as this
can lead to confusing code and subtle bugs.
According to https://en.wikipedia.org/wiki/Assignment_operator_(C%2B%2B), C++
allows any arbitrary return type, so this is standard compliant.
This could be re-assessed if/when we have an actual need for a behavior more
akin to that of the C++ STL, for now this PR simply changes a handful of
cases which were inconsistent with the rest of the codebase (`void` return
type was already the most common case prior to this commit).
|
|
The `opacity` property is superseded by the GeometryInstance3D
`transparency` property. It works the opposite way (0.0 is opaque,
1.0 is fully transparent), but provides the same behavior in a more
universal manner.
|
|
The visibility range begin/end margin properties must be set above 0.0
for the fade transition to be visible.
|
|
cpu) as mentioned here: https://github.com/godotengine/godot/issues/54993
|
|
Floating-point values are accepted as dynamic range settings.
This also clamps the lowest value to 1.0, as there's no practical
use case for going below 1.0 (it introduces clipping without
improving precision).
|
|
|
|
|
|
Fix wall acceleration in move and slide (3D)
|
|
|
|
|