Making better use of Ogre's capbilities?

[jhooks1]

If it helps, when you try to run playgroup inside morrowind from the console - it seems only simple animations (e.g. stop, start, loop stop, loop start) can be viewed. I think that the more complex skill animations don't execute through the command because they are waiting on external variables somewhere. I ran these tests on morrowind a while back when I was trying to figure out the text keys.

[Tarius]

Just a couple observations.

"WeaponTwoWide: Thrust Start"

If this is indeed a weapon animation, they only ever play once at the command of the player(or NPC I assume). Maybe I am not remembering correctly, but I seem to recall the fact that you can be interrupted while attacking. So basically, like half way through a swing you could be staggered or something.

As for attack speed, each weapon has a speed value for how fast you can attack with it.

[Chris]

We haven't figured that out yet. The playAnimationGroup/skipAnimation functions are meant for the script interface. We don't have a concept beyond that.

My thinking was, the animation controls would be based on the scripting functions available, much like the mwsound interface is. So the character AI would determine what's going on and call 'playgroup' or 'loopgroup' as appropriate, and the animation handler would call to do whatever is needed. But I'm not sure that's possible at the mwrender level.

The question here is how do we determine how long an attack is (i.e. when can an NPC start the next attack). Is it a fixed duration? Or should we actually use the duration of the animation? If it is the later, we only need a method to determine if the animation has finished.
Also, when does the attack comes into effect? At the beginning of the animation? Halfway through? Is there anything in the animation data that we can use to determine it? Not sure.

The text keys with the animation data are float:string pairs, and contain things like:

Code: Select all

297.533 - "WeaponTwoWide: Chop Start"
297.667 - "WeaponTwoWide: Chop Min Attack"
297.800 - "WeaponTwoWide: Chop Max Attack"
297.933 - "WeaponTwoWide: Chop Min Hit"
298.133 - "WeaponTwoWide: Chop Hit
WeaponTwoWide: Chop Large Follow Start"
298.467 - "WeaponTwoWide: Chop Large Follow Stop"
298.533 - "WeaponTwoWide: Chop Medium Follow Start"
298.867 - "WeaponTwoWide: Chop Medium Follow Stop"
298.933 - "WeaponTwoWide: Chop Small Follow Start"
299.200 - "WeaponTwoWide: Chop Small Follow Stop"

