• Godot Help

  • How to choose the proper Node for my entities?

Telokis The nodes you mention fall into different categories:

  • RigidBody2D, StaticBody2D, AnimatiableBody2D - are all rigid bodies. (aka dynamic bodies). They are supposed to be animated by engine's physics simulation. You typically don't animate their motion (position/velocity) directly. Instead, you apply directional and rotational forces (hence "dynamic") to affect the simulation. Static and animatable bodies are just special cases of the rigid body that have some performance optimizations. They are typically used when a full fledged rigid body is not needed (e.g. static body is used for obstacles that never move or a terrain).

  • CharacterBody2D - is a kinematic body. Its motion is supposed to be animated by your scripts. You can directly manipulate its position/velocity although the engine can help you there by doing some common kinematic gruntwork.

  • Area2D - is just a passive collider. A geometric shape that can detect if other geometric shapes overlap with it.

      xyz Hello and thanks for the reply!

      So in the case of something like a Pong clone, it could make sense to use CharacterBody2D for the paddles AND for the ball if I want to precisely define the interactions myself?

      • xyz replied to this.

          Telokis For a Pong clone it'd best to start by using a character body for everything that moves. After all that's how the original Pong was made. They certainly didn't have the luxury of running rigid body simulations on 1970s hardware 🙂.

            xyz

            xyz Area2D - is a collider. It is used by all above mentioned bodies to define their (collision) shape.

            A collision shape is used to define the collision shape of those bodies. Even area2d needs one. Or not?
            EDIT: You are talking about classes and not node names?

            • xyz replied to this.

                  trizZzle Sorry, had a brain fart. To much C++ coding lately. Corrected.
                  Yes, all those nodes need a CollisionShape2D or CollisionPolygon2D node as a child to define their shape.

                    xyz RigidBody2D, StaticBody2D, AnimatiableBody2D - are all rigid bodies

                    no. a static is a static, it should never move, it can cause problems.
                    an animatable is a middle point between a static and the others and can be animated, but it should not be moved by code.
                    rigid bodies are rigid bodies, they are modern advanced physics bodies. back in the day all we had was dynamics, which were more stiff.

                    xyz CharacterBody2D - is a kinematic body. Its motion is supposed to be animated by your scripts. You can directly manipulate its position/velocity although the engine can help you there by doing some common kinematic gruntwork.

                    character body can affect rigid bodies and collide with statics, that is the main thing, collisions. if you don't need collisions you can just use move any 2D node with code.

                    xyz Area2D - is just a passive collider. A geometric shape that can detect if other geometric shapes overlap with it.

                    think of the others as colliding on the edges (2D)/surface (3D) while an area can detect when something is inside it.

                    • xyz replied to this.

                            Jesusemora What are you on about here? What's your point?

                            The static body is a special case of the generalized rigid body. The simulation runs all bodies inside a particular physics space at once and static rigid bodies participate in exactly the same way as movable rigid bodies do, they just don't move. You can think of them as rigid bodies that have infinite mass. On account of that, their performance cost can be significantly lowered. That's pretty much the only reason they exist as a separate rigid body type. Animatable bodies are just static bodies that allow for arbitrary placement during simulation.

                            I never said that kinematic and rigid bodies cannot interact. That was not the topic at all here.

                            There are two parts to every collision: detection and response. Detection algorithms are the same for all objects that inherit CollisionObjectXD, be it areas, kinematic or rigid bodies. However the response is different for different types of bodies. Should you choose to disable the response for a body of any type, it can be made to behave just like a plain area - doing only the detection (e.g. via PhysicsDirectSpaceStateXD::intersect_shape())

                                xyz a static body and a rigid body are very different, and I wouldn't put them in the same group.

                                a rigid body ALWAYS looks like this:

                                rigid_body
|-> collider
|-> Sprite2D/meshinstance3D

                                but a static can look like this:

                                StaticBody
|-> collider
|-> collider
|-> collider
|-> collider
|-> collider
|-> collider
Node3D
|-> meshinstance3D
|-> meshinstance3D
|-> meshinstance3D

                                this is because static should never move, so it can be handled separate from the visual part and optimized.
                                using a static like a rigid body is a waste of nodes and can lead to problems.

                                rigid body will also reset it's size if scaled, while a static body will work, but could lead to problems in the future.

                                xyz I never said that kinematic and rigid bodies cannot interact. That was not the topic at all here.

                                it is the use that's important here, characterbody can be moved by code, any node can be moved by code, but rigid body cannot, it will cause problems, so you have to call integrate forces and a lot of other stuff.

                                • xyz replied to this.

                                      Jesusemora a static body and a rigid body are very different, and I wouldn't put them in the same group.

                                      a rigid body ALWAYS looks like this:

                                      The math doesn't care about how you think stuff should be grouped. I'm telling you how it is.

                                      To get some perspective, let's for example take a look at Bullet's source. Here's its class hierarchy for collision bodies. The only thing that distinguishes a static from a movable rigid body is the CF_STATIC_OBJECT flag in the btCollisionObject base class. For all intents and purposes from the engine's perspective, they are one and the same, represented by the same class btRigidBody. They just differ in collision response (and optimization opportunities) based on the value of this flag.

                                      Shall we peek into Godot's source as well? Needles to say, we'll see the same thing. Both static and movable rigid bodies are represented by the same class GodotBodyXD. If we look into class definition in godot_body_2d.h we can see there's mode property that can have values PhysicsServer2D::BODY_MODE_RIGID or PhysicsServer2D::BODY_MODE_STATIC, and some other values as well but that's beside the point. Ditto for its 3d counterpart. So again, from engine's (and simulation math) perspective, those bodies are the same type of thing.

                                          xyz well if you want to get technical, yes.
                                          but from a practical standpoint all of this knowledge is useless and only serves to create more confusion when actually working on a game.

                                          xyz The math doesn't care about how you think stuff should be grouped. I'm telling you how it is.

                                          yah yah there's the same number of atoms in a person and a rock of the same weight. you want to get into philosophy too?

                                          it doesn't matter how the code does what it does, not to someone on the "gdscript layer". we have a number of rules to follow, there's not that many, and that's it.
                                          a static should not move.
                                          a rigid body should not be resized or moved by code.
                                          a kinematic can be moved by code.
                                          and if you don't need to affect other physics objects you use an area
                                          and if you don't need physics you can use any other node with transforms.

                                          the engine calls them all bodies, not "rigid" bodies, there's a rigid body class and a static body class and they are different classes from each other, they inherit from PhysicsBody, not each other.

                                          • xyz replied to this.

                                                Jesusemora I can't respond to your incoherent walls of text. If you think something specific I said is incorrect, quote that and say why it's incorrect. I can respond to that.

                                                There's no rigid body or static body or kinematic body native classes in engine source. There's only one class (i.e. GodotBodyXD) that implements the full dynamic rigid body functionality. This class does the work underneath all various "body" node classes. Its functionality is just altered via flags to meet the needs of different nodes. Strictly speaking it's all rigid body simulation but for some "types of bodies" some functionality aspects are constrained or disabled. It's exactly how it works in Bullet as well.

                                                Static body is a rigid body that doesn't move. And kinematic body is a rigid body that's not affected by forces. The only defining characteristic of a rigid body in classical physics is non-deformability (aka rigidity). A rigid body doesn't cease to be a rigid body just because you constrained it in one way or another during a simulation.

                                                By your logic, I could now write an extension node using GodotBody2D that represents a perpetually rotating, pin constrained rigid body, call it RotatingBody2D and you'd say it's not a rigid body because it's called rotating body. Come on!