Streamline Physics Nodes

[shegedep]

Related to #5274. Pertains to 2D as well, but I wasn’t sure if this qualified in the Core category.

I expect hot debate on this, but I’d really like to see an overhaul to the physics nodes.

The distinction between their features and how they interact is pretty unintuitive. I see them misunderstood constantly. Even the proposal thread for the current setup is filled with debate and confusion.

You have to do a lot of work to port features of one to another if your use case falls outside their specific scope. The majority of my time working on the physics of my game is dealing with this. I’ve spent a lot of time digging through source just to make sense of things.

What we have:

• CollisionObject. Abstract class that creates/syncs collision shape with PhysicsServer, includes functionality like CollisionLayers
  • Area. Detects and signals overlaps. Includes lots of unnecessary hyper-specific functionality (like a wind feature that only works with soft bodies)
  • PhysicsBody. Abstract class that includes base functionality for kinematic collisions and depenetration (move_and_collide)
    • StaticBody. Body that isn’t intended to move (but can be)
      • AnimatableBody. A static body that is intended to move but doesn’t return collisions (unless using move_and_collide). Can be moved via animations but unintuitively this is not the only/best use for them
    • Rigidbody. Body for simulated physics.
    • CharacterBody. Includes functionality for character controllers (eg snapping, slopes, riding other bodies), thanks to the magical function move_and_slide. Unintuitively, move_and_slide is useful for much more than characters
    • Also there is PhysicalBone and VehicleBody, which need improvements outside the scope of this discussion

What I’d like to see:

• Collider. Essentially CollisionObject and Area combined, minus the hyper specific features
  • PhysicsBody. Works like Unity’s Rigidbody, can easily toggle between static, kinematic, and simulated motion (maybe add a fourth for animated). Technically, this already exists through freeze_mode, so my suggestion boils down to bolstering this feature so that entirely separate classes aren’t needed.
    • CharacterBody. Includes the character controller features but with the added benefit of inheriting the improved PhysicsBody.

I feel this is more in line with Godot’s philosophy. The current nodes are written with intended use cases that would be better left to the developer to distinguish. I’m interested to hear others’ thoughts.

[theraot]

Oh, this topic again. We don't even agree on the discussion category o,.,o.

Changing this now would be too much of a breaking change. So, it will be one of those topics that will come back from the grave once there is a Godot 5 announcement.

This is what I can come up with for deciding what to use:

- Can be pushed?
   ├ Yes: Use rigid body
   └ No: Is any of these true:
     │   - Have a complex or unpredictable motion?
     │   - Should areas detect it?※
     │   - It should be a moving platform for other things?※※
     ├ Yes: Use character body
     └ No: Does it move at all?
        ├ Yes: AnimatableBody?
        └ No: Use Static body

※: you can enable detection of static bodies in Jolt.
※※: I've seen enough issues with static and animatable bodies as moving platforms that I'm no longer recommending it.

Of course, the requirements might change, or you might run into a bug, and that might force us to reconsider the decision.

---

Static

If I have decided something that does not move should move, it is trivial, since I don't have motion code to translate. Similarly, if I decided something that moves shouldn't, I'm removing the motion code. So I don't think this is an issue.

---

Animatable

I void it.

Beyond the naming issue with which we have to live with. Animating something else and having a character body programmed to follow it solved many issues for me in prior versions of Godot. Perhaps I won't have these issues in Godot 4, in particular with Jolt, but I'm not trying, I'm sticking with what worked.

Thus I won't have to consider changing something from animatable to something else, or something else into animatable.

---

Character and Rigid bodies

If you need to migrate from rigid to character body, you need to implement impulse and forces. This should be doable (I tried, and could not get torque right, but still).

And if you need to migrate from character body to rigid body, your move calls should translate to impulse and forces, which isn't too bad. You might also need to teleport the rigid body, which you can do by calling directly into the physics server, or by changing modes and other work arounds. A teleport method would be welcome.

I'm saying impulse and forces to cover all bases, because I recall some differences between 2D and 3D rigid bodies, I do not know if they still stand (I mostly do 3D).

I'd wish we had official examples of a character body with impulse and forces, and a rigid body with move methods, so they would serve as reference for people doing these kinds of migration.

---

How can we design it so we don't need that?

I would like a "motion driver" type (or the same thing by a better name). That you could add to a physics body. In fact, I would like physics bodies to have multiple "motion drivers", and they get called one after the other. Many of us already do something like this in character controllers. But having it as part of the engine would allow Godot to provide "motion drivers" that have the methods we use to move either rigid and character bodies, and they might call the physics server under the hood to enable features as needed (e.g. allow the body to detect collisions so the rigid "motion driver" can react to them). And we might even have a follower "motion driver" for the animatable body use cases.

