Calling The Search Animation

[Springheel]

Crispy, I vaguely remember you saying that you did/tried to get this working, but at the time the only search animation wasn't working. Now that we have one (two?), would it take much to get the AI using this when they go into search mode?

 

Actually, I'll make that a blanket question for all the new animations. I know the idle ones might need something special to be called at random, but what about things like the pain animations or the sudden surprise one?

[Crispy]

Crispy, I vaguely remember you saying that you did/tried to get this working, but at the time the only search animation wasn't working. Now that we have one (two?), would it take much to get the AI using this when they go into search mode?

Short answer: Dunno. My memory on that one is pretty hazy as well. I can find out, it would just need some re-investigation.

 

Longer answer: There are two types of animations from the AI script's perspective; looped ones (walking/running/searching) and once-off ones (pain/surprise/idle). Once-off animations are easy; you just call the "play animation" script event when you want it to play (I forget what it's called - possibly playAnim). Looped animations are slightly more complicated, and I don't remember if I managed to figure out exactly how they worked. I got the impression that they were handled by some kind of state machine (a different one to the AI states).

[Ishtvan]

I have a concern about when to call the search animation:

 

The AI's FOV is linked to where they're looking. When they get an alert, they initially look toward the source of the alert. This actually makes it more likely for them to see something there, because sight is probabilistic, so the longer they look the more likely the are to see something, if it's possible at all to see it.

 

