Make physics nodes easier to understand

[pouleyKetchoupp]

Describe the project you are working on

Godot Engine

Describe the problem or limitation you are having in your project

Current state: After #2184 (physics nodes reorganization) has been implemented, each physics node consistently takes care of a specific game use case, or a group of related game use cases, which is a big step in the right direction.

Problem: As a consequence though, some physics node names are confusing and their name could reflect their general usage better, as most nodes do.

Examples: Some physics nodes have names that describe their functionality very well, like CharacterBody (the new node that replaces KinematicBody for character specific features), VehicleBody (obviously specialized in vehicles) or SoftBody (generic node for soft physics used for clothes and soft volumes).

On the other hand, some names are less clear.

For example, StaticBody can not only be used for actual static bodies (walls, floors), but also moving platforms. It makes sense to group these functionalities together, but the name can be misleading, especially for beginners. Basically, StaticBody has two modes of functioning: Static and Kinematic (more details about body modes below).

Another example is RigidBody, which follows a usual convention from physics engines, but can be misleading for users not familiar with these terms. Rigid can be interpreted as something fixed, while this node is meant to be used for any general physics object (with a specified body mode, see more details below).

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This proposal is about harmonizing the way physics nodes are named, by giving them names that describe their game functionality rather than their state in the physics engine, by following two simple rules:

1. Physics nodes are named after their use case

Change physics node naming to be based on use cases, while physics modes are based on behavior within the physics engine.

2. Body modes are not used for naming physics nodes

The physics engine uses body modes internally (Static, Dynamic, Kinematic, DynamicLocked - previously Character). These modes shouldn't be used to name physics nodes, because different nodes can use the same body modes, and the same physics node can switch between different body modes.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Name proposals: I will post specific suggestions to rename some of them in the comment section. If anybody wants to propose different names, you can add them in separate comments as well, after reading the details below for context.

Note: This proposal is about naming physics nodes. Discussions about the way functionalities are split between nodes, or comments about adding new nodes will be considered off-topic.

---

Body modes

These names would be reserved for internal modes in the physics engine, that way none of the node names can be mistaken for one of the body modes.

Here's the definition of the different body modes, used inside of the physics engine for different nodes: Static means the object can't be physically pushed by other objects. Kinematic can't be pushed by other objects and also moves following a predefined motion. Dynamic means the object is fully simulated with applied forces and can be pushed around. DynamicLocked same as Dynamic but can't rotate.

---

Current physics node names

Here's the list of all physics nodes, with their current name, usage and corresponding body modes. Note discrepancies between some of the node names and their possible modes.

-StaticBody Use cases: Commonly used for floor, walls, platforms and moving platforms. Modes: Static, Kinematic.

-RigidBody Use cases: Standard usage for anything that is physically simulated or can switch modes, and uses solid shapes. Modes: Static, Kinematic, Dynamic, DynamicLocked

-CharacterBody Use cases: Used specifically for character controllers. Mode: Kinematic

-VehicleBody Use cases: Used specifically for vehicles. Mode: Static, Kinematic, Dynamic, DynamicLocked

-PhysicalBone Use cases: Ragdoll parts attached to skeleton bones. Mode: Static, Kinematic, Dynamic, DynamicLocked

-SoftBody Use cases: Standard usage for anything that uses soft physics (clothes or soft volumes). Modes: n/a (different type of physics simulation)

If this enhancement will not be used often, can it be worked around with a few lines of script?

Node names are set in the core engine.

Is there a reason why this should be core and not an add-on in the asset library?

Physics nodes are already part of the core engine.

[golddotasksquestions]

@theraot @pouleyKetchoupp

The nodes in Godot 4.0 would be: ColliderBody, CharacterBody. RigidBody, SoftBody, VehicleBody and PhysicalBone.

To reiterate, the ColliderBody isn't exactly an old school StaticBody, because it can move. If nobody thinks of using CharacterBody for moving platforms, that is good. They should be looking for ColliderBody.

---

RigidBody will keep the same name, as a majority is more familiar with this term, and it's fairly easy for complete beginners to learn what it means.

