What bodies and logic to use for 3D in which I want to restrict physics interaction?

Question

I am writing a game for the player to walk through a maze and using the 3D engine for the first time.

I want the player to be stopped by walls, but I don't want its rotation (on any axis) to be affected by bumping into them, as I am restricting turns to 90 degrees on the y-axis.

After experimenting around with different types of bodies, my best results have come from making the player a RigidBody and the maze a StaticBody.

Also, because I am using a RigidBody and using translate, part of the character always ends up poking into a wall.

(Also, I don't understand how move in the KinematicBody translates the scene, as opposed to translate. Any pointers for me there?)

Sorry, a lot of questions rolled into one.

Answer 1

Everything always depends on your design, but here is a short explanation of the common 2 options:

---

Rigid bodies are entities that are controlled by the physics engine (in every engine), is always recommended to not manipulate their positions by hand but using forces/impulses and let the engine do the rest.

With Godot you have the chance to alter some rules and work with a custom integrator (using _integrate_forces, look the 3D platformer demo), that way you can modify the body state so it will move where you want to.

---

KinematicBody, like in every physics engine is just a StaticBody that can have the position changed and is the most recommended to make physic entities controlled by code.

Some engines have additional behavior on KBs, in the case of Godot, adds a special method to use with character controllers, move test movement and try to translate the body without overlapping, if there is a remainder on the movement vector, it marks the body as "colliding" for the rest of the physics frame.

Moving the KB with translation works as moving a StaticBody, ignoring and overlapping every static and kinematic body (useful for things like moving platforms).

In the Kinematic Character 3D demo, is a body moved by move and some platforms using translation (via animation) to see how it works.

---

More options are using areas or just a shape and manually check and correct overlaps the old way.

ps: The actual implementation of KinematicBody (just the 3D one) have some problems with move and layers and masks (looks like is using just layers), if you are going to use that, do some collision tests first.

Comments

Small correction: KinematicBodies are not StaticBodies that can be moved.
First StaticBodies can be moved as well, you should just be aware that in most physics engines that's a comparably expensive operation.
Second RigidBodies and StaticBodies are the two PhysicsBodies that are managed by the physics engine, meaning that RigidBodies will collide with StaticBodies (or other RigidBodies) and change their movement accordingly.
KinematicBodies and Areas are the two physics nodes that are not managed by the physics engine, they can merely check the physics engine for collisions. That means that RigidBodies will not bump into KinematicBodies, only KinematicBodies will be notified when they run into RigidBodies.

But I agree with the conclusion: the OP should use a KinematicBody.

---

Yes SB can be moved but are not supposed to do that, I just was trying to explain it in the less confusing way possible.

Are you sure that KinematicBody is not a PhysicBody? because inherits of it and RB can change to KB mode, also without using move wont get any notification (unlike Area).
And move is managed by physics server too.

---

You misunderstood what I meant to say. I am not a native speaker and I was tired, so sorry if my wording was not good enough.

This is what I meant with a little more detail:
There's two parts in every physics engine: collision detection and collision solving. Each of the four classes (RigidBody, StaticBody, KinematicBody and Area) performs collision detection, so on that lower level they all are managed by the physics engine.
This doesn't apply to the physics solver though. If you build a scene containing PhysicsBodies and StaticBodies the physics engine will detect collisions and then call the solver code for the PhysicsBodies to remove the collisions.
If you add KinematicBodies and Areas to that scene the physics engine will call your code on these objects for you to act.

So when I said these classes were "not managed" by the physics engine I meant that adding Areas or KinematicBodies to a scene won't change the game's behavior unless your code says so. That's why I said that KinematicBodies aren't StaticBodies (I didn't say they weren't PhysicsBodies, did I?), because StaticBodies affect the behavior of RigidBodies even if you don't write any custom code.

---

Thanks very much for this answer. I am in the process of digesting it. +1 so long.