I'm hoping that the search animation doesnt interfere too much with this, because if it made them look away from the alert, that would actually be hindering their search rather than helping it. We should make sure it only gets called if they've already looked at the area of the alert and determined that nothing is there (i.e., they've already passed the initial responding to alert phase and have moved on to the searching hiding spots away from the alert phase).

 

If the area where the alert happened was darker, they may have to walk closer to it while looking at it before they can see it well enough to decide nothing's there. Only after that should they call the search animation, IMO, and if they receive another alert during it, it should be aborted and relaced by the script-controlled head motion again.

[Crispy]

Wouldn't it be easier to just have no animation data on the search anim's head channel? Then it would function exactly like the existing idle/walk anims, with the torso+legs controlled by the animation and the head controlled only by the script.

[Springheel]

Exactly. The search animation should not be applied to the head channel. In fact, no animation should be applied to the head channel unless it's really important that the head move in a particular way (like a coughing animation).

[Domarius]

Um... yeah. I thought this was always the case?

 

Doesn't D3 override any head movment the animation has?

[sophisticatedZombie]

Hey, I was the one who had trouble with the search animation. The problem I ran into, is that it played the animation, but then the AIs arms became stiff at their sides for 30 seconds or so afterword. I don't understand it enough to guess at the cause other than there is some other animation that must be re-established in the arms.

[Springheel]

Doesn't D3 override any head movment the animation has?

 

I don't think so. Otherwise you wouldn't be able to control the head in any animation.

[Domarius]

Okay... if that's the case then I'm not sure what to do about it.

 

To keep the guy's head looking forward, I have to rotate his neck to compensate for the upper torso movement. Will the game be able to keep the head facing one direction independant of the torso rotation?

[Springheel]

To keep the guy's head looking forward, I have to rotate his neck to compensate for the upper torso movement. Will the game be able to keep the head facing one direction independant of the torso rotation?

 

I don't know. Are we talking about the search animation? If so you shouldn't need to keep his head looking forward.

[Domarius]

Okay... so I should just have to send through an anim where the neck doesn't compensate for the torso movement to keep still, so it ends up rotating left and right with the torso?

[Springheel]

I'm not sure exactly what you mean. The head should be free to rotate as it likes--D3 heads are already set to turn towards noise or other stimulus, as far as I can tell.

[Domarius]

Yeah but D3 can't control my anim while its in Motion Builder The anim that I make, if I don't put any keyframes on the neck, then its going to rotate with the torso. You know, how your shoulders swing back and forth when you run or walk. So essentially I'm going to be animating a guy who's neck is immobile and ends up looking left to right as he walks. And this is what I upload, to allow D3 to control the head properly.

 

Is this correct?

[Springheel]

I have no idea. What does the normal walking/running animation do?

[Domarius]

No idea.

 

Actually it was based off the motion capture files, which most definetly had neck movement in them, unless someone specifically deleted those keyframes.

[ascottk]

I think the look code overrides the animations or blends with the animations. I'm not entirely sure about that though.

[Domarius]

I'm hoping that the search animation doesnt interfere too much with this, because if it made them look away from the alert, that would actually be hindering their search rather than helping it.

I am just really confused about what prompted this? How is my search anim any different from the existing walk and run anims?

[Ishtvan]

I am just really confused about what prompted this? How is my search anim any different from the existing walk and run anims?

The existing walk and run animations don't override the head look joint. I thought the search anim specifically rotated the head joint around? Can the programming control of the neck joint run at the same time as the current search anim with believable results, or would the head just clip into the raised hand if it turned into it?

 

I mean, it may be technically possible for the look code to override and force the head a certain way in the search anim, but would that cause clipping or otherwise screw up the believability of the search anim, which relies on neck movement?

[Domarius]

Well let's see what happens once it's in game.

 

I can easily enough make the search anim without any neck movement, it just means he's going to be looking left and right as his shoulders rotate, so the "head look" code better keep it straight.

[Ishtvan]

I can easily enough make the search anim without any neck movement, it just means he's going to be looking left and right as his shoulders rotate, so the "head look" code better keep it straight.

Well, that was my concern initially, the head look code does (and should IMO) look towards any new alert. In this case I guess we should break out of the search animation if they get a new alert while searching. Also, we shouldn't play the search animation too early in the script when they are still looking toward the alert and walking over to it, because there it's important for them to keep looking toward the alert spot in case they actually can make out the player if they look long enough.

 

I think the search anim should come when they've already checked the spot of the alert and they still have no idea where the player is hiding. That should be do-able since I think those are two different phases in the script now, right? The initial look and walk over to alert spot, then the hiding spot search?

[Springheel]

I don't know, the search animation is also supposed to keep their weapon out. If they just stroll over to the spot with the regular walk animation, they won't have their weapon drawn, which could be exploited (and I think it would just look wrong, like they weren't at all concerned about the alert). Isn't it customary in the other games for guards to immediately go into search animation if they're alerted but can't actually see you? It's not going to control the direction they move or anything--they might proceed slightly slower than they would if walking, depending on the animation, but that's it.

[Crispy]

They can get their sword out without going into the search animation. I know this because they already do it. All you'd need to do is make sure they draw their sword first, then move to the alert spot, then start the search animation. Not that difficult.

[Springheel]

Really? When they run they keep their sword out, but when they walk their sword goes back into their sheath, at least when I've watched them.

 

The search animation isn't any different from a walk animation, in terms of how the AI interacts with things around it--it just makes it look like the AI is actually alert and ready for trouble, rather than strolling around. I don't see any reason not to use it if the AI really is, well, alert.

[Crispy]

Hmm, maybe you're right. I had assumed it was controlled directly by the code, but maybe it is just a run vs. walk thing. I'd have to look at it again to say for sure.

 

As for the topic at hand, the consensus seems to be "we don't know". Someone needs to actually try it, and raise the topic again if it turns out there is a problem.

[Domarius]

Well, that was my concern initially, the head look code does (and should IMO) look towards any new alert. In this case I guess we should break out of the search animation if they get a new alert while searching. Also, we shouldn't play the search animation too early in the script when they are still looking toward the alert and walking over to it, because there it's important for them to keep looking toward the alert spot in case they actually can make out the player if they look long enough.

 

I think the search anim should come when they've already checked the spot of the alert and they still have no idea where the player is hiding. That should be do-able since I think those are two different phases in the script now, right? The initial look and walk over to alert spot, then the hiding spot search?

 

Okay, this is nuts. I don't know why the initial concern was raised, but no valid reason has come forth.

 

There's nothing "special" about the search anim compared to the walk or run anim, and there won't be a need to break out of it just to let the head turn - either the head turning code can override the neck animation, or I remove the keyframes so that the head turning code can take over. Either way, the head will be free to look around.

 

Seeing as oDDity didn't know about dynamic head turning when he made the walk and run, I'd say he would have left all the mo-cap animation as it was and tweaked it, and not deleted the neck keyframes, which means the code can override the neck animation.

 

Just like it played the upperbody running animation while the legs did the walking animation, in that vid in the Out Takes thread. Doom 3 seems to be capable of controling the animation channels independantly of each other.