If anything should change, it would be StaticBody renamed to ColliderBody (based on #2867 (comment)) which seems to be the closest to a consensus and addresses the confusion around StaticBody being used for moving platforms. It would still use a well-established term.

Other physics nodes can stay the same because their use case is clear and there's no name confusion.

@pouleyKetchoupp : I interpreted your last statement as such that we will keep the "KinematicBody" name for the node, not the CharacterBody. Can you clearify?

[theraot]

@golddotasksquestions I'll explain how I interpreted it. And I'll repeat myself.

When @pouleyKetchoupp said that the other nodes stays the same, I understand it as the same as it is currently in the code base. So, I interpreted that the name CharacterBody stays, because that is the is the it currently has in the code base: https://github.com/godotengine/godot/pull/48908 (which I had linked previously) - See also #2184. That proposal is closed, because those changes are already done.

I've been saying and repeating that the name KinematicBody is available, and that what Godot 4.0 calls StaticBody can move, because those changes are already done, and I wanted - and apparently failed - to bring attention to that.

---

When I posted this:

                                                 StaticBody    RigidBody    CharacterBody    SoftBody
Physics
├ Solid
│ ├ Static ·················· Static mode             x            x
│ ├ Kinematic ··············· Kinematic mode          x            x              x
│ └ Dynamic
│    ├ Rigid
│    │ ├ With rotation  ····· Dynamic mode                         x
│    │ └ Without rotation ··· DynamicLocked mode                   x
│    └ Soft ················· (not a mode)                                                       x
└ Fluid ····················· N/A

It wasn't a suggestion. This is the given. This is what is in the code base. It matches what OP says under "Current physics node names". I hoped my presentation above was more digestible.

---

I suppose it is possible pouleyKetchoupp meant to say they will stay the same as in Godot 3.x. Except that would mean there would be a KinematicBody and a kinematic mode, and I believe the proposal intends to avoid using the same word to refer to two different things (a node and a mode). Futhermore, I would expect that expressed as "reverted to what they were in Godot 3.x", not as "stays the same".

[pouleyKetchoupp]

I interpreted your last statement as such that we will keep the "KinematicBody" name for the node, not the CharacterBody. Can you clearify?

The name CharacterBody will stay, not KinematicBody which was removed with #2184.

[charlesmlamb]

I'd suggest something like, EntityBody, or AgentBody . . as ideas, for CharacterBody ( former, KinematicBody ) . .

[JamesC01]

I'd suggest something like, EntityBody, or AgentBody . . as ideas, for CharacterBody ( former, KinematicBody ) . .

Agent typically refers to AI, and Entity can refer to many things, not just characters. Characterbody is the most clear name. You shouldn't really use it for anything other than characters (player, enemies etc.)

[theraot]

@charlesmlamb,

What do you understand by character? From your other posts I get some sense that it is about being humanoid or about talking. And I think the name bothers you.

I remind you that at the end, the name of the node does not change the experience you create in your game.

Yet, I'll oblige. I submit to your consideration: Toothless from How to Train Your Dragon. Toothless does not speak, and is not humanoid. Is Toothless a character? I think it is a character.

Anyway, I agree there could be a better name. Yet there are objections to every name, and I'm out of ideas.

[vesk4000]

@pouleyKetchoupp I know that this is not what this proposal is about and it has already been decided that way, but... Why is there a StaticBody (or whatever it is going to be called) in the first place. From what I understand it is just a RigidBody, but with only Static and Kinematic modes. Maybe there are some other functions that StaticBody provides, but in general what is the purpose of having this node. Couldn't people just use a RigidBody with Static or Kinematic mode and achieve the exact same thing just as easily. I'm sorry if I have missed something, but when I think about it doesn't really make much sense to me.

[LillyByte]

I read all these suggestions, and I really fail to see how "less confusing" these renames will be, or any of the follow-up suggestions. If your outcome is to make things easier to understand... you're really not doing it, by any measure of success with this proposal, on top of adding additional nodes.

And Dynamic and DynamicLocked to lock rotation? How about instead of adding extra physics bodies to already confusing and growing list... just add properties on RigidBodies to lock the various axis in whatever rotation/position we desire, something that's been weirdly missing in Godot from the getgo. I assure you that will be a thousand times more useful in many more situations than adding additional, confusing node names.

[JamesC01]

I read all these suggestions, and I really fail to see how "less confusing" these renames will be, or any of the follow-up suggestions. If your outcome is to make things easier to understand... you're really not doing it, by any measure of success with this proposal, on top of adding additional nodes.

And Dynamic and DynamicLocked to lock rotation? How about instead of adding extra physics bodies to already confusing and growing list... just add properties on RigidBodies to lock the various axis in whatever rotation/position we desire, something that's been weirdly missing in Godot from the getgo. I assure you that will be a thousand times more useful in many more situations than adding additional, confusing node names.

There already are Axis Lock properties in the current version of godot. Dynamic and DynamicLocked are just name of the modes used in the underlying code, I believe, they aren't new nodes. I think the names ColliderBody, RigidBody, CharacterBody are all good. They describe each decently. Godot's kinematicbody was already incredibly similar to Unity's CharacterController component, so it make sense to make it specifically a CharacterBody, and if you want a simple physics collider, like a moving platform, or a wall, colliderbody can be used. It's not the best name, but it seems like the closest.

[theraot]

@LillyByte

Dynamic and DynamicLocked are not nodes. They are modes. RidigBody now has a new property called Mode, that can take those values.

Also, as JamesC01 points out. Godot's RigidBody already has a series of properties under the Axis Lock category. So you can lock rotation (axis_lock_angular_x, axis_lock_angular_y, axis_lock_angular_z) or translation (axis_lock_linear_x, axis_lock_linear_y, axis_lock_linear_z).

---

Edit:

I don't think any suggestion of additional nodes is going to happen.

This is the old list, as per Godot 3.x:

1. StaticBody
2. KinematicBody
3. RigidBody
4. PhysicalBone
5. SoftBody
6. VehicleBody

This is the list currently in the code base, as per #2184 and https://github.com/godotengine/godot/pull/48908:

1. StaticBody (note: kinematic mode added)
2. CharacterBody
3. RigidBody
4. PhysicalBone
5. SoftBody
6. VehicleBody

This is the new list as per https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-866372871 :

1. ColliderBody
2. CharacterBody
3. RigidBody
4. PhysicalBone
5. SoftBody
6. VehicleBody

[LillyByte]

@LillyByte

Dynamic and DynamicLocked are not nodes. They are modes. RidigBody is now has a new property called Mode, that can take those values.

Also, as JamesC01 points out. Godot's RigidBody already has a series of properties under the Axis Lock category. So you can lock rotation (axis_lock_angular_x, axis_lock_angular_y, axis_lock_angular_z) or translation (axis_lock_linear_x, axis_lock_linear_y, axis_lock_linear_z).

I concede that. I haven't used 3D nodes enough to notice the lock because I have issues with 3D to start with due to all the issues I have with 3D in and of itself. However, this lock does not exist in 2D-- so, I made the assumption it doesn't exist in 3D either. For once, the lack of consistency is a good thing.

So, why do modes exist then if we can already lock orientation? Isn't that just doubling up a feature, creating redundancy and bloat for no reason?

Edit: Also... ColliderBody, CharacterBody, and RididBody... EVERY physics body is a "collider body". There's not enough facepalm in the world for this.

[theraot]

@LillyByte

Yeah, there is disparity between 2D and 3D. I'll add the fact that RigidBody2D does not have a axis lock properties to the mental pile (which I'm not listing here). And now that I double checked, the modes aren't exactly new either. I had shoved the fact that I can change the mode of RigidBody to the depth of my mind because it never made sense to me when I would want to do that. After a while it became selective blindness.

