simple character movement

[mike1]

Hi everyone,

In my game today I'm controlling character movements via setting their linear velocity. From what I read, this isn't ideal because it's affected by the frame rate (and indeed that's what I see). I'm now at a stage I'd like to change this behavior.
My requirements are fairly simple (to me):
1. Be able to limit the maximum speed of a character
2. Be frame rate and CPU independent

It is OK if it'll take some time for the character to reach the maximum speed, and it's also OK if it's immediate.

I played a lot with it, trying to restrain RigidBody's applyCentralForce() and friction without success. I always end up being able to reach indefinite speeds.
How would you do limit the max speed?

Thanks!

[mike1]

i guess the reason no one answered is that this post is lacking info; i'll elaborate:

if i'll only boost the character when the speed is below the maximum, i'll end up having an object that sprints every few minutes to above the limit, then slowly slows down to the limit, and over again. this isn't ideal, as its not the way people usually walk.

do you usually play around with the friction and force so that there's a de-facto maximum speed (at least when not down heal)? if so, can anyone please provide with such values? if not, how would you cap the speed?

thanks!

[N_K]

I'm not an expert, but I've played around a dynamic character controller similiar to the one you've described.

And I don't really understand this problem. If your simulation runs at a fixed timestep, linear velocity shouldn't be affected by the framerate (except in very extreme conditions, like below 5 or over 1000 FPS), or at least this is what I've experienced when I limited/raised the framerate to see how the character will behave.

Neither I understand how can your character move faster than the velocity you're moving it with. And what do yo do when there's no user input? Do you reset/limit the movement, either by applying zero velocity, or setting up its friction to make it stop/slow down?

Anyway, an expert's opinion would be very much appreciated, I'm curious about this problem as well (it seems it could affect my character controller as well).

[mike1]

from my understanding, setLinearVelocity() is framerate dependent (see here: http://www.bulletphysics.org/mediawiki- ... e_Snippets for example)

what i was trying to say is that the character moves faster than the limit when i play around with applyForce(). i didn't encounter a situation in which the character moved too fast when i manually set the linear velocity (it did move slower on slower frame rates - see above)

any thoughts?

thanks!

[Flix]

My requirements are fairly simple (to me):
1. Be able to limit the maximum speed of a character
2. Be frame rate and CPU independent

Not an expert myself about this topic (and I guess you should really do some tests on two machines with different performances to be sure about the framerate issues...). What I'd try to do is:
1) clamping the linear velocity if higher than a certain value should work as far as I know...
2) it all depends on how you process the input: what I mean is that if you process the input at a variable time step, and you apply some forces when a key is pressed, the forces keeps summing up (AFAIK) and in the next physic time step you get bigger forces on faster PCs. To avoid this problem you can either process the input at a fixed time step, or just "store" the key state and retrieve it in a "physic tick callback", where you apply impulses to the bodies (I guess the latter approach is the more common).

I'm not sure that kinematic bodies should be moved this way; I don't use them very frequently and when I do I simply set their position in the main loop (I think this way their position can be "interpolated" by Bullet, but I'm not sure if this is framerate dependent or not).

Anyway as I told you at the beginning I'm not an expert about it, and I think that without testing it on different machines nothing can be taken for sure...

In any case the simulation will be "physic tick dependent"... but this is another problem

[Flix]

My requirements are fairly simple (to me):
1. Be able to limit the maximum speed of a character
2. Be frame rate and CPU independent

Not an expert myself about this topic (and I guess you should really do some tests on two machines with different performances to be sure about the framerate issues...). What I'd try to do is:
1) clamping the linear velocity if higher than a certain value should work as far as I know...
2) it all depends on how you process the input: what I mean is that if you process the input at a variable time step, and you apply some forces when a key is pressed, the forces keep summing up (AFAIK) and in the next physic time step you get bigger forces on faster PCs. To avoid this problem you can either process the input at a fixed time step, or just "store" the key state and retrieve it in a "physic tick callback", where you apply impulses to the bodies (I guess the latter approach is the more common).

I'm not sure whether kinematic bodies should be moved this way or not; I don't use them very frequently and when I do I simply set their position in the main loop (I think this way their position can be "interpolated" by Bullet, but I'm not sure if this is framerate dependent or not).

Anyway as I told you at the beginning I'm not an expert about it, and I think that without testing it on different machines nothing can be taken for sure...

In any case the simulation will be "physic tick dependent"... but this is another problem

[sparkprime]

I wrote a simple character controller as a scripting example for my game engine project. It uses Bullet but uses casts (of cylinders). You may be interested.

http://www.gritengine.com/

http://gritengine.svn.sourceforge.net/v ... iew=markup

[STTrife]

I would also think clamping the velocity at each tick would be a good solution, then you can ensure it never goes faster than your max. Also you could try applying the force relative to he difference between the current velocity and the max velocity (the closer to max speed, the smaller the force applied). That should also stabilize it.