Character controller gets stuck and climbs walls

[GoogleCodeExporter]

See discussion

Original issue reported on code.google.com by erwin.coumans on 22 Feb 2009 at 6:45

[GoogleCodeExporter]

Kinematic character controller gets stuck in a triangle mesh, and climbs walls.

See report and reproduction case here:
http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=3220

John, can you check this out?

Original comment by erwin.coumans on 22 Feb 2009 at 6:49

[GoogleCodeExporter]

A coworker and I have run into this issue too and have had to modify the 
controller
to get it to work for us. A couple lines of code were disabled and others were 
added.

Attached are the Kinematic Character Controller files that were modified. This 
also
fixes an issue that caused the character controller to not fall at the same 
speed for
various step heights. An effect of gravity was added; which made adding jump
functionality somewhat easy.

Original comment by ossuma...@gmail.com on 5 Mar 2010 at 5:46

Attachments:

• btKinematicCharacterController.zip

[GoogleCodeExporter]

Thanks a lot, it seems to work much better.

Applied in http://code.google.com/p/bullet/source/detail?r=2058
I'll update Bullet 2.76 release, check out later revision.

Original comment by erwin.coumans on 6 Mar 2010 at 7:39

• Changed state: Fixed

[GoogleCodeExporter]

The stair climbing doesn't seem to work anymore (only for the very low steps)

Have you tried that feature?
Thanks,
Erwin

Original comment by erwin.coumans on 6 Mar 2010 at 8:25

• Changed state: Started

[GoogleCodeExporter]

See also attached screenshot. The character used to be able to move forward 
from this 
position, by climbing stairs.

Original comment by erwin.coumans on 6 Mar 2010 at 8:46

Attachments:

• cannotclimb.png

[GoogleCodeExporter]

It seems those lines prevent the stairs climbing:

    if (dotUp < m_minSlopeDot) {
        return btScalar(1.0);
    }

Original comment by erwin.coumans on 6 Mar 2010 at 9:11

[GoogleCodeExporter]

Hi Erwin,

Sorry for the late reply, I was away at GDC the past week.

The lines you pointed out prevent the controller from stepping up on walls and 
ceilings.

I think what is happening is that the stepUp method thinks you are hitting a 
ceiling
and thus prevents you from moving on top of the step. It looks as if the convex 
sweep
hits the bottom of the step and interprets it as a ceiling.

The ceiling/wall check prevents popping through and/or sticking to a ceiling if 
you
happen to hit it, either through normal motion or jumping. This was the biggest
problem we had with the controller initially.

I will see if there is something that can be done for this without making 
assumptions
of collision geometry. However, I am pretty sure the controller would work on 
those
steps if they extended from the ground. Either way, it seems like a bug for 
sure.

Chris Rodgers

Original comment by ossuma...@gmail.com on 15 Mar 2010 at 8:10

[GoogleCodeExporter]

Hi Erwin,

I have had a bit of time lately to revisit the character controller code. It 
turns
out that the step up code in the demo seemed to work only because of the pop-up 
bug.

After that was fixed, the step up behavior appeared to break. The shape of the
controller object is a factor in the behavior; the contact normals in the convex
object sweep tests are relative to the shape. Capsules and boxes have different
collision results for sweeps and thus react differently for the steps. Changing 
the
step height seems to work for a box, though a capsule has a bit more trouble. I 
think
in the case of a capsule, it slides down the corners of steps and appears not 
to step
up. For instance, I had to increase the max slope for the capsule to 60 degrees
rather than the default which was previously 50.

The sweep tests have been modified for the stepUp and stepForwardAndStrafe 
methods.
Also, code was added to ensure that the controller can step down instantly when 
going
down steps rather than floating down them. However, make sure your step height 
is
less than half the object height or you may fall through the floor.

Please find the code attached. The stepUp behavior could still use a little bit 
more
work, but for now seems to be better than it was. You may have to change the 
step
height and max slope parameters to get different object to work with the 
controller.

Looking forward to hearing your feedback Erwin. Talk to you soon!

Chris Rodgers

Original comment by ossuma...@gmail.com on 12 Apr 2010 at 9:54

[GoogleCodeExporter]

Original comment by ossuma...@gmail.com on 12 Apr 2010 at 9:55

Attachments:

• btKinematicCharacterController.zip

[GoogleCodeExporter]

Thanks for the update. 

I hope to get some time to look at your patch and apply it.
Thanks,
Erwin

