Although the expanded bounds were working in normal use, for moving and growing objects, there was one case which was not dealt with properly - significant shrinkage of exact bounds within an expanded bound.
This PR detects significant shrinkage and forces a new expanded bound to be created.
(cherry picked from commit ed47570266)
Some versions of microsoft compiler flag a warning that they want a typename keyword in templates in more places than clang / gcc.
(cherry picked from commit 9315b4fb51)
Updating the broadphase to find new collision pairs was done after
checking for collision islands, so it was working in most cases due to
the pairing margin used in the BVH, but in case of teleported objects
the narrowphase collision could be skipped.
Now it's done before checking for collision islands, so we can ensure
that broadphase pairing has been done at the same time as objects are
marked as moved so their collision can be checked properly.
This issue didn't happen in the Octree/HashGrid because they do nothing
on update and trigger pairs directly when objects move instead.
(cherry picked from commit e9fdf3e61f)
Previously a crude metric was used to decide on the roaming expansion margin, but it created unexpected results in some scenarios. Instead this setting is exposed to the user via the RoomManager, allowing them to tailor it to the world size, room sizes, roaming objects sizes and the speeds of movement.
(cherry picked from commit 788f075b44)
Reporting rest collision information is needed for move_and_collide and
move_and_slide so floor detection can be done properly, but in the case
of just testing the motion for collision, it makes sense to return false
if the body is able to move all along the path without being stopped.
Updated the logic in test_move and clarified the documentation for
test_move and move_and_collide.
(cherry picked from commit 1560c8b5aa)
In all physics servers, body_get_direct_state() now silently returns
nullptr when the body has been already freed or is removed from space,
so the client code can detect this state and invalidate the body rid.
In 2D, there is no change in behavior (just no more errors).
In 3D, the Bullet server returned a valid direct body state when the
body was removed from the physics space, but in this case it didn't
make sense to use the information from the body state.
(cherry picked from commit b93aeec4a2)
The hash symbol creates spurious issue references on GitHub if
the message is posted outside a code block, which means some issues
have a lot more references than originally intended.
(cherry picked from commit 63d214f04b)
This is useful information to have for troubleshooting, and it's
said to sidestep a possible race condition issue that breaks
microphone recording on Linux.
(cherry picked from commit de912a8bd9)
This prevents the viewport from going upside-down.
This was suggested at:
https://github.com/godotengine/godot/pull/51984#issuecomment-948614191:
> For 3.4, I think we can just clamp the angle value when using the
> camera orbiting shortcuts. We can investigate what to do with panning
> and freelook in 3.5 and 4.0.
(cherry picked from commit 3bd7c4f2a9)
For octahedral compressed normals/tangents, we use vec4 in the shader
regardless of whether a normal/tangent does/doesn't exist
For the case where we only have a normal vector, we need to specify that
there are only two components being used when calling glVertexAttrib
Before we would always specify that there were 4 components, and used
offsets to determine where in the vertex buffer to read data from but
this doesn't work on all platforms
(cherry picked from commit 8a43b222c7)
Replaced some in-loop uses of Vector.write with an out of loop ptrw,
to avoid a lot of superfluous reads on the CowData ref count.
(cherry picked from commit 47496a55bc)
After the decision to continue feature development for the `3.x` branch
alongside the `master` branch for Godot 4.0, we released 3.3-stable in
April 2021.
6 months and 2000 commits later, Godot 3.4 is another feature-packed milestone
for Godot 3, with a ton of improvements and fixes to make it a great option
for use in production while we wait for Godot 4.0!
A big thankyou to all contributors who work tirelessly on our two parallel
development branches and made this stable 3.4 release possible.