Page MenuHome

"Character" object physics type
Closed, ResolvedPublicPATCH


This patch adds a new "Character" BGE physics type which uses Bullet's btKinematicCharacter for simulation instead of full-blown dynamics. It is appropiate for (player-controlled) characters, for which the other physics types often result unexpected results (bouncing off walls, sliding etc.) and for which simple kinematics offer much more precision.

"Character" can be chosen like any other physics type in the "Physics" section of the properties window. Current settings for tweakingare "Step Height" (to make the object automatically climb small steps if it collides with them), "Fall Speed" (the maximum speed that the object can have when falling) and "Jump Speed". The latter is currently unused, but can be utilized for a new "Jump" Motion Actuator. If there is interest, I can create another patch for this and append it here; otherwise, the setting can be removed.

btKinematicController itself still seems to have some issues and doesn't work quite perfectly. I am willing to try fixing some of these if there is interest in including the patch.

Event Timeline

You might want to submit a sample file. This helps a lot in testing out the patch.


to facilitate the patch approval I have updated (rev43212) and uploaded the patch. Also, I have uploaded a blend file for test and I have published a video ( showing the new "Character" BGE physics type in action.


I looked at the patch, it looks quite ok.
I found some identation errors in the python UI code and a bug in bullet when the obstacle is a static mesh. I have updated the patch for reference only, I will commit it as soon as 2.62 is out.
I noticed in your demo that the obstacle uses the convex hull shape that turns any step into a slope. The character is then able to climb the slope unless it is too steep. If I change the shape to static mesh, it doesn't seem to be able to climb any step, even a small one. I'm not familiar with the character controller, maybe it has some bugs or limitations. Are you aware of anything?


just to remark. I am not the author of the patch, I have only done the video and update the patch.

I am checking the patch a lot in the last week and I had the following issues:

- If in the "character" object you select "triangle mesh" as collision bounds you will have a segfault
- If in the "character" object you active "compound" at collision bounds you will have a segfault

- If you put the "step height" higher than half the height of the character object, the character object may pass through the floor. This seems to be an issue in bullet.
- The step climbing depends (in order of importance):

Sorry, I press "save changes" by mistake.

I follow:

- The step climbing depends (in order of importance):
- The velocity of character object (i have attached a blend showing it)
- The margin of collision bounds
- The step height parameter
- If it exists a slope before the step (there is a different behaviour if you put the slope in a separate object)

- The fall speed depends (in order of importance):
- the step height (more step height more fall speed)
- Fall speed parameter (not very representative)

I have seen another implementations and almost all of them set the WalkDirection (this parameter isn't only the walk direction, It is a s a kind of walk direction multiplied by the walk speed. Maybe setting this parameter and the Max slope one we would have an improvement in the behaviour.

@Benoit: To your question, try incresing the velocity of the character, incresing the step height and decreasing the margin of the shape and character. In the new blend attached you can see that the shape is a "triangle mesh" and the character can climb several steps.

Thanks for the new blend. It shows that velocity is by far the main factor for climbing steps, which is not that great because it forces the character to run like crazy to climb even small steps. Maybe the new bullet 2.8 will improve the situation.
Anyway I have committed the patch in revision 47140 with a reference to this report in the commit log.

Benoit Bolsee (ben2610) changed the task status from Unknown Status to Resolved.May 28 2012, 11:40 PM