Animations 2013

[Chris]

Moving all relevant discussion to a single topic, which will hopefully make it easier to keep track of.

I've got the time to try working on this again. However, to get this working, it will require changes to other subsystems and how they interact with object. Here's what I can think of so far:


1. The animation classes need to be split.
Currently the classes handle skeletons, animations, and mesh instances (entities) all in one, but the skeletons and animations have importance beyond just rendering the meshes.

The whole job of animations is to move nodes, and a skeleton is nothing more than a node tree that represents parts of the object. Anything that moves nodes should fall under being an animation, regardless if it's done dynamically (e.g. gravity) or canned (e.g. pre-made skeletal animation), or both. This is separate from rendering because it has non-rendering implications: where collision is rooted, where a sound comes from, where attached objects appear, where the center of the object actually is, etc.

The animations also contain metadata necessary for performing functions, such as saying when a weapon is (un)readied, when an attack strikes, when a projectile is fired, what strength an attack has, what sounds to play, etc. These make animations more integral to the core engine, as it would have to talk to other subsystems.


2. Actor controller needs to use animations to move objects.
Like I said above, the job of animations is to move nodes. The placement of objects, and various object parts, is handled by nodes, so whenever objects move you are animating them. As such, anytime an actor thinks to move, it should tell the animation controller to actually do it. This includes the player, as they're represented by an object just like anything else.


3. Physics should not move objects.
Since the animation controller should be used to move objects, the physics system just needs to help sort out the resulting collisions. It shouldn't attempt to move the object itself, as that's the job of the animation controller.


Now that the explanations are out of the way, here's what I can say:

For 1, I should be able to do this. I'd just need to know where the animation controller should go. In mwmechanics? Or a whole new subsystem?

For 2, this is where I'd get stuck. I could handle doing the animation controller interface to make objects move correctly, but I wouldn't know how to get the engine to use it. I'm not familiar with the player input/AI to know what causes what to move.

For 3, this is also something out of my league. The way I imagine it to work is, the animation controller is told to move an object, it then runs a physics simulation to see where it can or can't go, then does the actual move. This will likely cause a lot of the physics code to get tossed out or rewritten since it's not touching the object directly anymore, and isn't directly moving objects anymore.


If anyone can help with these tasks, or provide further insight, please do. I'm still fumbling around in the dark, just trying to figure out how things should work conceptually, given what we know about Morrowind's (and to a degree, Oblivion's and Skyrim's) animations.

[jhooks1]

3. Physics should not move objects.
Since the animation controller should be used to move objects, the physics system just needs to help sort out the resulting collisions. It shouldn't attempt to move the object itself, as that's the job of the animation controller.

Are we talking actors here or objects?

If we are talking about actors, I do not agree. I think that pmove or something similar is necessary. I think there are two positions, the scenenode position and the physics actor position. The scenenode position/visual position would be offset from the physics position. The animation itself plays and the actor looks to the human eye at the physics position.

There are extremely complex concepts going on within pmove that are necessary. Many physics things do not even involve animations at all, such as sliding down a hill, the bones are just set in position.

[jhooks1]

While sliding down a hill, the physics controller is doing the work here. I was incorrect to say the bones are static though, an idle animation is being performed. Physics is influencing the movement though.

EDIT:
Depending on the steepness of the slope, that determines the movement of the player (or actor). Obviously on relatively flat ground (doesn't have to be perfectly flat) there will be absolutely zero movement, only an idle animation.

EDIT2:
This is not the only situation like this, there are many more. There is a lot going on behind the scenes with physics.

[jhooks1]

To expand more:

There is a trace going on, this actually interfaces with bullet and the physics world. The physical world is made up of objects that at the moment, do not move. Really for our purposes, only actors should be moving around within our physics world.

The trace simply checks for a collision with the world, the parameters are
1. Actor 3D bounding box
2. From (Vector + Rotation)
3. To (Vector + Rotation)

The actor can and must interact with multiple planes at once. A trace simple on our end, like 20 lines of code. Bullet handles the rest for us.

Pmove is actually like 2000 lines though, and many traces are being done to handle one actor on a single move.


We tried bullets kinematic controller before, before pmove was in the project. It is not good and too generic for morrowind anyways. Tom tried it as well, other devs have tried it (for a variety of projects), it is not a suitable solution. Traces interacting with a physics controller at a higher level is the way to go.

[jhooks1]

Also I am aware there are objects that go through animations as well. I think I actually made a comment somewhere in the code for the new npc/creature collision shape task.

Perhaps these objects do move slightly within the physical world. Things such as canton waterfalls and shop signs. There is simply not enough research done in this area by us (with Morrowind) in this area to know. If they do move though, these objects would not use pmove or anything like it.

[jhooks1]

Animations and physics do cooperate with each other though. I would more likely use the analogy though that animation is affecting the desired velocity movement of pmove. Even if animation sends pmove flying into a wall, the animation still plays and pmove still tries to get through that wall.

EDIT:
If an actor tries to jump though, it is up to the npc's stats, they influence the jump velocity. Once our npc is up in the air, it is entirely up to the physics controller on what to do. Animation gets no say.

[jhooks1]

I thought this old email I got from Tom (project Aedra lead dev) might be worth posting again.

I initially looked into using Bullet's kinematic character controller
for Aedra and decided that I didn't like the feel of it (plus it had
quite a few problems). So I ditched that and decided to do what I did
which is to use Bullet as a collision-detection system only and then
to do the collision-reaction system for characters, spells, etc.
in-engine instead of in Bullet. So no, you do not have to use Aedra's
modified Bullet (in fact, if you want to use Bullet for anything other
than collision detection, you'll probably want to use the unmodified
Bullet instead). Furthermore, there's still problems with the Aedra
physics code that needs to be resolved before it's ready to go -
namely that there's still random jitter that I need to get rid of,
other various physics smoothing that needs to be done, and also better
physics network synchronization. Speaking of which, I didn't modify
Bullet very much - I really just changed how a few small things worked
because I wouldn't accept that Bullet doesn't support 2-byte mesh
indices (which it now does in my version). Lemme know if you have any
other questions - I'd be glad to answer them

