CharacterController stuck problem

[J2T]

Hi norbo,

today i request your help with an old problem i have with the character controller. I have this problem since i started with BEPU and the Controller but it wasn't that huge problem unti now. This is because we are going straight forward to release a first version of our game and for this, the problem isn't acceptable...

I did a small video because i think this express the problem in a better way then with plain words. Please take a look at the first video on this page.

My first guess was that this is related to the possibility that the character can go up stairs etc. Or better to say that there is a StepHeight which allows this behavoir. So i think the charactercontroller believes there are stairs/supports and then get stucks.

I solved a lot of problems you see there by just editing the parameters(skinWidth, StepHeight, GlueSpeed, StepSlope) you give to the controller. Especially the stuck problem at the clerk and the latern.
But i can't solve the problem with stucking at the terrace (also happens sometimes at the fences). When you see the last two sequences(begin 00:43) in the video i reduced the problem and now the character sliding out after some time instead of getting stuck forever. But this period until the characters gets free is too long

I really did much tests with the parameters but can't found a acceptable soultion. So i tooked a closer look to the findeSupport() and isNewPositionValid() methods. And yes, i have to concede that i don't really understand whats going up there

I dunno if you can help me but maybe it's just to set another constraint anywhere

Anyway, thanks for continuous support...
regards

[Norbo]

This will require some detailed looking into. The character controller has some known 'instabilities,' mostly revolving around the way it finds supports and verifies them. The isNewPositionValid method basically checks the area where the shape would be moving to if it were to 'step up' and use the new object as a support. If it's OK, it uses it as a support. Otherwise, it doesn't. However, this can lead to situations where there is no support available that has a valid new position and the character appears to fall to the ground. This primarily happens in areas with overhangs that the character is being shoved into, but can occasionally happen elsewhere due to a variety of possibilities.

This may not explain every problem, but it is certainly a factor. I'll spend some time looking into it; this may result in a new version of the character controller.

[J2T]

That sounds good

Please post here if there are any news or maybe a new controller...i'm subscribing this topic.

[Norbo]

I've finished the new 'semi-barebones' character controller. It should be a little easier to understand and handles some things better conceptually.

Basically, it is capsule on a stick. A raycast attempts to identify supports for the character to sit on. If one is found, it is propped up. If the support is not too heavily sloped, the character has traction. With traction, the character will be able to move around under its own power.

The character can step up and down like the previous controller. However, there are a couple of limitations with this version. First, it can fall into small cracks (such as those between planks of wood) because it is a raycast rather than a cylinder. Second, it does not currently verify step-up locations as being valid. This is not a problem in many cases, but imagine there's a raised opening in a wall that is just barely tall enough for the character's capsule to fit in, but is not tall enough to include the whole raycast support as well. The character will be able to walk into that opening and, when the raycast detects the 'step,' the character's head will get pushed up into the ceiling.

I'm going to start working on the more complete version now that the base has been finished. In the mean time, you could try this new version out to see if it helps with your problems.

[J2T]

Wow that was fast

Okay i did a quick test just half n hour. Okay you changed a lot so i'm not able at the moment(with other projects in trouble) to take a closer look to this controller implementation now. There are too many thinks didn't work right now. The missing bodyDetector entity need for our 'smart camera', the moveTo() method and the isAirborne propertie. Okay that should not be the problem at the moment. But the characer doesn't move at all. Is it still correct to use the movementDirection propertie?

Okay okay don't worry as i said...just half an hour. I think i can give a better feedback next weekend.

Thanks anyway for your quick reply

[Norbo]

The moveTo method in this new system would just be body.moveTo(location). Instead of isAirborne, you could use !isSupported. The movementDirection field works in the same way as in the previous character controller, so there's two main possibilities to consider. The first is that the character controller's ray is stuck in a rut (between wooden planks for example), and the second is that the world is very large compared to the default speed (defined by maxSpeed). With a large world, the controller may appear to be completely stationary.

Good luck with your other projects!

[J2T]

Hi Norbo,

i found the problem. The problem is that the initializing code in activate() never get reached because isUpdating isn't false at beginning. That really strange because in the old controller it is false and the code in the if body get execuded. Same with your demos and the controller (tested with the new version too). You can believe me i didn't changed anything (around) in the code. Just replaced the controller and adapted the constructor in the client code.
I really don't know why this is happen