However, there you go: Set your RigidBody2D Mode to Character, and it has locked rotation. After writing that statement it is hard to deny that renaming is a good idea. Why would you set a RigidBody to Character mode to lock rotation?

[LillyByte]

However, there you go: Set your RigidBody2D Mode to Character, and it has locked rotation. After writing that statement it is hard to deny that renaming is a good idea. Why would you set a RigidBody to Character mode to lock rotation?

Yeah, this is the kind of thing that baffles me.

The other thing is, I've always assumed in Godot, like other engines, that Static bodies were a low-performance physics bodies with minimum code/functions that helps improve the performance of the physics engine.... because you have to use so many of them. I don't think this is the case in Godot... yet, somehow, doesn't surprise me. If we have no low performance physics bodies... I feel we have a bit of a problem.

I need to stop assuming things when it comes to Godot; because in the choice between performance versus understandability, I should just recognize that Godot jumps off the cliff, has tea with crickets, and yells at clouds.

[theraot]

@LillyByte Godot follows a "The problem always comes first" approach. This is how it plays out in my mind:

Some people want to use a RigidBody to make a character, so they can have physics gravity instead of simulating it with their own code, and they can use forces and impulses to move it. But the RigidBody falls down, and then it continues to move while laying down. That is a problem. We need a solution for the problem. Don't make a generic and flexible solution - says contribution guidelines. Instead a dedicated solution. We just need a switch that changes RigidBody behavior for this particular case. What is it for? A yes, a character. Let us call it character mode, so that everybody who wants to use RigidBody to make characters can find it. Et viola.

I think you can imagine how this approach can lead to some features added to 2D without a 3D counterpart or viceversa. And also how it can lead to some very similar features co-existing, because they address different problems. And how the names can be less than descriptive.

This approach has its advantages, mind you. It avoids premature optimization. It avoids premature abstraction. So it does not lead to over-engineering. Which is good to keep the engine small. It lets the engine grow organically. I think there is the issue. It has been growing into a mess. Godot needs a big refactor, the willingness to break compatibility, and a clear direction. Wait, that is Godot 4.0. It is going to fine, eventually, with good effort.

[LillyByte]

@LillyByte Godot follows a "The problem always comes first" approach. This is how it plays out in my mind:

Some people want to use a RigidBody to make a character, so they can have physics gravity instead of simulating it with their own code,

What you just described is the foundation of a Kinematic Body -- which is the complete opposite behaviour to a RigidBody.

Instead of splitting these into their own types (as they should be); we're forcing one body to share frameworks of both types?

[theraot]

@LillyByte Sorry, I don't understand.