Original comment by erwin.coumans on 23 Apr 2010 at 1:17

[GoogleCodeExporter]

Hi there,

I've been following this issue as I run into the same problem with the original 
version of the kinematic character controller.

The mod by ossumajor is performing quite well, though it might have a bug 
somewhere 
that only appears when using "Z" as the "up axis". I was using the mod 
flawlessly 
until I decided to change my global world orientation, and started using Z as 
the "up 
axis"...

In this situation, having a "flat" plate with normal (0,0,1) and letting the 
character falling from, lets say, (0,0,10), produces wrong results, as it sinks 
into 
the plane, as if no collision happened ever...it seems like the collision is 
not 
detected, but the controller gets stuck into the place because of the 
"reoverFromPenetration", and once this happens nothing works as expected...

I'm trying to seek the bug but I'm a bit lost...maybe there is some forgotten 
code 
somewhere assuming Y is the "up axis", or maybe is just any other thing...

Just wanted to share this with you. I'll let you know guys if I manage to solve 
the 
problem...

Original comment by der...@gmail.com on 5 Jun 2010 at 11:28

[GoogleCodeExporter]

Hi again,

A bit more info on the "z up" issue...it only happens when checking collisions 
agains A 
PLANE with normal near (0,0,1) (same as up axis). Setting the plane with normal 
(0,0.5,1) works fine...though setting it to (0,-0.5,1) does not...weird...

Using kinematic geometries or static meshes work fine too.

Original comment by der...@gmail.com on 6 Jun 2010 at 12:08

[GoogleCodeExporter]

The most recent patch from Chris was applied back in June 2010. Some other 
improvements were made.

We should check the remaining issues on the character controller.

Original comment by erwin.coumans on 2 Apr 2011 at 12:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This patch adds proper character reset support, including the clearing of the 
related pair cache (for when collision detection filtering options are changed, 
such as to disable collisions).

Original comment by eventhor...@gmail.com on 11 Apr 2011 at 5:41

Attachments:

• bullet-reset.patch

[GoogleCodeExporter]

I'm not sure if this would be better suited for a new report, but when falling 
without jumping (e.g., walking off an edge) the character controller uses step 
height rather than gravity for the fall speed. I've attached a blend file 
showing what I'm talking about. Notice how one cube falls a lot faster than the 
other? That one has a step height of 0.4 while the other has a step height of 
0.15.

Original comment by mogurijin on 26 Dec 2012 at 1:38

Attachments:

• char_drop_test.blend

[GoogleCodeExporter]

Okay, so looking at post #8, I guess the quick drop was intentional, but it 
really screws up larger drops (not stairs). I'm using the attached patch to 
make falling feel a bit more smooth. I don't know if it's "correct", but it 
gives me the behavior I want.

Original comment by mogurijin on 22 Jan 2013 at 6:39

Attachments:

• char_fall.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is an updated patch that includes the things from my post #15, and also a 
second drop check (used to differentiate short falls from long falls, and to 
use either fast drops or slow/normal drops), a "bounce_fix" flag that is used 
to correct strange character bounces on Windows 32-bit builds from riding on 
oversized triangles (the issue is fixed on other platforms by turning on 
Bullet's double precision, but for some reason this doesn't fix it on that 
specific platform), proper falling motion, and some other stuff.  I'd love to 
hear if this fixes things for others too.

Basically the drop check determines if the fall is within the step height.  If 
so, it does an instant drop; otherwise it does the standard interpolated drop.  
This fixes situations where the character would "float" down stairs instead of 
directly stepping down each step.

Original comment by eventhor...@gmail.com on 23 Jan 2013 at 7:19

Attachments:

• bullet-changes.diff

[GoogleCodeExporter]

The patch in reply #20 much improves the char controller for me.

Original comment by c...@gmx.com on 5 Jun 2013 at 3:22

[GoogleCodeExporter]

Thanks eventhorizon005 and cand, I'll test it before next Bullet 2.x release

Original comment by erwin.coumans on 5 Jun 2013 at 4:03

[GoogleCodeExporter]

ok, patch #20 (includes #15) applied in latest trunk
Thanks!
https://code.google.com/p/bullet/source/detail?r=2655

Let's fix the issue for now.

If there are any other contributions, please open a new issue (and sorry if I 
overlooked a patch)

Original comment by erwin.coumans on 10 Sep 2013 at 8:41

• Changed state: Fixed