But okay i comment out the if-statement to force the initialzation and now it works. There is only problem now which is hard to descripe. When i go straight forward/backward at beginning everything is okay. When i turn left or right the character doesn't go straight in this direction (after release left/right key) instead he goes (slides/strafe) in this this direction. It almost feels like a centripetal force or even if the axies are swiched when i walke around. I can't image you understand what i mean but i think its an settings problem which needs a second view. As is said i tested the demo with the new controller and there is also a normal behavoir.

bests,
J2T

[Norbo]

I'm having trouble visualizing the problem; if you could post a quick video or explanatory screenshot it would probably help.

It sounds like the relevant settings would be the deceleration/acceleration. Insufficient deceleration would cause sliding behavior, while insufficient acceleration would cause a slow change in direction/movement. Does it ever appear to work correctly in your situation, or is it always incorrect?

Another thing to consider is the movementDirection. This is a complete shot in the dark (especially since you've probably not changed the way you deal with movementDirection at all), but it sounds a little like a problem that can be seen when the forward vector of a matrix representing the view position is incorrect (z reversed or whatever else). It may be a good idea just to make sure it's still working right.

[J2T]

Okay found the problem and fixed it.

The problem wasn't the controller settings it was a problem of how i calculate the force. This i the calculation i used and also use further:

Code: Select all

rotationAmount = rotationAmount * RotationRate;
         
Matrix rotationMatrix = Matrix.CreateFromAxisAngle(Right, rotationAmount.Y) *
                Matrix.CreateRotationY(rotationAmount.X);
         
Direction = Vector3.TransformNormal(Direction, rotationMatrix);

Up = Vector3.TransformNormal(Up, rotationMatrix);
          
Direction.Normalize();
Up.Normalize();
          
Right = Vector3.Cross(Direction, Up);
            
Up = Vector3.Cross(Right, Direction);

           
 force = Direction * thrustAmount;
 characterController.movementDirection = new Vector2(force.X, force.Z);

The problem was, that before, with the old version, 'thrustAmount' was either -9f/9f or 0f. Changing this values result in different velocities (with fixed accelearation/maxspeed properties in controller). For now i use just 0f or even -1f/1f and set the resulting velocitie with the acceleration and maxspeed properties from controller. I think this i the normal/right way and i should have do this also with the old controller version

btw i also tested values like -9f/9 for 'thrustAmount' and normalized 'force' then. This results in complete freeze...

Now i will set up the game/controller to the behavoir like it was with the old controller and then going over to test out the proper problem with the stuck. I'll post my results in few hours....

[J2T]

I sadly have to say that the problem is still present

It still happens at the terrace quite often like before. But now the character gets stucked forever again and even doesn't get free after a bit time how i described in the first post.

Do you have any further ideas maybe some changes i can do in the new controller?Or maybe changements in the triangluation or something like that?

thanks

[Norbo]

The simple character controller is a single raycast-based method, so any small cracks between planks on the terrace will cause it to get stuck forever. This was one of the weaknesses of that version I mentioned; are there any cracks between the planks? A "solution" to this problem would be to make the collision mesh solid.

I'm also still working on another cylinder-cast based version which so far is looking fairly promising. It won't fall into cracks and deals with things better than the old version.

[J2T]

No i meant the terrace from the video. See screenshot please.
The problem with the planks of the other terrace is solved through a invisible plane which lays direct on it.

[Norbo]

In that particular situation using the SimpleCharacterController, is isSupported false? How do the velocities/position of the body capsules look while the character is stuck? How do the velocities/position of the intangible object around the characters feet look when the character is stuck?

The support mechanism is so direct in the SimpleCharacterController (single raycast against support candidates, if a support exists, stand on it, else do nothing) that I don't know how it could be causing the problem. To solve this, I might need a simplified, barebones reproduction case that I can debug directly.

[J2T]

Hi Norbo,

yes in this situations there is isSupported false because findSupport() return false. And yes as you wrote before in this case the character should do nothing or in this case fall back to ground....

Norbo, i think it's the best (as you meant) when i give you the solution so that you can see yourself. It's not a problem when you don't like because i know that this cause in high expenditure of time for yourself. If you like i'll naturally support you where i can (setting up project, necessary files etc).

[Norbo]

You can help me by setting up a project that is as stripped down as possible while still showing the problem.

The project could include just the following:
-the character controller,
-input handling for moving the character,
-a mesh which shows the problem (doesn't have to be the one in the game now)
-some extremely simple rendering system (BasicEffect would be fine)
-instructions for how to trigger the bug.

That way, I can run the project and quickly test things.