This change does two things:
1. Properly update the internal shape data using _update_in_shape_owner
when updating a shape (in 2D it was resetting one way collision)
2. Avoid unnecessary updates when calling set_shape with the same shape,
which happens each time a shape property is modified
(e.g shape.extents.x = ...)
Fixes#45090
(cherry picked from commit 4b43cd17c5)
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 🎆
(cherry picked from commit b5334d14f7)
Body transforms from physics are used to setup the joint and they are
only updated before the physics step by default.
Without forcing the transform update, joints could use a previous
position if the body's position was set after it was added to the scene.
3D physics is not affected by this issue.
(cherry picked from commit 11bee25de4)
Partially revert change allowing sprite get_rect snapping to be controlled by `pixel_snap` again rather than `transform_snap` (to prevent breaking compatibility). Adds a final `use_camera_snap` project setting to allow snapping viewports as in reduz original PR.
Changed CPU velocity calculation for EMISSION_SHAPE_DIRECTED_POINTS
to follow the same logic as in the GPU version:
mat2 rotm;
rotm[0] = texelFetch(emission_texture_normal, emission_tex_ofs, 0).xy;
rotm[1] = rotm[0].yx * vec2(1.0, -1.0);
VELOCITY.xy = rotm * VELOCITY.xy;
Now both CPUParticles2D & CPUParticles3D (z disabled) show the same results
as their GPU counterparts and take the initial velocity settings into account.
(cherry picked from commit 1c231cacb3)
`ConvexPolygonShape2D` and `ConcavePolygonShape2D` are only meant to be
used directly in code and not in the editor for physics-based use cases
specifically.
Developers are advised to use `CollisionPolygon2D` instead, which does
generate those shapes under the hood, handling polygon convexivity,
proper orientation etc.
(cherry picked from commit dc446203be)
This reverts commit 7f61710183.
See #38868, in its current implementation a small skew value might end up
serialized to scene files due to floating point precision errors, which is
detrimental to VCS.
This can be cherry-picked anew once a fix for #38868 has been found.
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
Skew is x-axis only, because it must be bidirectionally convertible to a 2x3 matrix, but you can subtract it to the rotation to get the effect on y-axis
(cherry picked from commit efb1f7d76b)
Calls to set_amount can increase the size of the particle array, but do not zero the memory, they only set the active flag to false. This uninitialized memory can be sent to the GPU, possibly as NaNs.
The code above for horizontal movement uses the right margin (_positive_ x direction) when the offset is negative, but vertical movement uses the top margin (_negative_ y direction) when the offset is negative.
The resulting problem is easily seen in the editor — set the drag margins to be asymmetrical, turn on drawing the drag margins, and slide the offsets from -1 to 1 and back. The horizontal offset moves the camera's center between the left and right margins, but the vertical offset gets them backwards and will move the camera outside the margins entirely.
(cherry picked from commit 40816574ac)
