Physics Process, Delta Time
Raycast
-
Can be done using the Raycast Node or via
.intersect_rayof the 'PhysicsServer' / 'PhysicsDirectSpaceState2D'. -
Calculations are only performed inside the 'physical frame', so use the
_physics_process()function to access their information. -
Raycast: Using Raycast via the PhysicsDirectSpaceState .
var space_state : PhysicsDirectSpaceState2D = get_world_2d().get_direct_space_state() var query := PhysicsRayQueryParameters2D.create(Vector2(), Vector2(), masks)
Raycast: Climbing Stairs in a 2D Platformer .
Area2D
-
Layer :
-
"Which shirts the node wears".
-
In other words, the Area uses this if it needs to be "seen" by another Area.
-
-
Mask :
-
"Which shirts the node sees".
-
In other words, the Area uses this to identify which Areas it wants to "see".
-
-
Monitoring :
-
Roughly: If set to 'true', it will allow boolean 'true' Masks to be activated. If set to 'false', it will disable all the node's Masks.
-
-
Monitorable :
-
Roughly: If set to 'true', it will allow boolean 'true' Layers to be activated. If set to 'false', it will disable all the node's Layers.
-
-
Example: If Area_A and Area_B are intersecting while both areas are listening for entry and exit signals from the other area:
-
If Area_A quickly toggles its 'Layer':
-
Perception of Area_A: It will not perceive anything.
-
Perception of Area_B: It will stop detecting Area_A and then detect Area_A again. In other words, it will interpret it as an "enter" and "exit" of Area_A.
-
-
If Area_A quickly toggles its 'Mask':
-
Perception of Area_A: It will stop detecting Area_B and then detect Area_B again. In other words, it will interpret it as an "enter" and "exit" of Area_B.
-
Perception of Area_B: It will not perceive anything.
-
-
If Area_A quickly toggles 'Monitoring':
-
Perception of Area_A: It will stop detecting Area_B and then detect Area_B again. In other words, it will interpret it as an "enter" and "exit" of Area_B.
-
Perception of Area_B: It will stop detecting Area_A and then detect Area_A again. In other words, it will interpret it as an "enter" and "exit" of Area_A.
-
-
If Area_A quickly toggles 'Monitorable':
-
Perception of Area_A: It will not perceive anything.
-
Perception of Area_B: It will not perceive anything.
-
-
If Area_B quickly toggles its 'Layer':
-
Perception of Area_A: It will stop detecting Area_B and then detect Area_B again. In other words, it will interpret it as an "enter" and "exit" of Area_B.
-
Perception of Area_B: It will not perceive anything.
-
-
If Area_B quickly toggles its 'Mask':
-
Perception of Area_A: It will not perceive anything.
-
Perception of Area_B: It will stop detecting Area_A and then detect Area_A again. In other words, it will interpret it as an "enter" and "exit" of Area_A.
-
-
If Area_B quickly toggles 'Monitoring':
-
Perception of Area_A: It will stop detecting Area_B and then detect Area_B again. In other words, it will interpret it as an "enter" and "exit" of Area_B.
-
Perception of Area_B: It will stop detecting Area_A and then detect Area_A again. In other words, it will interpret it as an "enter" and "exit" of Area_A.
-
-
If Area_B quickly toggles 'Monitorable':
-
Perception of Area_A: It will not perceive anything.
-
Perception of Area_B: It will not perceive anything.
-
-
-
'area_shape' and 'body_shape' signals:
-
These signals are useful in cases where the Area2D has multiple collision shapes, for example an enemy with many contact points spread across its body.
-
These signals will return: the RID (Resource ID), the Area2D itself, 'area_shape_index' and 'local_shape_index'. All this information is used to better detect which shape was collided within the Area2D.
-
Skeleton, Bones, Joints
-
Using Skeleton2D with Polygon2D to create deformations in sprites .
-
Creating a Rig without Skeleton2D or Bone2D, only using the Create Bone option of Sprite2D.-
It is a very strange technique.
-
I much prefer using Skeleton2D and Polygon2D, because it is much more visual.
-
Apparently it supports IK, but that seems very odd to me. I did not like the technique.
-
-
Using a 'Bone' as Root Motion to create a more realistic "physical" animation .
-
The video is absolutely longer than it should be. For most of the time he is doing things unrelated to the topic, like creating character controllers and camera controllers.
-
From what was shown in the video, a character's walk speed can be "synchronized" with the walking animation, giving the impression of a more realistic / physical animation.
-
This should be set first in Blender, perhaps using an addon that creates a useful Bone to be used as root motion.
-
Apparently, setting up a 'root bone' in Blender is important so the character does not become 'wabbly' inside Godot.
-
IK
-
Forward Kinematics and Inverse Kinematics in 2D .
-
[Godot 4.3] IK is inside Skeleton2D, in the Modifications section.
-
-
Improving Inverse Kinematics using the 'Souperior Skeleton Modifications' addon .
-
Motivation for using the addon:
-
When flipping the character using Skeleton2D's Skeleton Modifications, the constraints did not respect that flip and produced an undesired result.
-
IK for "UpperBody" and "LowerBody" in a more simplified way.
-
-
{0:58 -> 8:50}
-
Conversion from the previous method to the new method is done, only to solve the IK problems when flipping the character.
-
-
{13:20 -> 14:40}
-
Demonstration of the character flip after the change.
-
-
The rest of the video is skippable.
-
SpringArm
-
Moves all child Nodes into the region corresponding to the SpringArm, regardless of where they are. One way to imagine the SpringArm is as a "train track", where its children are the "trains" and they can only move along the track. The advantage of the SpringArm is collision detection with the node's Shape, so it adapts to collisions and moves all its children "forward" from the collision, i.e., moves them closer to the SpringArm origin.
-
About the Shape: I don't know how it works, because the Shape is not visible to me.
-