Should you use the kinematic character controller?

Post Reply
Yelnats
Posts: 1
Joined: Wed Aug 21, 2013 8:35 pm

Should you use the kinematic character controller?

Post by Yelnats »

Hello, I am currently new to bullet. I've begun to grasp the basic concepts of it, however my progress has come to a standstill. I am unsure how to control a character. Original it was a single rigid body, a capsule. However, this prevents useful control such as slope handling (whether to stand still or slide), walking up and down stairs, and flying off of slopes when going up at a fast speed. This led me to research the kinematic character controller. The manual says that it has several outstanding issues. I have tried to implement it, like many other, and have found issues. I am using blender and importing .bullet files from it. My first hold back was that gravity as well as hitboxes were screwed up, but after some evaluation it was found that the blender export has to be rotated -90 degrees due to the XYZ coord differences (blender seems to use a right handed system that is rotated 90 degrees along the X axis). This is the code I use to create the controller:

Code: Select all

playerShape = new btCapsuleShape(0.25, 1);

btTransform startTransform;
startTransform.setIdentity ();
startTransform.setOrigin (btVector3(0, 10, 0));

ghostObject= new btPairCachingGhostObject();
ghostObject->setWorldTransform(startTransform);
ghostObject->setCollisionShape(playerShape);
ghostObject->setCollisionFlags(btCollisionObject::CF_CHARACTER_OBJECT);
controller = new btKinematicCharacterController(ghostObject,playerShape,1);
controller->setGravity(-physics.getWorld()->getGravity().y());

physics.getWorld()->addCollisionObject(ghostObject,btBroadphaseProxy::CharacterFilter, btBroadphaseProxy::StaticFilter|btBroadphaseProxy::DefaultFilter);
physics.getWorld()->addAction(controller);
Right after I create the broadphase in the physics class, I also declare this:

Code: Select all

broadphase->getOverlappingPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
At first I had issues with the imported .bullet file. The ghost object, which I use to get the location of the player, would slowly sink through half of an object, then simply fall through as if it wasn't even there. This was fixed by manually setting the "Collision Bounds" for each object in blender.

Now the issue lies in the player stepping down on places where they should fall (heights higher than the step height). Another issue is that it sinks through the floor at certain points (this floor is not created in blender, but rather created before as a plane 100 by 100). The third and really the biggest issue is that it doesn't always step up. This is observed in both imported and non-imported objects, though it is more visible in imported objects (however this could be an ocular error as the non-imported objects are currently invisible). It fails to step up and bumps against the wall of the object.

The way I move the controller is through

Code: Select all

controller->setWalkDirection(btVector3(right, 0, forward));
and I jump through

Code: Select all

controller->jump();
The way that the coords are obtained of the controller is through the ghost object:

Code: Select all

btTransform trans;
trans = controller->getGhostObject()->getWorldTransform();
I would really appreciate some help, as I am a newbie in both bullet and 3d collision detection in general.
labidus
Posts: 7
Joined: Sun Aug 25, 2013 12:40 am

Re: Should you use the kinematic character controller?

Post by labidus »

I am new too (bullet) and I wanted to use the kinematic character controller for an FPS game, but it just not working well, the camera is shaking (all the time) even if the character is not moving, so I think now this class is just good for outside character view, like RPG game, even if I set the walk direction to 0, 0, 0 in a slope, it move. Anyway just the shaking make me sick, I cannot use that, it just not working well. (shaking a few pixel, its like the character penetrate the ground and return back to the position), if I set something in stepHeight its worse, i need to set this to 0.

I believe you need to handle it manually with a rigid body, but i did not really try, I am in the process of looking at it.

Also I try the BspDemo way to load the brush (planes) converted in hull shape, but it is not working well, I can pass true wall quite easily, its quite useless, so now I load all the faces to get a correct collision detection but the interaction with the character class is pain in the ***.

Maybe someone have the same issues? what is the best way to get a correct collision interaction in the world from a FPS point of view?
labidus
Posts: 7
Joined: Sun Aug 25, 2013 12:40 am

Re: Should you use the kinematic character controller?

Post by labidus »

I tried the rigid body solution and it work quite well compared to the kinetic solution.

I also find the problem with the bsp demo brush, i was wrong it work very well too.

I based my code from this sample:
https://github.com/222464/EvolvedVirtua ... ntroller.h
https://github.com/222464/EvolvedVirtua ... roller.cpp

I changed a lot of stuff to make it more like i wanted.

But even this solution does not work with stepHeight, just forget the stepHeight, put zero if you don't want a shaking camera
MaxDZ8
Posts: 149
Joined: Fri Jun 24, 2011 8:53 am

Re: Should you use the kinematic character controller?

Post by MaxDZ8 »

The main problem regarding kinematics is that they are game-dependant and even context-dependant. Personally I believe the provided kinematic controller should be seriously downtoned.
I am surprised to keep reading about people using dynamic objects instead of kinematics and finding them a good solution. I spent at least one whole month trying to make them work as intended with no success.

Back to OP, I also had experienced the "slow sink" problem you describe. It turned out it was the result of both simulation and de-encroaching. What happened in my case is that simulation would cause the kinematic object to fall. I would only sweep kinematics only if exceeding a certain threshold, thus the following de-encroach pass would detect the object as encroached and push it out.
The system had a logic bug: falling speed would not be zeroed out in those cases.
The result is that the following frame the object would get detected as floating and simulated to fall with a greater movement. Eventually encroaching would grow up so much that it would cross "floor" midpoint. This would cause the de-encroach pass to push it out the other side.

I solved it by taking advantage of tolerance margins - I also rewrote the systems to be more integrated.
Post Reply