Note, however, that I don't mean they replace coding the motion in physics process. So you could still program the way you are used to. But making a character behave as a rigid body should be as simple as adding a rigid motion driver, and configuring it.

Note if we combine the physics bodies this way, it would also add friction: when you want to add a rigid body and you open the dialog search for rigid... It won't be there.

---

The new node dialog needs improvements

We might use a simplified mode. For example, what Miguel De Icaza did: https://blog.la-terminal.net/giv/

We could have the search include the class descriptions or keywords, so we might find stuff even if the name does not match.

And we could have some build-in templates, which could appear as children of the nodes, but are not other classes... They are the same node but with some configuration already done for an specific use case and a name that is easier to find for that use case.

[shegedep]

Yep, this would be a major change for a whole number release.

The fact you need a workflow to choose a node, illustrates my whole point.

Heres a little more in depth breakdown of what the current nodes actually do differently, and therefore what they’re suitable for.

Static Body: This node should not be moved, it will have unexpected behavior. Use for fixed terrain.

Animatable Body: This node infers its own velocity no matter how it is moved. It will push CharacterBodies and Rigidbodies when moving into them without recognizing any collisions (technically those bodies are reacting to a wall moving into their collider). CharacterBodies in Grounded mode will ride on top of it. It can be moved using move_and_collide if you want it to react to collisions. Lastly, its namesake feature, the confusingly named “Sync to Physics” option, will synchronize any movement via Animation frames with the physics process. If you’re not moving it with Animations, Sync to Physics should be OFF. Animatable Body is ideal for moving platforms, and suitable for any kinematically moving body that does not make use of move_and_slide.

Character Body: Designed to operate by using move_and_slide. The basic move_and_slide, aka Floating mode, simply calls a loop of move_and_collide, using the returned KinematicCollisions to redirect velocity along the surface of another body. The Grounded move_and_slide is very advanced, it includes features useful for a character controller like floor/wall/ceiling detection, floor snapping, sticking to slopes, and automatically riding any other body it is on top of. It does NOT push any other body, or even register a collision in that other body, due to how move_and_collide stops you before you enter the other body’s collider. Causing interactions on other bodies requires you to manually make use of the KinematicCollisions returned by move_and_slide. It is ideal for basic character controllers, and the floating mode is suitable for any object you want to make use of the basic slide functionality (although this basic function is very easy to recreate in other bodies).

Rigid Body: Full simulated physics node, moved via forces. Its collision response is fully automated under the hood by the physics engine. It is optional to report these collisions. Fine-tuned control can be achieved by writing a custom force integrator. Alternatively, you can make hacky use of the kinematic freeze mode. RigidBodies push other RigidBodies, they cannot push CharacterBodies, but they can act as moving platforms for CharacterBodies (very janky). RigidBodies are compatible with Physics Joints, unlike the other bodies. Suitable for, obviously, realistic simulated physics. Very challenging to adapt to a kinematically-driven object.

Summed up:
Moved by physics -> RigidBody
Moved by move_and_slide -> CharacterBody
Moved any other way -> AnimatableBody
Not moved -> StaticBody

But each body also includes subtler features you may want to use in another. Or you may simply want a body that can alternate between these methods of movement. That’s where you’re out of luck and that’s what my suggestion aims to address.

[theraot]

@shegedep I don't use that workflow to choose a node, I use that workflow to try to help people who run into issues with those nodes.

I hope it is not lost on you that an animatable body is an static body. You can move static bodies. An animatable body moving is an static body moving. This was a whole argument in the issues you linked.

That leads me to the issue with areas: if the static body moved the area won't detect it. Yes, you can say it is not the intention of the design.

The problems I had to deal with an animatable body as a platform arise once the animatable body wasn't moved itself, but a parent. That is, once I wanted to do something more complex than a single moving body. Another issue I saw was the character body not consistently retaining speed from the animatable body. I have no issues using character body as a platform. And yes, I know that is not how it was intended.

I'm not arguing the intention of the design, but what freaking happens in practice.

It looks to me that there are use cases that you - and perhaps the designers - have not considered. For example, I can use an area to simulate enemies hearing. So I give the area to the enemy, and I use physic objects for things that emit sound. I would, of course, separate them using layers and masks. Now, consider, should the physic objects that represent sound be static, animatable, character or rigid? They are not going to move on their own, but I might want to parent them to something that moves. Animatable? Ah, that is an static body movies, areas are not going to detect it.

I believe we can both agree that even if we begin programming against the design of the system, we need to make a game that works, and so when there is a bug, or when there is a missing feature we are going to deviate form the intention of the design of the platform system and program against what actually works in practice.

I agree the design can be improved. And perhaps I misunderstand the design, I'm ready to accept that. But what I tell you is based on experience of what works in practice.

[theraot]

Let us focus on the suggestions then.