Yet, I guess I was little too reductionist.

If I want a character that can be pushed around, slides down slopes, and falls under gravity. Why should I implement all that on a KinematicBody when the engines has a RigidBody and I can add scripts to it? Well, because lacks rotation locking?

Perhaps I should not write that in first person. I have no intention to suggest that RigidBody is the way to go for everybody. When I was new to Godot, I tried using a RigidBody for a player character, and it was too much trouble to fight the game engine when both my script and the physics engine wants to move the physics body (now I know I could have solved it by working with _integrate_forces).

So, OK, let us use KinematicBody instead. I can re-implement gravity for my kinematic body, this is standard practice at this point. I can have it slide down slopes. I can even have it bounce. And - with much effort - I can make it so other things can push it. Is this what you recommend people always do? Or is there a point at which you would say it makes sense to base a player character on RigidBody?

Regardless, people implement player character with RigidBody. There is even an official demos that does it: https://github.com/godotengine/godot-demo-projects/tree/master/2d/physics_platformer - Even if you go to other engines, people do it. There are plenty of examples of RigidBody based player character for Unity, and articles, tutorials and videos discuss RigidBody vs CharacterController.

To be clear, I'm not saying every game needs player character with all the features of a RigidBody. Now, for the games that need them. Does it make sense to have some way to lock rotation on a RigidBody to make the implementation of characters on top or RigidBody easier? Is it too much stretch of the imagination that such feature would be called "character mode"?

Edit: Again, to be clear, I'm not saying that character mode is a good name. I'm saying that I can imagine how it got that name, without it being malice.

[LillyByte]

In my experience with other people developing games, there are very few... and I mean... very few... who use RigidBody for character controllers.

Most of the people I interacte with use KinematicBody because using a RigidBody for a character controller is counter intuitive to controlled physics of characters. Those who I have seen use RigidBody for players are far and few between.

As for people who DO use RigidBody for character controllers (like myself, we a small minority of users).... but with that, as you said, we already have axis locking then. So, why would we need a character mode to lock the axis if we already have axis locking that does what character mode does? It's adding something for nothing you can already do.

But, that's not really my issue honestly, I don't care about that.

What I care about... is the renaming non-sense we have going on.

[golddotasksquestions]

What I care about... is the renaming non-sense we have going on.

If you start with behaviour non sense, you end up with naming non sense. It's therefore pointless to argue about names. A definitive decision to go with behaviour non sense has apparently already been made and is not discussed any longer. If the behaviour is convoluted and confusing, you can't make it magically clear and simple by giving it a certain name.

[LillyByte]

What I care about... is the renaming non-sense we have going on.

If you start with behaviour non sense, you end up with naming non sense. It's therefore pointless to argue about names. A definitive decision to go with behaviour non sense has already been made and is not discussed any longer. If the behaviour is convoluted and confusing, you can't make it magically clear and simple by giving it a certain name.

Then it makes way more sense to bring the behavior into what's expected of their name sakes; which are a standard expectation of engines, books, tutorials everywhere... rather than changing the names AND the behaviors into some monstorous cross-product.

[theraot]

This made me wonder what was added first, axis lock or modes.

