Re: [Algorithms] Kinematic Collision

[Jon W. <jw...@gm...>]

David Black wrote:
> Can you describe your approach in more detail? eg how the user input is
> translated into movement of the rigid body? Because approaches involving
> applying forces etc to a rigid body in order to move it have never felt
> correct for player movement etc (ie the result is too
> disconnected/soft).
>   

Well, I'm not making FPS games, so I don't need that wrist-snapping 
single-frame 180-degree turn. In fact, what we make is "down-tuned" from 
what we could make, because requirements are that it should be 
human-like (no running at 90 mph and turning at 20 g). FPS gamers 
constantly complain when they first have to use our software :-)

However, when I've done it more action-adventure style, I make the 
available propellant force inversely proportional to velocity (clearly 
avoiding divide-by-zero by adding some tuning constant to the divisor 
:-). This means that "getting started" is a lot quicker, which is 
generally the main problem. The draw-back is that you can be able to 
move really heavy things, so to work around that, I down-scaled the 
available propellant force if there was a sideways contact onto the 
player capsule. Also, no propellant force unless you have some 
upwards-facing contact (from the ray legs or from the capsule), meaning 
you have a floor contact.

In my opinion, for an action-adventure style character, that controller 
actually turned out pretty well. It also had the nice (for this case) 
side effect that you couldn't turn as quickly when running fast as you 
can when standing still, because propelling force (which turns into 
delta-vee) is less. I did allow a large amount of braking force in all 
cases, though. And in the end, it still uses a ray plus a capsule as all 
the testing needed, by being smart about re-using all the information 
you get. (I did not add two rays for legs -- that'd be an interesting 
experiment)

Sincerely,

jw


-- 

  Revenge is the most pointless and damaging of human desires.