I just remember our own problems with falling through the floor all the time and when we were actually supposed to fall we would instantly snap to the ground below, no jumping. Maybe both projects were using it wrong, maybe bullet's controller has improved recently, who knows?

This article is very informative
http://www.digitalrune.com/Support/Blog ... llers.aspx


Whatever the case is, we need a character controller for actors to actually move around.
Character controllers are complex, it's hard to say if morrowind's was coded from the ground up or if gamebryo provided something in this area. Coding one is a big task, a lot of things to consider, possibly performance issues if it is not designed well.

[Chris]

Are we talking actors here or objects?

Both. Anything that moves, really.

I think there are two positions, the scenenode position and the physics actor position. The scenenode position/visual position would be offset from the physics position. The animation itself plays and the actor looks to the human eye at the physics position.

But you run into a problem when you consider how the animation itself moves the "physics object". Take the death animations, for example. There's several of them, and they each move in their own ways. But no matter which way it moves, the object properly collides with walls, and the hit box (used for activation/looting purposes) moves too.

Physics mean nothing if you can't animate the object, as the object would never be able to move. Conversely, animations don't always need physics. Ergo, the animations should have control over the physics, rather than the animations having to constantly react to what the physics are trying to do.

Many physics things do not even involve animations at all, such as sliding down a hill, the bones are just set in position.

Think higher level. Whenever you move a node (be it a skeleton bone or an object's root node), you're animating it. Whether it's being animated dynamically by some outside force like gravity, or whether it's following a pre-made animation track.

While sliding down a hill, the physics controller is doing the work here.

Not all by itself. There's more to it than simply applying downward force on a collision object since it also depends on the steepness of the hill as well as its texture/material. There's also a conceptual difference between walking down a slight incline and sliding uncontrollably down a steep hill... in the former you're purposely sticking to the ground as you traverse it, in the latter you're trying to fall but the ground gets in the way.

I think what should happen here is that the mechanics/AI sees "hey, this hill's too steep, this object should be pushed down by gravity." It then tells the animation controller "animate this object falling." The animation controller then runs a physics simulation to see how the object would be affected by gravity -- taking the object's collision node (e.g. Bip01), the collision shape, and everything it can collide with -- then applies the delta to the object's root scene node so the collision object is placed properly while being animated.

As far as the game is concerned, the object would be at the collision's node position. The object's root node would be used to "correct" the position when the animation gets it wrong (e.g. walking through a wall, falling through the ground).

[jhooks1]

Are you trying to say morrowind does not have a physics character controller? That AI is doing the work?

EDIT: I agree there is interaction. We do not have a good physics character controller though, and its not extremely simple just to code proper player/actor movement up from scratch. We are using bullet for physics interaction. Somehow you are going to have to interact with our bullet collision world.
Because we are using bullet we have three options for interacting with our physics world:
1. Use bullet's built in character controller.
2. Use traces, try to code all physics movement ourselves. From the ground up. Everything from scratch.
3. Use traces, use something open source like pmove to control the character.

Switching to something else other than bullet would be disastrous for the project. Which one of these are you proposing?

[jhooks1]

Physics mean nothing if you can't animate the object, as the object would never be able to move.

OK. But I could say the opposite as well. Animation means nothing without physics, as the object would never be able to move and collide with the world.

And yes the player/actor is constantly being animated and affecting position.


When jumping (just one example) AI/keyboard movement, gets sent to the physics system. The physics system is very much an integral part and can't be set aside as simple.