MODE_DYNAMIC instead of MODE_RIGID
MODE_DYNAMIC_LOCKED instead of MODE_CHARACTER
No more special case for sleeping behavior for MODE_DYNAMIC_LOCKED
(MODE_CHARACTER was forcing the body not to sleep, which is redundant
with can_sleep and wasn't done in Bullet).
Use ThreadWorkPool to process physics step tasks in multiple threads. Collisions are all processed in parallel and solving impulses is
processed in parallel for rigid body islands.
Additional changes:
- Proper islands for soft bodies linked to active bodies
- All moving areas are on separate islands (can be parallelized)
- Fix inconsistencies with body islands (Kinematic bodies could link
bodies together or not depending on the processing order)
- Completely prevent static bodies to be active (it could cause islands
to be wrongly created and cause dangerous multi-threading operations as
well as inconsistencies in created islands)
- Apply impulses only on dynamic bodies to avoid unsafe multi-threaded
operations (static bodies can be on multiple islands)
- Removed inverted iterations when populating body islands, it's now
faster in regular order (maybe after fixing inconsistencies)
Several optimizations in the way solver islands are processed in both
2D and 3D physics:
- Use LocalVector instead of linked list to avoid cache misses (with
persistent storage based on worst case scenario)
- Remove pairs when setup fails (no valid contact) to avoid unnecessary
solving of non-colliding rigid bodies just to return immediately
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
I couldn't find a tool that enforces it, so I went the manual route:
```
find -name "thirdparty" -prune \
-o -name "*.cpp" -o -name "*.h" -o -name "*.m" -o -name "*.mm" \
-o -name "*.glsl" > files
perl -0777 -pi -e 's/\n}\n([^#])/\n}\n\n\1/g' $(cat files)
misc/scripts/fix_style.sh -c
```
This adds a newline after all `}` on the first column, unless they
are followed by `#` (typically `#endif`). This leads to having lots
of places with two lines between function/class definitions, but
clang-format then fixes it as we enforce max one line of separation.
This doesn't fix potential occurrences of function definitions which
are indented (e.g. for a helper class defined in a .cpp), but it's
better than nothing. Also can't be made to run easily on CI/hooks so
we'll have to be careful with new code.
Part of #33027.
Which means that reduz' beloved style which we all became used to
will now be changed automatically to remove the first empty line.
This makes us lean closer to 1TBS (the one true brace style) instead
of hybridating it with some Allman-inspired spacing.
There's still the case of braces around single-statement blocks that
needs to be addressed (but clang-format can't help with that, but
clang-tidy may if we agree about it).
Part of #33027.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
It seems to stay compatible with formatting done by clang-format 6.0 and 7.0,
so contributors can keep using those versions for now (they will not undo those
changes).
Using `misc/scripts/fix_headers.py` on all Godot files.
Some missing header guards were added, and the header inclusion order
was fixed in the Bullet module.
-Added ability to disable individual collisionshape/polygon
-Moved One Way Collision to shape, allowing more flexibility
-Changed internals of CollisionObject, shapes are generated from child nodes on the fly, not stored inside any longer.
-Modifying a CollisionPolygon2D on the fly now works, it can even be animated.
Will port this to 3D once well tested. Have fun!
I can show you the code
Pretty, with proper whitespace
Tell me, coder, now when did
You last write readable code?
I can open your eyes
Make you see your bad indent
Force you to respect the style
The core devs agreed upon
A whole new world
A new fantastic code format
A de facto standard
With some sugar
Enforced with clang-format
A whole new world
A dazzling style we all dreamed of
And when we read it through
It's crystal clear
That now we're in a whole new world of code
This is a continuation of an on-going work for 64-bit floating point builds, started in PR #7528. Covers physics, physics/joints and physics_2d code.
Also removed matrixToEulerXYZ function in favor of Basis::get_euler.
This is the follow up for the 2D changes mentioned in PR #6865. It fixes various mistakes regarding the order of matrix indices, order of transformation operations, usage of atan2 function and ensures that the sense of rotation is compatible with a left-handed coordinate system with Y-axis pointing down (which flips the sense of rotations along the z-axis). Also replaced float with real_t, and tried to make use of Matrix32 methods rather than accessing its elements directly.
Affected code in the Godot code base is also fixed in this commit.
The user code using functions involving angles such as atan2, angle_to, get_rotation, set_rotation will need to be updated to conform with the new behavior. Furthermore, the sign of the rotation angles in existing 2D scene files need to be flipped as well.
That year should bring the long-awaited OpenGL ES 3.0 compatible renderer
with state-of-the-art rendering techniques tuned to work as low as middle
end handheld devices - without compromising with the possibilities given
for higher end desktop games of course. Great times ahead for the Godot
community and the gamers that will play our games!
You can't set this value very well, since it's automatically computed
from the mass and the collision shapes. But since the values are higher
than many people might suspect, so being able to read it helps estimate
the amount of torque you might need to apply.
