Guard Animation For June 17th Video

[BlackThief]

yes they all have a head-bone, so head-turning should work.

[Springheel]

I'm confused by all this discussion...head turning *already* works, right? If you watch the elite guard (don't know about the others) he clearly turns his head to look at things. You can even see it in this screenshot:

 

http://www.mindplaces.com/darkmod/guards2.jpg

[SneaksieDave]

I believe that was a posed shot.

 

Aside: egads, why would that shot ever be shown? That was a 4 minute, all-same-texture-and-even-misaligned piece of pure shit map I threw together to test sound. Please, no publicity photos with crap test maps.

[Springheel]

I believe that was a posed shot.

 

No it wasn't...I took it while playing around with the AI. (and it's there to show AI in action, not the map)

 

On the peering animation: I"ve noticed that waist thing to. For now it just turns toward the position using its feet and head.

 

There's discussion about head-turning here:

http://forums.thedarkmod.com/index.php?showtopic=3705

[SneaksieDave]

Wow... that's interesting then. Maybe I had seen those movements and assumed it was animation. I'm going to run off and see if I can get a guard to turn his head.

 

Edit: it's really hard to tell. Anyone know if there is a command to visually show the vision cone? The other cones were for audio, if I remember correctly (as in haunt_city).

[Ishtvan]

They can turn their head independent of animations. They have "look joints" that can be controlled by where they're told to look in the script. Ideally both the waist and head are supposed to be "look joints" so they can turn their torso a little in the direction as well as their head, but the waist one gives an error in the console so it doesn't seem to be set up right.

 

Whether they look in directions is determined by the script then. I know in combat, they definitely keep looking at their enemy wherever they go. As for alerts, SZ has been handling the latest version of those scripts so I'm not sure myself. I know they look at you when you're in an unreachable position. For alerts, they may turn their whole body toward you rather than just their head. Maybe we could put a phase in the script where first they just turn their head to the position for a few seconds while they say their bark before they start walking toward it. It depends what behavior we want.

 

We would not want to do that for tactile alerts, because that would let you stand behind them and hit them with the sword while they pause for a moment to look over their shoulder at you.

[Springheel]

We also want them to turn their head randomly from time to time, right (at least when unalert)? Is that difficult to do?

[sparhawk]

Nope. It would be just a matter of using a stimtimer and randomly adjust the time until the next turn.

[Ishtvan]

Yeah it's not difficult, although you might not need a stimtimer, since AI are running their own threads already, you could just include a timer in the thread with a min time and max time for psuedo-random head turning.

 

To randomly turn the head/waist, you'd just have to give them a look position on some random direction vector within an arc based on their current body facing, then look back straight ahead when done.

[sparhawk]

We will need timers anyway, because I think depending on the purpose of the AI, it should be possible for them to randomly stop walking, looking around, etc. For other AIs we will need randomly picking up things and putting them back and such.

[Domarius]

So to understand this correct:

 

The bones are required for coded animations, while the MD5 files are requiered for generic animations, but for this there would be no bones needed as it is applied directly to the mesh? And you can have a mix of both, meaning that you can apply an MD5 and at the same time interfere with code?

 

Is this understanding correct?

 

Still the question is, do our models already have these necessary bones?

No it's not correct.

 

Bone's are the unifying method of making the character move, whether it be animation or code. When I animate in motion builder, I'm moving bones. The animation is just a sequence of bone rotations.

 

The code can manipulate these rotations in real time.

 

The only issue is if a bone rotation is being controlled by the code and the animation at the same time.

 

In some game engines, this is allowed, and the average rotation is interpolated.

 

But even if DOom 3 doens't support this, all I have to do is not animate the head as part of any animation, so that the neck joint will not contain any rotation information while that animation is playing, leaving it free to be modified by the code in real time.

[Ishtvan]

The only issue is if a bone rotation is being controlled by the code and the animation at the same time.

 

In some game engines, this is allowed, and the average rotation is interpolated.

 

But even if DOom 3 doens't support this, all I have to do is not animate the head as part of any animation, so that the neck joint will not contain any rotation information while that animation is playing, leaving it free to be modified by the code in real time.

 

Hmm, I know they can turn their heads while walking or running, but I don't know if the walk/run animations are sending any instructions to the head. I know D3 makes a special case with the "look joints" of neck and waist. It seems like the look joints might override other animations, but I'm not sure. Whatever we decide to do should be tested first to make sure it works before applying it to every animation.

[Domarius]

