How do you draw the character controller's capsule?

[chebob69]

I've tried adding it to my InstancedModelDrawer (also tried adding characterController.Body). No luck so far. I can manage without but it's probably best so I can align my character mesh with the capsule perfectly.

Could I also ask which is the best out of the SphereController and the SimpleController (efficiency/features)? I started off with Simple- as I only need to be able to jump and climb slopes. Any reason to switch?

Thanks.

[Norbo]

I've tried adding it to my InstancedModelDrawer (also tried adding characterController.Body). No luck so far. I can manage without but it's probably best so I can align my character mesh with the capsule perfectly.

Adding the characterController.Body entity to the model drawer should work. Is the ModelDrawer.Update method being called to update the transforms, in addition to the draw method?

Could I also ask which is the best out of the SphereController and the SimpleController (efficiency/features)? I started off with Simple- as I only need to be able to jump and climb slopes. Any reason to switch?

The SphereCharacterController is substantially more robust than the SimpleCharacterController. Currently, for FPS-game style characters, the choice should only really be between the SphereCharacterController and CharacterController. The others are not nearly as robust, and don't have a speed advantage.

(I've kept some of the older ones around as some form of documentation, but they're so old that they probably do more harm than good these days.)

[chebob69]

Oh my mistake, it WAS drawing the capsule- it was just smaller than I'd imagined so I didn't notice it under another mesh I had. I'm a bit curious why the capsule being drawn doesn't seem to align with the collidable it represents though. As in there's a gap of 0.3-0.5 between the bottom of the capsule and the ground.

Currently, for FPS-game style characters

And what about for non-FPS style characters? My game will be a third person action/strategy. I assume that'd be the same character though, just different camera? Out of curiosity,
why is the sphere character more robust than the simple?

[Norbo]

I'm a bit curious why the capsule being drawn doesn't seem to align with the collidable it represents though. As in there's a gap of 0.3-0.5 between the bottom of the capsule and the ground.

The SimpleCharacterController is kept off the ground by a ray cast. That allows it to support a form of stepping, though unsafely.

And what about for non-FPS style characters? My game will be a third person action/strategy. I assume that'd be the same character though, just different camera?

The camera perspective is indeed irrelevant to the character controller. If the character controller itself behaves like the usual FPS character, then the CharacterController or SphereCharacterController is the way to go. The SimpleCharacterController is almost always worse regardless of the goal.

An example of a game where the CharacterController isn't really necessary would be Starcraft 2 and other RTS games. The characters do not need to do much. Their modes of interaction could be more efficiently handled by a highly specialized implementation that doesn't even have a general physical representation (they usually have some inter-unit collision detection, but that is a long ways from being a full physical simulation).

Out of curiosity, why is the sphere character more robust than the simple?

On a high level, it's because the SimpleCharacterController is enormously old, built for a long-obsolete version of the engine where it was difficult to do the things the newer character controllers do.

An overview of the characters can be found here:

However, the SimpleCharacterController has a couple of problems. First, as mentioned, it does not try to protect itself against step ups. It has no way to recover from a bad step. Second, since it relies on a single ray cast, it can fall into tiny gaps. The CharacterControllerConvexCast addresses the second problem. Instead of a single, thin ray cast, it casts a disc down. However, it still has no way to abort a bad step-up.

There do exist environments in which the SimpleCharacterController won't suffer from severe robustness problems, but there's no advantage to using it over the SphereCharacterController or CharacterController. Rather than relying on a single ray to find support, the new characters analyze all their current contacts for persistent support. They use rays for occasional supplementary tests, such as when the character goes down steps.

In addition, the SphereCharacterController and CharacterController both use constraints to move around. That means their movement forces can be fully seen and understood by the solver; they can interact with articulated structures with a great deal of robustness.

[chebob69]

Ok, well I'm switching to the SphereController but seem to be getting some errors:

Code: Select all

SphereCharacterController.cs(141,54): error CS0246: The type or namespace name 'BroadPhaseEntry' could not be found
QueryManager.cs(57,14): error CS0246: The type or namespace name 'BroadPhaseEntry' could not be found
QueryManager.cs(58,39): error CS0246: The type or namespace name 'BroadPhaseEntry' could not be found

Copied it directly folder to folder, got all the same 'using' directives, I don't understand. Any ideas?

[Norbo]

BroadPhaseEntry lives in BEPUphysics.BroadPhaseEntries in v1.2.0 and above. In v1.1.0, it was in BEPUphysics.BroadPhaseSystems. If you're using v1.1.0 with a character from v1.2.0 or vice versa, the usings won't quite match up. Either update the usings, or use the latest character/engine pair.

[chebob69]

Excellent. You're right- I was using the code from demos 1.1.0. Got a lovely SphereCharacterController prowling my landscape.

Cheers Norbo. One of these days, I swear you're not gonna know the answer!