Jump to content
  • Advertisement

Michael Valle

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

114 Neutral

About Michael Valle

  • Rank
    Newbie

Personal Information

  • Interests
    |programmer|
  1. Michael Valle

    Character Controllers - what do YOU use?

    Great stuff, people! Thank you so much for your descriptions!    Please keep them coming.  :)
  2. So, I naively thought implementing a character controller with the Bullet Physics would be quick, simple, and there'd be a "one size, fit all" approach.   Boy was I wrong...   I have been scouring the web for details of tried and true implementations, but am quickly seeing its something that needs to be tested and calibrated per game. I think people just apply a lot of experimental tweaks and don't always share the details. So I just wanted to see what other people are doing to give me some baseline approaches.    My main questions are the following but you can provide as much detail as you wish:   1. How do you model your collision objects for your character? 2. Do you use a dynamic rigid body, or a kinematic object? 3. How do you apply force/velocity/position updates and resolve collisions? 4. How do you drive the motion of the character with scripted animation? (For example, if there is a dash forward and strike animation, make sure the physical object moves forward, and follows the slope of the ground) 5. What do you think are the strength and weaknesses of your approach?   Right now I am particularly curious about how some people use a capsule that is "sitting" on one, or several ray casts, as this seems to be the most common approach. My understanding is that a ray cast is just a means of measuring distance (and getting collision info) so I don't know exactly how height is maintained (setting position, velocity, force? etc.). Do you use a kinematic object for this? How do you handle collisions? Etc. and so forth..   Any details or insight in this matter would be appreciated. From what I gather, this is quite a "black art" and it can consume a lot of time. Trying to avoid this problem eating my life. 
  3. Thank you for that detailed response!   I am still doing some research and piecing together an approach, using elements of what you described and some others.   Here are some good details of an approach using ray casting. This is described as "the general approach" which is what I'm more or less looking for here. I'm wanting to implement a "tried and true" technique, not something too original.    https://groups.google.com/forum/#!topic/ode-users/mkbwSymDRm8   What I'm not sure about with this is how they resolve the ray cast collision. Do they just apply forces to adjust the height of the capsule so its always suspended at the appropriate height above the ground?   I wonder if it would make sense to suspend gravity on the capsule and just have a check to see if there is ground beneath the object, and apply gravity forces only if not.   Here is some pseudo code for the general approach I'm thinking of so far. It is intended to support moving platforms. I leave out some of the logic you describe about updating the animation, and the threshhold, etc. Just thinking about the capsule physics mainly, at the moment... It is assumed that gravity is disabled on the capsule object.  heightOffFLoor = doRayCastToGround(); desiredHeight = getDesiredHeight(); delta = desiredHeight-heightOffFloor; applyForcesToShiftHeight(delta); // apply just enough force to move the body up by delta target_velocity = base_velocity + (isOnGround ? groundSpaceTransform: Identiy) * getVelocityFromAnimation(); current_velocity = body->getLinearVelocity(); applyForcesToChangeVelocity(current_velocity,target_velocity); if (isOnGround) { base_velociy = groundBody.getVelocity(); } else { base_velocity += gravity; } Note I use "base_velocity" to control both the added velocity of a moving platform, and also gravity when there is no platform. I also make use of the ground transform (derived from the contact normal in the ray cast) to make sure that the motion follows the slant of the terrain.   Does this seem like a reasonable approach?    (edit) Also, not sure exactly how multiple ray casts would be handled, since it mentions that using just one ray can get the object stuck....
  4. That sounds reasonable..       What's the difference between "compensate for the error in physics" and "change the animation" in what you describe above?     My only other concern is moving platforms when computing the target velocity. I suppose I could compute this as (target animation velocity ) + (velocity of platform). By clamping the resulting force within some threshold, this would allow for some realistic sliding of the character if they were to land on a platform with a considerable difference in velocity.   Do you think this would work with the approach you described?
  5. Thank you for that detailed response!     That sounds very doable for a basic walking/running animation.   I guess my concern is how precise this  will all be for more complex animations, and if the physical corrections per frame are going to accumulate and mess up the look and feel that the artist creates. Or, if I ever need the animation to be precise. For example, maybe I need the character to leap a certain distance, or climb up on a ledge or something. The bounding box would be following a specific path, and I would have to accurately compute the forces to apply to the object to move it along this path.   The simplest approach for this I could think of is: 1. compute the desired change in position for the capsule at each frame of the animation, and record that as velocity. 2. compute the change in velocity for the capsule at each frame of the animation, and record that as acceleration. 3. apply force = mass*acceleration to the capsule at each frame.  The good thing is this calculation could be pre-computed for the whole animation, but this would certainly not be 100% accurate, estimating velocities and accelerations in this matter. Certainly the position of the animated character could be "corrected" at the end of each frame, but I wonder how much the resulting animation will differ, with these mild discrepancies adding up, potentially messing up the appearance of the animation. More sophisticated, numerical approaches could be used to calculate the appropriate acceleration/force I guess, such as taking the Fast Fourier Transform, and then computing the 2nd derivative. But this all seems like overkill.   Does the above, 3 step approach seem like it would work well enough? Guess I don't yet have the experience to know if good enough is good enough..   (edit) Friction still creates a big problem with the approach above though. For a walking animation, for example, the above calculation would only produce enough force to accelerate the character to walking speed and then no more force would be applied, and the friction would quickly stop the motion. A compensating force could be added to counter-act the friction, but I'd have to calculate the exact amount of force to add, and do it only when the character is in contact with the ground....   Sheesh this is getting quite complicated for something I thought would be rather simple.. 
  6. I am trying to implement a simple collision capsule so my animated character will be able to physically walk on the ground, bump into walls, etc.    My original approach was the following:   1. The character is positioned and animated relative to a root transform R. 2. Let the position of the capsule, P0 be either explicitly defined by the animation (via keyframes), or computed from the characters position. 3. Execute the bullet simulation step to derive the corrected capsule position, P1 4. Multiply R by Delta(P0, P1 ) to correct the position and shift the character.   Or in plain English... determine where you expect the collision capsule to be from the animation, determine where the capsule ends up (after forces, and collision resolution), and shift the character's location accordingly.    A problem arose with 2, because I found that Bullet does not easily let you just re-position a rigid body in this manner. I would have to remove and re-add the body to the simulation for this to work and i'm worried that this will be an issue with speed and stability. I don't think Bullet is meant to be used in this way.   A potential solution is to set the capsule's velocity equal to Delta(P0, P1 ) at every frame (I like this idea because then it gives the capsule the appropriate momentum and it would realistically knock another lose object around if you ran into it). But then the problem becomes friction. If I set the friction to 0, the capsule will slide everywhere and not grip the surface. But if I use non-zero friction, then the shift will be dampened and not correct.    Am I using an outlandish approach for this? Can anyone suggest a better way?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!