The official documentation let me go as back as Godot 2.1 (https://docs.godotengine.org/en/2.1/classes/class_rigidbody.html).

And there is a very limited axis lock:

void set_axis_lock ( int axis_lock ) Set the axis lock of the body, from the AXISLOCK* enum. Axis lock stops the body from moving along the specified axis(X/Y/Z) and rotating along the other two axes.

And there are modes:

void set_mode ( int mode ) Set the body mode, from the MODE_* enum. This allows to change to a static body or a character body.

MODE_STATIC = 1 — Static mode. The body behaves like a StaticBody, and can only move by user code. MODE_KINEMATIC = 3 — Kinematic body. The body behaves like a KinematicBody, and can only move by user code. MODE_RIGID = 0 — Rigid body. This is the “natural” state of a rigid body. It is affected by forces, and can move, rotate, and be affected by user code. MODE_CHARACTER = 2 — Character body. This behaves like a rigid body, but can not rotate.

So... I don't know which was first. However, modes didn't change for Godot 3.0, but the axis lock did (it became six properties, which is more versatile).

[theraot]

@pouleyKetchoupp How about removing the DynamicLocked mode and add axis lock to RigidBody2D?

Experimenting with RigidBody with mode set to character vs axis_lock_angular_* in Godot 3.3.2, I fail to see why the mode is needed, other than the fact that RigidBody2D does not have axis lock.

[LillyByte]

I would say keep the axis locks, make them equivalent for 3D and 2D (able to lock any axis/rotation independently), and get rid of modes entirely, because modes are just a redundancy to that and adds a perceived complexity that isn't needed.

[charlesmlamb]

well, one could have an option, to set name conventions in project settings . . so, one could have the names be physics based or, 'game' based, like Characterbody . . imo, the current names are really confusing, if you find something better, I'll be using that . . until then, having a feature to call Kinematic or, Character-body might make sense . .

imo, names need to get better, not sure how, no matter what, gonna roll with Godot 4, thx . .

[theraot]

@LillyByte removing modes is harder than it seems.

Looking at the source. The physics nodes talk to the PhysicsServer to create a body, set its shape, and the mode (body_set_mode). And this is what matters for the physics simulation. The PhysicsServer does not know about nodes. The physics nodes are a way to create and manipulate the bodies in the PhysicsServer, with some extra things on top (notably move_and_slide).

Edit: I don't know where to look for the bullet physics integration (which I believe was removed for Godot 4.0), but I bet the PhysicsServer in Godot 3.x would create a different kind of bullet physics body depending on the mode.

[pouleyKetchoupp]

Here's the reason why both specialized physics nodes and RigidBody modes exist:

Modes in RigidBody node can be useful when a node needs to switch between different states at runtime. It can be useful for optimization, for things like breakable objects that start Static and can become Dynamic, or some other custom behaviors.

But these modes can't replace StaticBody (or ColliderBody) node which has built-in functionalities that can help with static and moving platforms:

• Constant velocity to create movement for touching bodies without actually moving (conveyor belts)
• Sync to physics to allow moving platforms to synchronize well with characters standing on top

If these functionalities were added to RigidBody, the API would be bloated and RigidBody would be more difficult to understand and harder to maintain, that's why a specialized node exists.

[golddotasksquestions]

• Constant velocity to create movement for touching bodies without actually moving (conveyor belts)
• Sync to physics to allow moving platforms to synchronize well with characters standing on top

Why are these functionalities not kept in the KinematicBody?

[pouleyKetchoupp]

@golddotasksquestions The first one was already in StaticBody and the second one was in KinematicBody, which doesn't exist anymore. So both functionalities are in StaticBody now, it's a node used for both static and moving platforms.

[just-georgeb]

@pouleyKetchoupp I think this is the real issue / main area for confusion with the naming - why is StaticBody now used for moving platforms? Why wouldn't you just leave the StaticBody node for static things and keep the KinematicBody node for moving things? Those names then both describe their use cases and are imo clearer than any of the alternatives suggested.

Also +1 for renaming the locked mode to DynamicLinear

[golddotasksquestions]

@pouleyKetchoupp I understood that much from the opening post in https://github.com/godotengine/godot-proposals/issues/2184

It also has been explained there and here many times by many people in many ways.

What I don't understand is the why. Why make things even more confusing than they already are instead of clearing up the thing that made them confusing in the first place? StaticBody conveyer belt and platform usecase could be removed and discurraged in the documentation (would only make it more intuitive to use), and without a moving StaticBody, there is no StaticBody platform and therefore no need to synchronize with a character on top more than they already are.

The intention of both this proposal as well as #2184 seem to be to make things less confusing and more clear for the user.

If another motivation behind it is to make something more specific for character behaviour then why not just make a separate CharacterBody node in addition to what we have now?

StaticBody could stay what is is minus what it should not be (moving): static and passive, definitely not moving, best for the performance of lot's of bodies that "do nothing" but sit statically like an immovable rock. Used for environment and obstacles that shall never ever move as much as the width of a hair.

KinematicBody could stay what is is and currently used for: For every moving object, simple player object controller, platforms, conveyor belts, simple bullets and projectiles, any character and non character type that needs to deterministically move and slide and collide without simulated physics)

RigidBody could stay what it is + get the move_and_collide (personally I would prefer to just be able to use all KinematicBody methods in KinematicBody mode, so we could finally have a Body that allows seamless transition from deterministic control to physics simulated control).

CharacterBody ... I honestly can't think of any thing that I would need in a character but not elsewhere. BonesPhysics? Ragdoll? Isn't this what RigidBodys modes are for? A working stop on slopes? I would definitely need this on simpler moving objects that are not characters at all too. I'm sure you and reduz have a good reason why you are proposing a CharacterBody, a reason that goes beyond my understanding, but I honestly don't see the need from a superficial behaviour perspective. Especially when the intention is to make things less confusing.

[pouleyKetchoupp]

@just-georgeb It would be too many nodes for similar functionalities:

StaticBody can already be moved by changing its transform, and it can make objects touching it to move using the constant velocity properties.

KinematicBody would be the same as StaticBody, only it could be moved and push other objects on the way, and it would have an extra sync to physics property for synchronizing with objects on top. It wouldn't have any of the character specific features, which are part of CharacterBody now.

That's why it makes sense to group these two nodes into one that's used for all platforms, under a name that makes it clear.

[theraot]

@golddotasksquestions

RigidBody could stay what it is + get the move_and_collide (personally I would prefer to just be able to use all KinematicBody methods in KinematicBody mode, so we could finally have a Body that allows seamless transition from deterministic control to physics simulated control).