Whether the keys specify when these things happen, or are the points to use when the AI determines what happens, I don't know. I'd tend to think the former given how they're ordered, with the Min Attack coming first before the Max Attack, and how the AI can't know which is being used ahead of time (it's dependent on real-time user input). But the position and ordering of Min Hit and Hit has me perplexed either way... the hit doesn't occur until after releasing the attack button, but as far as I can tell, the release animation is one of the "Follow" sections (as in, the "follow up" of the attack).

2. Movement

That is particular difficult, at least for things like walking, running and sneaking. As I understand it, while running through an animation a NPC moves over a considerable distance. This must be compensated somehow, i.e. the internal coordinates of the NPC object in the world model must represent where the NPC actually is and not where the NPC was at the beginning of the animation, i.e. the NPC must move continuously and not in discrete steps. So there is probably need for some feedback from the rendering system to the world model (and the physics system).

The "real" coordinates need to be tracked anyway, so the animation system can know how far to move the base scene node when stopping or looping the animation. There's also the physics that will need to have the actual coordinates too, for collision purposes.

The reason I think that this should be moved out of the rendering system is that, as far as NIFs go, the bones are more like scene nodes that are being moved and animated, and scene nodes are more than just graphics-related (they can determine where a sound comes from, or where one object connects to another in the game world, or where and how large a bounding box is), and as noted above, there are text keys in the animation that possibly control AI.

Unfortunately, though, this is all out of my understanding. I've never looked into making a full game engine (let alone an RPG game engine) with "complex" character AI, to figure out how these things are typically done. Reverse engineering how such an engine would work from the external game data doesn't make it any easier.

[Zini]

My thinking was, the animation controls would be based on the scripting functions available, much like the mwsound interface is. So the character AI would determine what's going on and call 'playgroup' or 'loopgroup' as appropriate, and the animation handler would call to do whatever is needed. But I'm not sure that's possible at the mwrender level.

Most likely not. That the sound interfaces mostly works for non-script sounds is more like an accident. I would love the same interface for scripted animation and game mechanics related animations, but at least we will have to extend it substantially and maybe it will not work for everything.


I think what we should do here is apply divide and conquer. The animation problem is just too big to handle it all in one go. Do you think it is reasonable to wrap it up here and leave the non-scripted animation parts for later?

What we should do IMHO is to divide the animations up into categories and handle these separately when we have the rest of the engine ready to interact with them. From what I see we have:

1. Attacks and being hit
2. Walking, running, sneaking
3. Swimming
4. Dying and death

For 2-4 we already have tasks on the tracker, though they were originally more about integrating the animations into the engine.

[HiPhish]

Maybe I am not remembering correctly, but I seem to recall the fact that you can be interrupted while attacking.

Yes, you can, the question is if you can be interrupted anytime (even during a swing) or only while charging you attack.

[Chris]

Do you think it is reasonable to wrap it up here and leave the non-scripted animation parts for later?

Yeah, that shouldn't be a problem. It may take a little bit to get playgroup working with groups other than "all" (if they were working before? there was code for them, but last I knew only "all" worked), but just about everything should be working at least as well as it used to.

What we should do IMHO is to divide the animations up into categories and handle these separately when we have the rest of the engine ready to interact with them. From what I see we have:

1. Attacks and being hit
2. Walking, running, sneaking
3. Swimming
4. Dying and death

For 2-4 we already have tasks on the tracker, though they were originally more about integrating the animations into the engine.

I'm pretty sure swimming is just like walking, except with altered physics and a different animation names.

What's going to be tricky is the animation "patches". The way it appears to be, you have the base_anim[kna].nif for the base skeleton and animation, then you also have base_anim_female.nif, argonian_swimkna.nif, base_anim.1st.nif, etc, which specify overrides for particular parts of the original animation, perhaps even new animation groups too. I don't think the lengths of the replacement animations need to match the length of the originals, but I haven't looked very closely at that.

[jhooks1]

Do you think it is reasonable to wrap it up here and leave the non-scripted animation parts for later?

Yeah, that shouldn't be a problem. It may take a little bit to get playgroup working with groups other than "all" (if they were working before? there was code for them, but last I knew only "all" worked), but just about everything should be working at least as well as it used to.

They were working before, but I only had support for "start, loop start, loop stop, and stop"

[Zini]

Do you think it is reasonable to wrap it up here and leave the non-scripted animation parts for later?

Yeah, that shouldn't be a problem. It may take a little bit to get playgroup working with groups other than "all" (if they were working before? there was code for them, but last I knew only "all" worked), but just about everything should be working at least as well as it used to.

They were working before, but I only had support for "start, loop start, loop stop, and stop"

Yeah, the support for running animations from scripts (for those animations that are supposed to be run from scripts) it worked. That is a piece of functionality that we definitely should not lose during the rewrite.

I'm pretty sure swimming is just like walking, except with altered physics and a different animation names.

Really? If I were to make a swimming animation, I would just animate leg and arm movements and don't move the character forward. After all when swimming the distance you cover is not directly related to how far you move your legs, while when walking it is exactly the size of a step.

[Chris]

Playgroup/loopgroup should be fully working now, going by my understanding of the functions. It should work with any group that has markers that fit "foo: start" and "foo: stop" with optional "loop start" and "loop stop" markers. Modes 0, 1, and 2 work according to this description.

I could go ahead and send a pull request, though if people want to test it first, now's a good time.

[scrawl]

Couldn't find any issues while testing. The performance impact seems to be really small, so I think hardware skinning is now a post-1.0 optimization/feature.