Animations 2013

[raevol]

Can't wait to see the progress on this. Super super excited.

[jhooks1]

In the new character controller, will the bip01 current rotation rotate the collision shape around all 3 axes (yaw, pitch, roll (do we need roll?))? In our newtrace for pmove, we never actually factored in rotations in the trace (so in reality the box didn't actually turn, its direction just changed). I am sure there is an easy and sensible way to do this though. This is all very interesting.

[Chris]

In the new character controller, will the bip01 current rotation rotate the collision shape around all 3 axes (yaw, pitch, roll (do we need roll?))?

It doesn't currently. We aren't handling rotation via the mechanics manager/character controller/physics, which is where the animations and its results are handled.

Does vanilla accumulate rotations? I'd need to look at vanilla's collision grid and how it works with various character animations and actions.

[Chris]

If anyone has any info on how Morrowind handles animation accumulation, I'd be grateful. But currently I see no pattern in how and when it decides that an animation drives movement.

I remember LizTail mentioning having accidentally caused an actor to remain stationary because a replacement animation didn't move them. That at least tells me it won't cause movement when it's expecting the animation to do it. But that still leaves so many unanswered questions in when or how it expects an animation to move. Or how it handles it when an animation moves in the "wrong" direction.

Currently the way I have it is:

Code: Select all

    Ogre::Vector3 movement = Ogre::Vector3::ZERO;
    if(mAnimation && !mSkipAnim)
        movement += mAnimation->runAnimation(duration);
    mSkipAnim = false;

    if(!(getState() == CharState_Idle || getState() >= CharState_Death1))
    {
        movement = mDirection * movement.length();
    }

    return movement;

Where 'runAnimation' returns the movement vector as caused by the animation, and mDirection is the wanted direction vector (normalized). The returned movement then gets passed to doPhysics for actual movement calculations.

That 'movement = mDirection * movement.length();' part, however, does not seem to be correct, but I'm unsure how else to do it so moving diagonally and flying up/down works. It basically makes it ignore the direction the animation moved, and applies the animation's movement "speed" to the wanted direction instead.

This causes problems with the idle and death states as they won't have a wanted movement but still do move (currently special-cased to get around that). It also makes it so an animation can only move in one direction; for example, when walking forward any side-to-side movement is purely cosmetic and won't cause collisions.

[jhooks1]

It also makes it so an animation can only move in one direction; for example, when walking forward any side-to-side movement is purely cosmetic and won't cause collisions.

I'm thinking about this, the normalized vector method you are using may be right in this respect. If you think about it one frame with the side to side movement may be forward with a slight left, the next frame forward with a slight right. Essentially the character is zigzaging. I may be completely wrong here.

EDIT: See what is going wrong now

[jhooks1]

Can you do movement * QUATERNION (for mDirection)? I think that may work and allow unique zigzaging.

[Chris]

Can you do movement * QUATERNION (for mDirection)? I think that may work and allow unique zigzaging.

I'm not sure what you mean. The problem is you have the animation moving one way (which can change slightly over the course of the animation), while the character wants to move in another way. So either you move in the way the character wants, meaning you can't properly zig-zag with the animation, or you move in the way the animation wants, meaning you can only move how the animation does.

[jhooks1]

Hmm...

I meant that you could change mDirection from a normalized vector into a rotation.

Then do:
movement = mDirection * movement;

Not sure if this would help anything now though.

EDIT: So you are not taking the length anymore.

[Chris]

Hmm...

I meant that you could change mDirection from a normalized vector into a rotation.

Then do:
movement = mDirection * movement;

Not sure if this would help anything now though.

EDIT: So you are not taking the length anymore.

That may work for forward movement, but sideways or backwards would break (e.g. you'd have the movement going backwards, then the direction would also rotate backwards to turn it forward instead).

[jhooks1]

Backwards shouldn't break, the calculation should work. Your quaternion is pointed in a good forward direction, but movement will be somewhat negative. Then they are multiplied together.