Since we clone the environments to build thirdparty code, we don't get an
explicit dependency on the build objects produced by that environment.
So when we update thirdparty code, Godot code using it is not necessarily
rebuilt (I think it is for changed headers, but not for changed .c/.cpp files),
which can lead to an invalid compilation output (linking old Godot .o files
with a newer, potentially ABI breaking version of thirdparty code).
This was only seen as really problematic with bullet updates (leading to
crashes when rebuilding Godot after a bullet update without cleaning .o files),
but it's safer to fix it everywhere, even if it's a LOT of hacky boilerplate.
(cherry picked from commit c7b53c03ae)
(cherry picked from commit e94161dada)
Allows users to override default API usage, in order to get best performance on different platforms.
Also changes the default legacy flags to use STREAM rather than DYNAMIC.
Fixes#46181
CameraServer.add_feed() takes a CameraFeed object type as parameter.
Passing in another type of data while binding the method it will make
tha parameter null.
Added a check for null which returns from function and does not make the
engine crash anymore.
(cherry picked from commit c158a63a8a)
The program would fail if the parameter is passed as null in set_primary_interface because
in the print_verbose, the get_namea) method is called on the parameter and this causes a
failure if the parameter that was passed is null.
The moment of inertia calculation for BoxShape is:
```
Vector3(
(p_mass / 3.0) * (ly * ly + lz * lz),
(p_mass / 3.0) * (lx * lx + lz * lz),
(p_mass / 3.0) * (lx * lx + ly * ly));
```
where the final line includes both the x and y extents.
However, for CapsuleShape3D, CylinderShape3D, ConvexPolygonShape3D, ConcavePolygonShape3D, and HeightMapShape3D, the final line read `(p_mass / 3.0) * (extents.y * extents.y + extents.y * extents.y)`. I believe this is a mistake, considering the comment in each case mentions using an AABB approximation, which should follow the same approach as BoxShape.
This change corrects the final line to include both the x and y components of the shape's extent.
The angular velocity estimate for kinematic bodies was calculated
incorrectly. Also, fixes its use in some kinematic/rigid collision
calculations.
3.3 version of #47130
Test specific axes before falling back to GJK-EPA algorithm to get more
accurate separation axes for common cases, the same way it's done for
cylinder-cylinder collision.
In the case of falling back to GJK-EPA algorithm to generate cylinder
contact points, margins were never taken into account.
This fixes the depenetration phase for kinematic bodies and allows
consistent floor detection for cylinder shapes.
- Fix objects with no material being considered as fully transparent by the lightmapper.
- Added "environment_min_light" property: gives artistic control over the shadow color.
- Fixed "Custom Color" environment mode, it was ignored before.
- Added "interior" property to BakedLightmapData: controls whether dynamic capture objects receive environment light or not.
- Automatically update dynamic capture objects when the capture data changes (also works for "energy" which used to require object movement to trigger the update).
- Added "use_in_baked_light" property to GridMap: controls whether the GridMap will be included in BakedLightmap bakes.
- Set "flush zero" and "denormal zero" mode for SSE2 instructions in the Embree raycaster. According to Embree docs it should give a performance improvement.
Changes default ninepatch mode to preserve compatibility, and renames default mode to 'fixed'.
Also adds an editor restart to changing ninepatch mode and software skinning, which will be more user friendly.
More work is needed to make sure that those options actually solve users' issues, so we prefer to remove the options for 3.2.4 and revisit for a future release.
Automatically set the `baked_light` bool when applying a lightmap to an
instance. This ensures the disabling of dynamic lights when the
bake mode is set to ALL.
The rendering/quality/2d section of project settings is becoming considerably expanded in 3.2.4, and arguably was not the correct place for settings that were not really to do with quality.
3.2.4 is the last sensible opportunity we will have to move these settings, as the only existing one likely to break compatibility in a small way is `pixel_snap`, and given that the whole snapping area is being overhauled we can draw attention to the fact it has changed in the release notes.
Class reference is also updated and slightly improved.
`pixel_snap` is renamed to `gpu_pixel_snap` in the project settings and code to help differentiate from CPU side transform snapping.
Two common problems have emerged as a result of transform snapping:
1) Camera jitter with a camera following a snapped object
2) Pixel gaps between e.g. a platform and a player, where a platform rounds down and a player rounds up
Using round seems to greatly reduce problems due to camera jitter. It also may prove better for pixel gaps because pixel art is often designed on a grid, so whole numbers are too expected, which are unstable with floor().
These are benign but worth fixing as it clears the log to find more important errors.
A common problem with the sanitizer is that enums are often used to represent bits (e.g. 1, 2, 4, 8 etc) but without specifying the enum type, the compiler is free to use unsigned or signed int. In this case it uses int, and when it performs bitwise operations on the int type, the sanitizer complains.
This is probably because a bitshift with negative signed value can give undefined behaviour - the sanitizer can't know ahead of time that you are using the enum for sensible bitflags.