RigidBody will have move_and_collide. It was moved to the base class. What RigidBody would be missing is move_and_slide.

They decided to move the parameters of move_and_slide to properties, so the method signature don't continue becoming complex.

---

@pouleyKetchoupp

Could those properties be a resource class instead? And then give it along with move_and_slide to the base class?

Edit: Actually, it sounds to me like trait or extension material.

[pouleyKetchoupp]

Could those properties be a resource class instead? And then give it along with move_and_slide to the base class?

Edit: Actually, it sounds to me like trait or extension material.

I would rather discuss that as a separate proposal if it's something that can be useful to you. It also needs more details about the use case / problem to address.

[Norrox]

I'm fine with how it is right now in the Master branch, but I feel the description need to be better, and maybe a "help" button that opens the correct side in the manual where you can read about the node you have selected?

[Calinou]

I'm fine with how it is right now in the Master branch, but I feel the description need to be better, and maybe a "help" button that opens the correct side in the manual where you can read about the node you have selected?

I'm not sure about adding a 3rd button to a ConfirmationDialog. While we do this in many places, I feel like this pattern isn't ideal since the "create" button isn't particularly highlighted (at least until we add a "primary" button stylebox override for such buttons.

That said, we can add this Help button elsewhere (e.g. in the corner of the description box).

See also https://github.com/godotengine/godot/pull/50505.

[vesk4000]

I'm fine with how it is right now in the Master branch, but I feel the description need to be better, and maybe a "help" button that opens the correct side in the manual where you can read about the node you have selected?

I'm not sure about the help button, but the nodes definitely need much better descriptions, at the moment, they practically don't have any.

[Calinou]

I'm not sure about the help button, but the nodes definitely need much better descriptions, at the moment, they practically don't have any.

Descriptions are sourced from the <brief_description> only from the class reference XML. The full <description> isn't featured as it's too long.

Feel free to open a pull request to improve brief descriptions, but keep in mind we expect them to be < 300 characters long each (ideally < 200 characters) :slightly_smiling_face:

Alternatively, we could drop the brief description entirely and display the first paragraph of the full description instead. However, many descriptions will need to be adjusted as their first paragraph is too long. Edit: This may not be a good idea, as it's easier to make a dedicated paragraph shorter.

[ghost]

The problem with all these proposed renames is that they are confusing and don't correspond to any other engine. I would even rename CharacterBody back to KinematicBody since we have 2 different concepts: KinematicBody which is a physics body and KinematicMode which is a physics body behavior. A KinematicBody is a physics body permanently locked into KinematicMode. A CharacterBody seems confusing to new users. Is confusing to me going from 3 to 4.

Most engines use these: Kinematic (pretty much standard) Dynamic/Rigid/Simulated (the only one that seems to change) Static (standard)

[JamesC01]

The problem with all these proposed renames is that they are confusing and don't correspond to any other engine. I would even rename CharacterBody back to KinematicBody since we have 2 different concepts: KinematicBody which is a physics body and KinematicMode which is a physics body behavior. A KinematicBody is a physics body permanently locked into KinematicMode. A CharacterBody seems confusing to new users. Is confusing to me going from 3 to 4.

Most engines use these: Kinematic (pretty much standard) Dynamic/Rigid/Simulated (the only one that seems to change) Static (standard)

CharacterBody is incredibly similar to Unity's CharacterController component, and since it exposes a ton of character-related options, I think CharacterBody is a good name.

[ghost]

CharacterBody is incredibly similar to Unity's CharacterController component, and since it exposes a ton of character-related options, I think CharacterBody is a good name.

Right but based on the name it would suggest the sole purpose of that node is for building characters. Imagine you have never used this engine and you see CharacterBody in the list what's the first thing that pops to your head? Is like a VehicleBody but specifically for building characters. Is not strictly true. I use KinematicBody for a lot more than just characters.

Someone above has proposed renaming CharacterBody to InteractiveBody which seems more appropriate imho.

[JamesC01]

CharacterBody is incredibly similar to Unity's CharacterController component, and since it exposes a ton of character-related options, I think CharacterBody is a good name.

Right but based on the name it would suggest the sole purpose of that node is for building characters. Imagine you have never used this engine and you see CharacterBody in the list what's the first thing that pops to your head? Is like a VehicleBody but specifically for building characters. Is not strictly true. I use KinematicBody for a lot more than just characters.

Someone above has proposed renaming CharacterBody to InteractiveBody which seems more appropriate imho.

InteractiveBody is even more unrecognizable to people from other engines. And in Unity, you could also use the CharacterController component for things other than characters, but most of the time you won't. For moving platforms or doors, you can use staticbody, with kinematic motion enabled, or rigidbody set to kinematic mode, similar to Unity's way of doing it.