The animations are linear, just like a strip of movie film (there's no "instructions" to be sent other than a stream of rotations), so if the animations were controlling the head, you'd notice the repeated pattern. A run cycle is only 2 steps long (one foot, then the other). There's no time in there to make the head move the way you see it move in the game. The animation has nothing to do with the head looking about.

 

I don't think there's anything to "apply" to an animation. It's just something I don't do. I don't animate the head, thereby leaving it free for you to manipulate with the code.

[sparhawk]

The MD5 file allows for independent animations of different parts of the model. In Q2 this was not possible and if you wanted to have multiple animations you would have to do all kind of permutations. This means that, even if the walk cycle is playing, it doesn't follow from this, that the head animation must have the same cycle, because they can be controlled independently. Also I think doing the head totally code controlled might look a bit steril. If it takes to much time it's ok, and we have to live with it for now, otherwise there should also be some animations on the head maybe as, especially, humans are not really static with any part of their body.

[Domarius]

Yes the anims can control different parts of the body. I'm pretty sure Doom 3 can do what I've seen other engines do - if 2 animations are controlling the same bones, their effects are averaged out so that it does both at the same time.

 

Valid concerns about the code controlled head, but I'm faithful that it will look pretty good, with just simple accelleration and decelleration between start and end position. I can't wait to see the results if a programmer tries this out.

[Ishtvan]

I'm not trying to be combative here, but why are we even talking about adding new features to be filmed in the video? I thought the footage was locked down months ago and we're just cutting/scoring the video right now?

[sparhawk]

The major problem is that the video was locked down long ago, but there is a lot that has been added by now. And AFAIK searching is quite an important progress. IMO it would be kind of pointless to show a video with features that were done a year ago. The major problem was that Tyrot dragged this along for such a long time. And we are not talking about adding tons of stuff, but I think the searching should warrant that it is included, as it is a very important aspect of the gameplay.

[New Horizon]

The major problem is that the video was locked down long ago, but there is a lot that has been added by now. And AFAIK searching is quite an important progress. IMO it would be kind of pointless to show a video with features that were done a year ago. The major problem was that Tyrot dragged this along for such a long time. And we are not talking about adding tons of stuff, but I think the searching should warrant that it is included, as it is a very important aspect of the gameplay.

 

The only problem is, if we want to release this video at the same time we release the new update for beta mappers, I need to have the video clips to drewb50 by no later than tomorrow night. So, if we're talking about something that still needs to be coded...it won't make it in. I can't justify delaying the video much longer. I was playing around, and the guards seem to be doing some pretty good searching right now, so I can definately put something together with what we have.

[sparhawk]

That's ok then. As it seems, Domarius wont be able to get the anims in-game before the 18th anyway. So if you already did some shots where you can see that they are searching, even though they ar enot properly animated, then I think it is ok. Maybe we can emphasize the effect a bit, by having a bark in the video "Where is that guy?" or something?

[New Horizon]

Maybe we can emphasize the effect a bit, by having a bark in the video "Where is that guy?" or something?

 

Yup, that shouldn't be a problem. I find the guards are starting to do that already anyway.

[Domarius]

Heh, oh well. That's a bit less stress for me then I guess. I even copied the files onto my CD so that I could take it with me and possibly work on it while I'm away.

[sophisticatedZombie]

If its not too late, I could go through the scripts this weekend and add some random head turns etc... The key would be adding a lookAt (position, duration) event method. Right now there are lookAtEnemy and lookAt (entity, duration) methods, but nothing to look at just a piece of space. It could be done relatively quickly however.

 

I've added two new script methods: lookAtPosition and lookAtAngles. I've placed them in the darkmod_ai_base script along with some probability variables. There is chance to look around while idle (during patrol, waiting, etc..) and a chance to look around while searching. THey are each a "probability per second". If an AI is slightly agitated (non-0) then its chance of looking around while idle is doubled.

 

Eventually we will want to make the probability variables set from spawAargs. For now they are set in the Init member from defines at the top of the script. An overriding script could always just replace the variable values with new ones for a different type of AI (elite etc...)

 

I'll make sure I have all the latest updates from CVS and then check this stuff in tonight.

[Ishtvan]

Sweet! Now we can finally see how it works ingame. I'm guessing it will be a delicate balance between too unpredictable and too predictable.

 

I was thinking that if they look side to side randomly while idle, maybe the amount of time they look to the side should be pretty consistent, but randomize when they choose to look to the side. That way you can wait for them to look left if you're on the right of them, and know that they'll keep looking that way for at least a few seconds, giving you a chance to get by. Of course it should all eventually be spawnArgs so the FM author can set up specific situations.

[sophisticatedZombie]

Yeah, there are a number of variables that will need to be tuned. I've checked in the stuff, so you can look at it. Feel free to make any changes to the head turning functions in the ai_darkmod_base.script file to get them the wayyou like them.