I agree a redesign would be good. Of course not yet. And I have a different idea of what it could be.

First, I made a stop gap suggestion to have more official examples. It is often the case that we start with a kind of node and then want features of another※. And examples can cover how to mimic a body type using another, so we can use them as reference to implement whatever we are missing. Plus, it can be done before Godot 5.

※: Reasons including, but not limited to: picking wrong, changing requirements, bugs, and missing features.

Of course that does not remove the choice of nodes. As alternative you suggest modes. People would be choosing anyway, and might have the same kind of confusion, and issues between modes. So from my point of view the advantage is making it easier to switch (instead of removing the choice).

I made a counter suggestion: I think I would like a modular physics object (the "modules" I called "motion drivers" for lack of better name). The equivalent of changing modes under my idea would be enabling or disabling the modules. And it would allow extension: we could write our own if there isn't a combination of existing ones that is right for our use case※※. To be fair, I'm aware this does not remove the choice either, if anything it pushes it down one level because we would be choosing these modules.

※※: In fact, I expect some people would implement character controllers this way, because there are existing character controllers that use a similar kind of composition. However, I'm not suggesting that implementing these modules should be the default way to implement a character body, instead I want that to remain the same way as it is now, so people don't have a hard time getting started.

As far as I can tell the reason why the bodies remain separate in code at the end of the day is because optimization. For example, since nothing is going to push an static body, it does not register a callback for that, it does not even have a property to check to know if it should. That is faster. See, for example, that we could be using frozen rigid bodies for floor and walls, but that is not recommended.

If we have the modules I suggest, and they are responsible of calling into the physics server to enable the different things they need to work, then an static body is a physics body without any modules. And so it does not instantiate them, and no code runs. It remains fast.

Finally, I was also arguing that when the node types get merged into one, the old node types would be removed, so people are not going to find them. To address that I brought up improvements for the new node dialog.

---

Addendum: Perhaps I misunderstood and you don't want modes at all.

Right now, it happens that if we move a rigid body without working around the mode, the physics server will move it back. That is, there are two sources of truth for the position of the rigid body, the position according to the scene tree, and according to the physics server, which are kept in sync, until we try to mess with it. Without modes, the physics server would have to be listening for changes of the position by other means. My worry would be performance, but perhaps it isn't an issue.

[shegedep]

Couple things I wanted to mention:

• Areas absolutely do detect AnimatableBodies. I tested this just now (in 4.3)
• That use case of a sound emitter is not a good example; if it’s just supposed to represent the source of the sound for the listener to detect, it should not be a body at all, but a simple area (Areas detect other Areas).

A modular approach sounds like it will only add to the mixups and confusion. I do want modes, essentially I want the rigidbody Unity has (yes I know, ew Unity, but its rigidbody is very good). In effect what I want to see:

• No abstract class nodes (let developers extend the base CollisionObject and PhysicsBody)
• Gut the unnecessary features from Area that have hyper specific intended uses (gravity, damping, wind, audio busses), move them to subclasses or create a new “AreaEffect” resource type.
• Combine Area with CollisionObject for a single Collider class
• Make RigidBody the base PhysicsBody
• Give it the basic move_and_slide
• Give it sync with animations feature
• Give it modes: Static, Kinematic, Simulated, and Animated
• Rewrite CharacterBody’s grounded_move_and_slide to account for being a RigidBody

[theraot]

About my examples...

Do the area detect the animatable body enter and exit, regardless of which one moves? Sounds like I have something to test. I settled on what worked for me, and I didn't keep testing. Sadly using character bodies for moving platforms allowed some unification of my code. Which is another point in favor of some kind of unification of these nodes. About the sound example, yes, areas can detect areas, but I don't need the area functionality on the source of the sound (this is a case of areas doing too much), a body that nothing collides with due to layers and masks, but certain areas detect also due to layers and makes makes sense for me.

And about the suggestion...

I like the idea of making the base classes not abstract, so we can make our own that way. It is odd that area got so much stuff on it, as far as I can tell, at no point it was worth it to add a new kind of node for any of the things it does... I like the idea of an AreaEffect type, and the PhysicsMaterial is a precedent.

Now, you say you want the rigid body to be the base body. I think the base body should be a type that is easy to extend for those who want to (which goes with the above point), and act like a static body if nothing is added to it. That way we can use it for floor and walls that do not move, and it is more performant than using frozen rigid bodies.

So, I would make it like this: CollisionObject (with the basic functionality of an area, and can have area effect) <- PhysicsBody (with the basic functionality of an static body) <- RigidBody (with modes, and with the methods from character body).

Addendum: Maybe not. If the CollisionObject has the ability to detect and PhysicsBody is the static body, this does not give an static body that does not have the ability to detect. So scratch that. I think we can live with it being resolved at lower level instead.