[AwayB]

Forgetting analogies and so on. Considering types of physics simulations, we have:

Physics
├ Solid
│ ├ Static
│ ├ Kinematic
│ └ Dynamic
│    ├ Rigid
│    └ Soft
└ Fluid

I'm very very late for this conversation, so don't mind me too much, but I find your comment very interesting, I expected:

Physics ├ Rigid │ ├ Static (unaffected by non-script physics) │ ├ Kinematic (easily scriptable physics) │ ├ Animated (CharacterBody/InteractiveBody) │ └ Vehicle (VehicleBody) │ └ Dynamic (full physics simulation) ├ Soft(is there a point to a non-dynamic soft body?) └ Fluid(??)

Currently with Godot 3.3.3 we have: PhysicsBody ├ KinematicBody (Scriptable) ├ StaticBody(Unmovable but can still be moved) ├ RigidBody(Is Rigid, but how is it more or less rigid than the others?) │ └ Vehicle (Vroom Vroom)

A minor uncertainty I held for awhile with Godot was whether Static was movable at all, due to its name. Of course you could just modify its transform, but I wondered if it was going to be a problem for the physics engine or something like that.

I had questions like:

• Can static be moved?
• Should I use Kinematic on objects that I will attach to my Kinematic Player (say, an Axe, a gun, a backpack)?
• Will a StaticBody crash or cause trouble if it's attached to my Kinematic? <- still not sure about that one
• Do I lose any helper for movement like move_and_slide if I use a RigidBody? And a few more.

From that first impression, I believe the clearest naming convention would be: RigidBody(Base, non instantiable, replaces PhysicsBody) ├ StaticBody (Does not Move) ├ KinematicBody (Moves by Scripting) │ ├ AgentBody(CharacterBody/InteractiveBody) │ └ Vehicle (VehicleBody) └ Dynamic (Moves by Physics) SoftBody(Changes Shape, Dynamic)

In my mind, Static should never move, Kinematic should, Dynamic is fully simulated. Rather than defining them by their names, they're best defined by what they oppose. Rigid vs Soft, Static vs Kinematic vs Dynamic, CharacterBody/AnimatedBody/AgentBody vs VehicleBody.

If StaticBody should have the possibility to move, remove KinematicBody(or CharacterBody), and maybe have a non-dynamic MovableBody that would handle moving platforms, rotating doors, etc? Not that it's necessary to have a new class, but for example I only learned that StaticBodies had Modes by reading this thread.

[theraot]

@KingArrkinian I mean those physics simulations exists. I can see how it could be interpreted that we had them in Godot, but it is not like that. So.. Let me clarify…

When it comes to physic simulations that exist (not necessarily in Godot, but in general)…

A kinematic simulation is based on velocity and angular velocity. A dynamic simulation is based on force and torque. And you can have them with deformation (soft bodies) or without (rigid bodies). There are also fluid simulations, winch I mention just to not lose the fact that the other are all solids. I remind you states of matter. Soft bodies (such as cloth) are solids. Solid in that context does not mean rigid. Ah, and an static simulation, is ern.. It does not move. Well, actually the term static would come in analysis of stress points of a structure in engineering (which we usually are not concerned in games) but for us it is "it does not move".

Those being physics simulations, their classification is not about whether or not they can be scripted.

