Character Controllers, Colliders and Speed

Target Platforms Mobile
1

I’m working with animated characters for the first time in any serious way.

I’ve pushed around the characters, worked with animations and an beginning to feel comfortable about how things are working. I can get basic behaviour and little skating… But many of the examples I see are based around the use of a Character Controller, and I’ve been exploring this direction over simply using a box collider and transform.translate.

I have one vague worry and one specific problem:

The vague worry is:
How efficient is the character controller and is there a better work-around if it isn’t? I’ve been doing a lot of digging on the forums and have not really answered that one.

The specific problem is related to the capsule collider:
This capsule collider seems to be completely integrated into the Character Controller, and it’s not really working for me.

I find that, to get the model to rest correctly on the ground, I have to seriously fiddle with the controller’s collider, and it doesn’t really comfortably contain the creature and, as you can see, it sticks way above the model. I’d rather have a simple box collider…

What is the going advice for Character Controllers, Animated Creatures and limited platforms like the iPhone?

2

The CharacterController isn’t generally too bad for performance, although some people seem to have had memory management issues with it on the iPhone (ie, it seems to cause a garbage collection undesirably often in some cases). What you use will depend on what behaviour the spider needs to have. If it is a player character, you will probably want something like the CC’s collision detection to stop the player walking through walls, etc. You can also do things like this with raycasts sometimes, and this may turn out to be a better solution for you. If the spider is an NPC, you will probably get better results with a box collider + transform.Translate since NPCs normally don’t walk into walls.

3

andeeee, thanks for getting back to me.

Not to put you on the spot, but I’d really appreciate your comments:

First, I’m not sure I fully understand the detail from some of your suggestions. Second, since I first posted I have tried a few alternatives, and I’m not sure what is best:

I’ve tried box colliders using transform.translate and a rigidbody using Rigidbody.MovePosition with both isKinematic on and off.

For this test, the spider* is an NPC/MOb with a very rudimentary AI that randomly switches between idle, turning, and moving so a group of them will mill about roughly in the same area. Ultimately this could involve working with an A* pathing package** to find way points or seek targets.

The easiest alternative was the rigidbody using Rigidbody.MovePosition and isKinematic off. This meant that the spiders used gravity, followed uneven terrain and didn’t go through walls. My worry is that suddenly the spiders are in the realm of the physics engine, which I imagine is NOT efficient.

When I tried a box collider and transform.translate and the rigidbody with movePosition and isKinematic, the spiders, not surprisingly, didn’t use gravity, didn’t follow terrain and went through walls.

This leads me to the part I don’t fully understand how best to implement - which it the collision detection and/or rays. I understand this in theory, but I’m unclear how best to put this in practice.

I did look at the character controller and try to suss out how it worked, but felt a bit confused when trying to apply this to a box collider situation…

When you are mentioning using rays, are you suggesting that each frame the moving object moves it should cast a ray looking for colliders… like the collision script on the wiki to prevent rigidbodies from going through geometry at of high speeds?
(http://www.unifycommunity.com/wiki/index.php?title=DontGoThroughThings)

I’ll take any insight or suggestions, as I’m still stabbing in the dark and when I get something to work, I’m really not sure if it’s the best or most efficient way to do it.

* (The spider is from GusM at http://gustavom.com/ and a lovely piece of work, I might add!)
**(A* from Aron Granberg at http://www.arongranberg.com/)

4

Getting back to this… I’ve been using the solution I discussed above as a temporary measure:

The problem I’m finding with this approach right now, is I it’s difficult to get the NPC to register a contact with the Player, tagged as “Player”. I’ve tried the default CharacterController with the integrated capsule collider, but this didn’t work. A basic search of the forums for “character controller” and “collider” and “tag” reveal general problems with getting good collisions from the character controller. I’ve tried adding an additional capsule collider to the Player’s character controller and made this collider larger than the character controller’s capsule collider. This seems to work with the following code that’s attached to the NPC:

function OnCollisionEnter(collision : Collision) {
  if (collision.gameObject.tag == "Player") {
    Debug.Log ("OnCollisionEnter Tag Test = Player");
  }
}

What I’m discovering, tho’ now that the NPC is in the realm of physics, is that it seems to be taking not only the contact but the physics from hits from the character controller. I need to do more research into this, but that’s what it seems…

I’d like to take the NPCs out of the world of physics, and not use the character controller (unless I can get better control over it’s capsule and other issues…). I’ve been looking into isKinematic and trying something from this family:

transform.rotation = Quaternion.FromToRotation (Vector3.up, surfaceNormal);

… as a start to a way to keep the npc’s on a surface and following uneven terrain without useGravity…

But, in an effort to keep from just randomly experimenting, has anyone found a reasonable solution to NPCs, controllers, and such?

5

The physics engine is pretty efficient at what it does (and much of it is essentially the same as what you would do in your own code, but highly optimised). However, what I would say is that is is easy to end up with the physics badly set up so the engine is doing more work than it really needs to. Pushing a box collider along the ground shouldn’t be too bad but you could improve on this setup if, say, you need a lot of spiders in the scene. One solution that springs to mind is to use wheel colliders to support and move the spider. With four of these placed at the spider’s “corners”, it should track the ground convincingly. However, the wheel collider should have less CPU overhead than a box collider in contact with the ground.