Bullet Physics for Characters

Game Engine Game Engine Support and Discussion
1

Hey guys,
I’m still trying to figure this out. How can I get Bullet to play nice with “characters?” By my definition, a character must:

  • Never fall over
  • Be able to climb all slopes (unless they are vertical of course)
  • Be able to rotate without sliding along the ground
  • Be able to stop linear motion and rotation at a moment’s notice (ie no momentum)
  • Collision sensitivity (this should be obvious)Okay, so that’s my list. Unfortunately, Bullet cannot (as far as I can see) natively support all of these characteristics. Do you know how to implement this? I’ve tested this file in the Bullet preview versions and Release Candidate 1, but the result is far from satisfactory, especially as far as the rotation/sliding problem is concerned. A script is not a satisfactory solution, at least in the long run. (They are not easy to implement, are not included within Blender, and sap processing power).

Let’s use this thread to speculate, plan and discuss character physics in Bullet.

2

For me, if I maximize the Form factor, and up the Dampening and RotDampening, I generally get a really good effect.

3

I have both dampers on 1.00 and still it’s not enough

4

Wasn’t Erwin going to soon implement proper character control for the Bullet system?

5

I was just about to make a topic asking this very point! I’ve used form, mass, dloc, force, dloc and force anchors, altered scale, resistance, no combination seems to get a totally ground-bound, no resistance (mesh vibration), life-like gravity effect. None of the BGE related forums I’ve searched seem to have the perfect solution. Till I can find a resolution for it I’m gonna have to keep with Sumo.

6

I don’t know what version of Blender you are using, maybe 2.42a, but Bullet physics for characters is great in 2.43rc1, with the following exceptions:

Friction causes character to stray from path; [http://members.shaw.ca/chasey/media/FrictionProblems.mov](Click here for video example)

Damping doesn’t work.

Also, blender 2.43rc1, at least for me, is EXTREMLEY UNSTABLE, it shutdowns almost every 5 - 10 minutes.

7

In the old blender versions, a simple hill would cause my character to slide all over the place. In the 2.43 RC1, he doesn’t exhibit any of that behaviour.

The solution for me was to take an empty and set it to dynamic. Then I parent my armature to that, and my model to my armature. Its very important to set the armature and the model to Actor/Ghost without setting them to dynamic.

In other words, ur empty will use whatever bounds and controls to move around ur character. And with the new improved RC1, the character moves remarkably well for me and i’m an idiot.

Good job Erwin!

my character moves without any of those issues u’ve mentioned. which is funny because I had a post myself on the previous release where I couldn’t get my armature to control properly in the GE. So, anyway, with those techniques it works fine in 2.43 RC1 for me.

I think. Oh well, but I also think it uses about 2x as much processing power on physics now, or more. Because my physics % went from about 5% to 14% on a very simple scene of a dude walking around a field.

Edit: make that from about 6%-20% and there is only 1 dynamic object on screen right now. But when u think about it u shouldn’t really rely on in game physics too much anyway unless its a pool game or hockey or something.

Also, i noticed that when I have about 6 of said armatured characters on screen at once, even without physics applied the perfomance suffers a considerable hit. In other words, too many armatured characters on screen at once seem to skewer the frame rate MUCH faster than when I add more polygons.

For example - with 1 rigged character I can have about 30,000 polys on screen at 60fps.

with 5 rigged characters it’s more like 5,000 polys.

which basically to me means that poly counts are not the primary perfomance consideration by a long shot anymore… if it ever was

8

http://blenderartists.org/forum/showthread.php?t=84015&highlight=game+character

download my blend. It has my character run around setup. I use some cheap tricks mentioned in old threads to create some of the things you want. But anyway look through the logic bricks piece by piece after running the character around for a bit and you’ll see what effect i got.

9

yeah, I checked my blend again and its getting some very severe slowdown from armatures that don’t have anything to do with polycount. With 3 armatures my game is basically 10fps.

10

Yes, these are the problems. Aside from that, the support is great.
Is there any chance of resolving these issues before 2.43 goes to release?

11

T’was a good theory MagicMyshu, however that sequence of parenting has no effect for me in 2.43RC1, same problems as using the armature for control. Really RC1 was the only reason I’m revisiting this idea in bullet, I can’t remember I time where I ever got the right results with a third or even first person bullet set up. Nor am I getting any fps loss importing complex projects from 2.42 to .43RC1. Or even any instability, indeed, aside from the same problems with bullet as there were in .42 I seem to have a release stable version of RC1. Must be a more specific cause to the fps loss and instability problems.
EDIT: Then again, I just tested jessegp’s blend at 15fps in RC1, I always used object IPO sequencing for my mesh animation, rather than armatures for the very reason of memory. It seems RC1 does have a major fps problem with a small number of armatures.

12

its not theory its fact. i’m using it right now - maybe I didn’t say it right.

Basically you take an animated armatured character and then parent it to an empty. It works fine. I’m not lying!:slight_smile:

13

Just double checked to be sure, force, linV, dloc, nadda. Can’'t get it to work my attaching armatures to the mesh then bounding the armatures to an empty (Using the empty as both bounds and control). I think maybe you’re using dloc for the control, that works fine till you hit another large solid object, then you get force feedback. However if I’m in the wrong, a blend would help me out.

14

lin V controls the amount of inertia behind your movements, while dloc is the actual movement.

So i have my inertia set to something realistic (quite low). While my dloc is the speed that I actually want to move.

15

Actually linV can be used for movement controls on its own, but my point was more Dlocs effect on other objects. Try crashing your movement object into a normal unbound 2d wall, see the result. That’s my current problem with Bullets dloc. One way to get around it, is to have collision reaction with downward force on the walls, however that would cause no end of problems with any ‘floating’ reactions.

16

yeah inertia is movement

17

I don’t mean to be rude Magic, but you’re totally missing the point. Here’s a blend made in RC1 with a simple character rig in a box using dloc, try moving the character to the walls of the box.
http://www.savefile.com/files/393274
The second problem, any extra downward force of the object to stop the ‘Rubberband’ effect when hitting other objects causes friction, ‘jittering’ the mesh.

18

in my blend, I posted link to the thread where it is above

I’ve taken care of the motion using linV. I’m faking a stop velocity using a -.001 velocity on the character when there is no running button being pushed. Therefore the .001 velocity replaces the objects inertia so no slide affect.

By using the linV you can alter the rate a character can move on surfaces using different friction factors. And by setting up a property of the actual ground. You can check for collision with planes that have the ground property. The ground property will trigger the zero velocity.

edit scratch that
You can set up a swap method of imposing an initial velocity then a constant force. The friction factor of the surface will affect the velocity resulting only from the force. The way I did it in a previous test blend was when I pressed up, a lin velocity was applied, a force was applied, and a property gained a value of one.

The lin velocity was setup so that it would only apply the linear velocity if the property value was less then two. That way the character would recieve the initial velocity, this means that the character will not move very slowly when i first hit the button waiting for a force to overcome the contact friction and the character to reach its maximum velocity, the force is such that with the friction the maximum velocity is equal to the initial velocity. Then when the button is not being pressed you setup a velocity of -.001 and reset the initial velocity controlling property.

Then for ramps and such you can setup different initial velocities and friction factors. <---- combersome suck method.

I perfer using just a linV to move the character around so that I have good collision detection and no bouncing off of walls.

19

Thanks jess! That’s the resolution I was looking for.

20

never fall over - don’t enable or disable “rigid body” can’t remember which way to make this never rotate due to physics, but that the option to stop it.

climb all slopes - using the small velocity trick and linV to drive all motion this can be done just make sure your ramps are using the same property as the ground property that gives you the small stop velocity. (gets kind of ugly when you are climbing 70+ degree ramps) Then for ramps you don’t want to be able to climb don’t include the the ground property mentioned above)

no rotation slide - use drot to turn your character

no momentum crap - mentioned above

by collision not sure if you mean not going through walls or not.

but like i said check my blend throw some walls and ramps in it works rather well as far as i can tell