Now, that we have a primer on physic simulations we can have another look at the nodes Godot has and see what kind of simulation they do, and that is one way to argue if the names are good or not. That is what I was doing there (https://github.com/godotengine/godot-proposals/issues/2867#issuecomment-861880058).

[ghost]

From what I understand the issue is that after the physics changes some of the KinematicBody or RigidBody kinematic mode functionality from Godot 3 was unified and moved up in PhysicsBody in Godot 4 which makes all the children of PhysicsBody also kinematic (to a certain degree) in addition to their specific functionality.

Here is my suggestion that is perhaps more inline with code changes.

PhysicBody
├ SolidBody (formerly PhysicsBody)
│ ├ InteractiveBody (requires manual scripting and is mainly used for interactivity) (formerly CharacterBody)
│ ├ DynamicBody (is fully simulated) (or could be RigidBody)
│ │ ├ CharacterBody (works in tandem with navmeshing agent ai move to location)
│ ├ └ VehicleBody 
│ └ StaticBody (is generally speaking static like a wall but has limited motion like a moving platform)
├ SoftBody
└ LiquidBody

I would honestly prefer the old and more familiar terminology KinematicBody, RigidBody, StaticBody but maybe it doesn't line up with the functionality of the classes in Godot 4.

[vesk4000]

Can anyone summarise what the final decision on what the physics nodes are going to be is? I saw that there is some kind of AnimatedBody which inherits from StaticBody and there is also apparently a RigidDynamicBody, but I don't know about the other bodies. Are there going to be any other bodies?

[theraot]

I'll write what I have been able gather. We have:

    On 3D                       On 2D

─ PhysicsBody3D         ─ PhysicsBody2D
  ├ StaticBody3D          ├ StaticBody2D
  │ └ AnimatableBody3D    │ └ AnimatableBody2D
  ├ CharacterBody3D       ├ CharacterBody2D
  ├ RigidDynamicBody3D    └ RigidDynamicBody2D
  │ └ VehicleBody3D         │
  └ PhysicalBone3D          └ PhysicalBone2D
─ SoftDynamicBody3D     ─ SoftDynamicBody2D

The following is written from the perspective of going from Godot 3 to Godot 4.

---

StaticBody

If you were using StaticBody in Godot 3, keep using StaticBody in Godot 4.

What StaticBody does (without scripting it) remains pretty much the same as in Godot 3 (You can't push them, and they affect the response of what collides into them).

And I say without scripting it, because it now has move_and_collide (they all have it, except SoftDynamicBody3D, because it was added to PhysicsBody). Which you could use... However, I'm going to suggest using the new AnimatableBody instead.

The new AnimatableBody adds a sync_to_physics property, and is intended to be moved, for example from AnimationPlayer. Furthermore, going forward, advice is to use AnimatableBody for moving platforms. See also https://github.com/godotengine/godot/pull/51600#issuecomment-909381723.

---

KinematicBody

As we know, if you were using KinematicBody you probably would want to use CharacterBody. It is there where you would find move_and_slide... And you would find it has no parameters, because they became properties of CharacterBody. See https://github.com/godotengine/godot/pull/51027 and https://github.com/godotengine/godot-proposals/issues/2982.

If you were using KinematicBody but you don't need move_and_slide, you can use AnimatableBody instead.

Note: RigidDynamicBody and AnimatableBody have a physics material, but CharacterBody does not.

---

RigidBody

If you were using RigidBody, you would want to use RigidDynamicBody. As you would expect, it uses impulses, forces and torque, also has build-in gravity.

What is up with the word Dynamic? Perhaps verbose, it is not wrong. There are two types of dynamic bodies: rigid and soft. And so there are RigidDynamicBody and SoftDynamicBody. However, I'm not sure we needed the word Dynamic in the name. Yet, if anything, anybody looking for "DynamicBody" will find them. See also https://github.com/godotengine/godot/pull/51600#issuecomment-909381723.

Plus, I think https://github.com/godotengine/godot/pull/52754 makes things easier to understand, in particular the property lock_rotation (which used to be MODE_LOCKED which used to be, er… MODE_CHARACTER - yeah, and even now I had to look at the documentation, lock_rotation is much better).

---

Between AnimatableBody, CharacterBody and RigibBody, when it comes to script motion, how do you want to do it?

• Setting the transform -> AnimatableBody
• With move_and_slide -> CharacterBody
• With forces and torque -> RigidDynamicBody

---

SoftBody

If you were using SoftBody you would want to use SoftDynamicBody. I see no functional difference.

---

VehicleBody

Disclaimer: never used these.

Aside from the name change (Added 3D on the name), and the changes of RigidBody to RigidDynamicBody, they appear the same to me. There should be no reason stop using VehicleBody.

---

PhysicalBone

Similarly to VehicleBody, I don't expect any reason to stop using PhysicalBone.

Why PhysicalBone2D extends RigidDynamicBody2D but PhysicalBone3D does not extend RigidDynamicBody3D? Don't know. But I'm glad there is a PhysicalBone2D at all. There weren't in Godot 3.

[vesk4000]

@theraot Thanks a lot for the reply! That's what I was looking for. One question though, is there a node that works the way the RigidBody worked. By that I mean that it had a few modes which allowed you to dynamically switch the way it behaves from a RigidBody (meaning that you use forces and what not) to make it behave like a KinematicBody or a StaticBody. I really hope that there is still an easy way to do that, because it was very useful.

[theraot]

@vesk4000 Use RigidDynamicBody(2D/3D).

Currently (edit: I mean the way it is in the master branch - a.k.a. Godot 4 pre-alpha - at the time of writing), you would set freeze to true when you don't want it to move by forces (including gravity).

If freeze is true and freeze_mode is kinematic then changing the position of the object in physics steps is considered movement from the previous position and pushes things along the way.

If freeze is true and freeze_mode is static then changing the position of the object it is considered a teleport, and thus pushes nothing.

Note also that it gets move_and_collide inherited from PhysicsBody. Which, by the way, now takes a velocity, so you don't need to multiply by delta.

[vesk4000]

@theraot Oh ok, that clears it up, thanks! I gotta say I wouldn't have guessed that when you 'freeze' the RigidDynamicBody you would be able to use it as a KinematicBody, so I don't think that it is the most intuitive naming, but at least it works and there hasn't been any regression in terms of actual functionality, which is what matters the most.