When rotating the camera horizontally, why not rotate the entire CharacterBody instead of just the character? Since Collsion shapes like Cylinder and Capsule are simmetrical, it wouldn’t make a difference, and it would allow the use of global_transform.basis to see the direction the character is facing.
Is it an optimization thing? Why do so many FPS demos lock the rotation of their body?
Because typically the camera is representing the character’s eyes/head.
I would love to know the answer to this too. Almost every tutorial and I have found has a fixed CharacterBody3D that never rotates and then has a separate child node that rotates for the mesh.
Is it so a camera can be attached simply? Or is there some other reason?
It doesn’t matter if the collider is symmetrical. Do what’s more convenient for your rig. I’d always prefer not rotating it.
I’m not sure I understand. If the root of your character scene is a CharacterBody3D, then it needs to have a CollisionShape3D as its direction child and it needs to have its move_and_slide() method called. If the CollisionShape3D’s shape is, for example, a Capsule in its default, vertical, orientation, then omnidirectional grounded movement of the root CharacterBody3D is fine.
As soon as the CollisionShape3D(s) shapes stop being symmetrical, then you need a way to have them match the rotation of the rig. You can’t make them children of the rig/base pivot which is itself a child of the CharacterBody3D, since they must be direct children. You can used a RemoteTransform3D as a child of the base pivot that targets the CollisionShape3D so that its rotation matches the rig while the CharacterBody3D itself stays with its basis aligned to the global position axis.
Am I fundamentally misunderstanding something about how CharacterBody3Ds should be used, or is this basically it?
You can use it in many ways. As I said - it doesn’t matter if the collider is symmetrical, which will almost always be the case for a fps. If it’s not symmetrical then you’ll need to rotate it but who’d want to have a non-symmetrical collider in a fps. It’d make the whole thing very confusing for the player.
@wolscott I can’t think of an instance in which a 3D character would need to have a non-symmetrical collision shape. And, even if it did, that would cause more problems, such as running up against a wall and quickly turning around to clip through the wall.
There’s almost no point to having a non-symmetrical collision shape, unless you can think of one. A game where having a non-symmetrical collision shape is part of the mechanics (slotting into walls to traverse vertically?) is the only situation I can think of.
Just a thought, though.
This is a good point. It certainly doesn’t make sense for an first person game, I think. But case that this came up in for me is I was working a project where the player was first person and I wanted to re-use the movement component for the enemies, but the enemies were like, monsters that were short and long like spiders or dogs or whatever. And there’s no round-bottom collision shape that is shorter than it is wide.
So if I uses a spherical collision shape with the sphere big enough to cover the width i wanted, it was way too tall and didn’t work for that reason. So I ended up putting a capsule on its side.
But I do think you’re right. The potential for the shape to clip through things is definitely a negative. But in general I don’t understand the solution for round bottom collision shapes that wider than they are tall.
Use multiple capsules or a custom convex shape.
You can make one, though. CollisionShape3D’s shape → new CapsuleShape3D → you can set the radius and total height independently of each other! You can make a shape with a radius of 2 and a height of 0.5.
Nevermind, I just checked, a capsule shape HAS to have at least double the radius for it’s height. So, at minimum, it’s a sphere. Oh well.