In the 3D version:
- Partially revert #20908 that was reverted in the 2D version as part
of #21653. This ensures that the Vector returned is always perpendicular
to the surface collided with; and not the floor_normal Vector passed to
the function when on a floor.
- Include an update of the floor velocity before multiplying by the time
delta, which was added to the 2D version as part of commit 13a8014.
In the 2D version:
- Use the Vector2.slide() function instead of Vector2.tangent() to adjust
the amount of motion the stop_on_slope undoes to ensure that it is in the
right direction. This is a implementation of the 3D approach from #30588.
- Combine the !found_collision and motion == Vector2() checks for break.
- Other minor formating changes to make the functions look identical.
Also renamed some variables to align with their use.
It was triggering a warning in bullet followed with a crash in some cases.
WARNING: assert_no_constraints: A body with a joints is destroyed. Please check the implementation in order to destroy the joint before the body.
At: modules/bullet/rigid_body_bullet.cpp:465
A z_depth of 0 returns the camera position, which is not really useful.
This also makes the API breakage from 3.1 clearer as 3.1 code will now
fail to compile, so users will have to adapt and use the new parameter.
For the reference, in 3.1, the z_depth was hardcoded to the near plane.
Closes#33493.
Make sure particles are processed during the same frame when visibility is set to on, in case they are still active from before and need to be restarted.
Fixed#33476
Particles were processed only on the next frame after the emission started, causing a one frame delay in rendering. Now the first process cycle is started during the same frame, which makes them consistent with Particles & Particles2D.
Fixes#32890
Adds a new NavigationMesh property to select which objects will be taken
into account for the generation.
By default it will use all the NavigationMeshInstance children to keep
compatibility. The new modes allow to build the NavigationMesh from
all the nodes belonging to a specific group, and optionally include
their children too.
When moving KinematicBody2D from one scene to another and not freeing
the old scene, the first call to move_and_slide() in the new scene will
generate an error because KinematicBody2D keeps internaly a
RID on_floor_body of a body resource in the old scene which no more has
a space assigned.
To fix this, on_floor_body is set to empty RID in response to
NOTIFICATION_ENTER_TREE notification of KinematicBody2D and
KinematicBody. Also all other data related to move_and_slide() is reset:
floor, ceiling, wall flags, colliders vector, floor_velocity.
This fixes#31416.
This was a regression in 3.1 and later from the new inspector, where
PROPERTY_HINT_SPRITE_FRAME was not fully re-implemented. It's meant to
be a normal PROPERTY_HINT_RANGE which also automatically increments its
value when keyed in the animation player.
To avoid code duplication, I made the frames properties use the actual
PROPERTY_HINT_RANGE and introduced a PROPERTY_USAGE_KEYING_INCREMENTS
usage flag instead.
Also added support for SCons project-absolute paths (starting with #) and
warning about duplicates in add_source_files(), and fixed
default_controller_mappings.gen.cpp being included twice after first build
due to *.cpp globbing.
Part of #30270.
With the default camera node settings, this makes directional shadows
look consistent between the editor and the running project.
The original issue occurs because the editor camera defaults to a
Z-far value of 500, whereas the Camera node defaults to a Z-far
value of 100. Since the directional shadow maximum distance is clamped
to the Z-far value, it caused the running project's effective shadow
distance to be lower compared to the editor (100 instead of 200).
This partially addresses #13575.
- Refer to properties explicitly when possible
- When multiple warnings are returned, always separate them by one
blank line to make them easier to distinguish
- Improve grammar and formatting
For clarity, assign-to-release idiom for PoolVector::Read/Write
replaced with a function call.
Existing uses replaced (or removed if already handled by scope)
The original shader code uses a phase (ratio from 0 to 1 for the particle
lifetime) for the randomness ratio computations, and this code was ported
over but converted to time computations.
The seeding/cycle logic was thus invalid, so we're going back to phase
for these computations, thus fixing the previous non-working time/emission
randomness property.
Part of #29692. Follow-up to #26859.
The tangential acceleration for both CPUParticles2D and CPUParticles had been
badly converted from their GPU counterpart (ParticlesMaterial).
This fixes it and ensures that both GPU and CPU particles behave the same with
regard to tangential acceleration.
It's not necessary, but the vast majority of calls of error macros
do have an ending semicolon, so it's best to be consistent.
Most WARN_DEPRECATED calls did *not* have a semicolon, but there's
no reason for them to be treated differently.
As mentioned in
https://github.com/godotengine/godot/pull/26897#issuecomment-491178089
the look-at scaling issue solved by PR #26897 happens also in another
look-at method.
Spatial::look_at_from_position() also does not have same input checking
Spatial::look_at() has. Therefore, I fixed it too at same time.
* Expose EditorNavigationMeshGenerator as an engine singleton so users
can generate navmesehes from `tool` scripts.
* Add support for generating navmeshes from static colliders. All
collision shapes are supported except for Plane (since Plane is an
infinite collider and navmeshes need to have finite geometry).
* When using static colliders as a geometry source, a layer mask can be
specified to ignore certain colliders.
* Don't rely on global transform. It still should give the exact same
results but allows for building navmeshes on nodes that are not in the
tree (useful in `tool` scripts).
* Update navigation gizmos after every new bake.
This work has been kindly sponsored by IMVU.
It always normalized basis after look_at() computation.
Now it applies previous scale back, in order to avoid
distortions when global scale was different of (1,1,1).
fix#10003 and #19000
Related to #17924
Adds the ability to directly add disabled shapes to a collision object. Before this commit a shape has always been assumed to be enabled and had to be disabled in an extra step.
The bake mode property of lights previously didn't affect GI probes.
This change makes the GI probe ignore lights that have their bake mode
set to disabled.
Made AudioFrame and Vector2 equivalent for casting.
Added ability to obtain the playback object from stream players.
Added ability to obtain effect instance from audio server.
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).
FBX support and MMD (pmx) support.
Normals, Albedo, Metallic, and Roughness through Arnold 5 Materials for Maya FBX.
Maya FBX Stingray PBS support.
Importing FBX static meshes work.
Importing FBX animations is a work in progress.
Supports FBX 4 bone influence animations.
Supports FBX blend shapes.
MMDs do not have an associated animation import yet.
Sponsored by IMVU Inc.
Adds `FALLTHROUGH` macro to specify when a fallthrough is intentional.
Can be replaced by `[[fallthrough]]` if/when we switch to C++17.
The warning is now enabled by default for GCC on `extra` warnings level
(part of GCC's `-Wextra`). It's not enabled in Clang's `-Wextra` yet,
but we could enable it manually once we switch to C++11. There's no
equivalent feature in MSVC for now.
Fixes#26135.
1. Consider 'own_world' as well as 'world' to stop propagating enter/exit world notifications.
2. Clean & fix handling of camera currency.
This fixes some random crashes and error logs in the editor; namely
- when enabling/disabling own world in a Viewport;
- when switching back from a subscene displayed into a main scene's Viewport;
- when exiting the editor after any of them;
- memory corruption (can that explain certain other seemingly unrelated crash reports?).
This also fixes situations where a Viewport and its main Camera get out of sync about which World is relevant to them.
With this change finally one can use compound collisions (like those created
by Gridmaps) without serious performance issues. The previous KinematicBody
code for Bullet was practically doing a whole bunch of unnecessary
calculations. Gridmaps with fairly large octant sizes (in my case 32) can get
up to 10000x speedup with this change (literally!). I expect the FPS demo to
get a fair speedup as well.
List of fixes and improvements:
- Fixed a general bug in move_and_slide that affects both GodotPhysics and
Bullet, where ray shapes would be ignored unless the stop_on_slope parameter
is disabled. Not sure where that came from, but looking at the 2D physics
code it was obvious there's a difference.
- Enabled the dynamic AABB tree that Bullet uses to allow broadphase collision
tests against individual shapes of compound shapes. This is crucial to get
good performance with Gridmaps and in general improves the performance
whenever a KinematicBody collides with compound collision shapes.
- Added code to the broadphase collision detection code used by the Bullet
module for KinematicBodies to also do broadphase on the sub-shapes of
compound collision shapes. This is possible thanks to the dynamic AABB
tree that was previously disabled and it's the change that provides the
biggest performance boost.
- Now broadphase test is only done once per KinematicBody in Bullet instead of
once per each of its shapes which was completely unnecessary.
- Fixed the way how the ray separation results are populated in Bullet which
was completely broken previously, overwriting previous results and similar
non-sense.
- Fixed ray shapes for good now. Previously the margin set in the editor was
not respected at all, and the KinematicBody code for ray separation was
complete bogus, thus all previous attempts to fix it were mislead.
- Fixed an obvious bug also in GodotPhysics where an out-of-bounds index was
used in the ray result array.
There are a whole set of other problems with the KinematicBody code of Bullet
which cost performance and may cause unexpected behavior, but those are not
addressed in this change (need to keep it "simple").
Not sure whether this fixes any outstanding Github issues but I wouldn't be
surprised.