• entries
    743
  • comments
    1924
  • views
    580402

Edge Traversal Improvements

Sign in to follow this  

1424 views

Have been spending a bit of time improving the edge traversal stuff this week. I had to make a few mods to my model editor as I uncovered some issues when trying to improve the animation, which was a bit of a side-track, but always good to get things working right in there.

The slightly improved shimmy animation requires a different animation for left and right shimmying so I added a "Duplicate Animation" option to Charm. Was then pretty easy to use the existing joint-swap features to make the right version from the left version. But may need to do something more automated in the future here, to automatically make a mirror of an animation so you only have to modify one.

I've also now got around to setting things up so that when you press direction buttons when edge grabbing, it uses the direction of the camera and the normal of the current edge to work out which direction to move. Previously this was just hard-coded to the left and right buttons, which meant you moved in different directions depending on where the camera was facing.

First up, I added a method to the base PcState that all states can access:

int PcState::shimmyDirection(float cameraAngle) const{ float dot = dotVectors(inputVector(cameraAngle), data.grab.coincident()); return dot < -0.7 ? -1 : (dot > 0.7 ? 1 : 0);}Where inputVector() looks like this:

Vec3 PcState::inputVector(float cameraAngle) const{ Vec3 v(0, 0, 0); Vec3 look, right; cameraFlatVectors(look, right, cameraAngle); if(data.controls.down(PcControls::Forward)) v += look; if(data.controls.down(PcControls::Backward)) v -= look; if(data.controls.down(PcControls::Left)) v -= right; if(data.controls.down(PcControls::Right)) v += right; return normalizeVector(v);}Essentially it takes the dot product of the direction currently being pressed, with respect to the camera angle and a normalized vector running along the current edge. If you are facing directly into the edge with the camera, behind the player, this will return -1 or 1 for left and right, and 0 for forward and backward, where left, right, forward and backward are relative to the camera angle.

To make life a bit easier when edge traversing around corners, the ShimmyState is set so it can only stop shimmying if the normals for both hands are pointing in the same direction with a small tolerance. Inside the ShimmyState update method we have:

if(!shimmyDirection(params.cameraAng) && std::fabs(data.grab.dotNormals()) > 0.9f){ machine.setNextState(PcState::Grab); return;}I.e. if the player releases the direction keys, keep shimmying in the current direction anyway until the two hands are both on edges with roughly the same normal. This saves an awkward situation where the player would have to change keys at exactly the right time while moving around a corner.

I also changed the size and shape of the capsule that is used to do collision checks during shimmying, so the problems I mentioned last week are no longer an issue. You see at the end of the video that he can shimmy around the quite complex geometry on the little island at the bottom of the map. Basically its just a smaller capsule than the main capsule used for the normal player collision detection, and seems to work fine.

Still not completely happy with the animation, but think it is as good as it will get with this character. I really need to start on a new model that is a little bit easier to pose, but that is a great deal of work so am going to stick to mechanics for the time being.

Thanks for stopping by.

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now