Newb Anim Thread

[Baddcog]

title says it all, I don't know what I'm doing. well, to a degree.

Do have a few q's regarding anims though.

I looked at some of the spider anims and they brought more questions to mind. I figure at some point it would be good to add this stuff to wiki.

 

Animation sequences:

I always thought that anims needed to have the exact same pose begining and end. But the spider isn't like this at all. also there are spots in the middle of anims that seem to switch to an entirely different anim.

 

Animation Lengths:

Seems like 30 frames is fairly standard. Spider death is like 50. How critical is this to blend anims?

 

--edit--movement:

We don't need to actually move the Ai in animation for them to move do we?, just need to animate them right so they look like they are pushing off floor.

 

random stuff:

Spider swords: I noticed a 'no draw' box above the spider mesh. This is just for attaching a sword/weapon stimlulus I take it.

 

--edit-- don't know what I did but all of a sudden I can moce waist independent of origin, some bug I think

[ascottk]

Animation sequences:

I always thought that anims needed to have the exact same pose begining and end. But the spider isn't like this at all. also there are spots in the middle of anims that seem to switch to an entirely different anim.

What anims are you referring to? The only one I can think of is the death & search anim & I only modified those. oDDity is the original animator for these.

 

Animation Lengths:

Seems like 30 frames is fairly standard. Spider death is like 50. How critical is this to blend anims?

There's no real standard, just what looks good & natural. I'm not sure how the blend anims operate.

--edit--movement:

We don't need to actually move the Ai in animation for them to move do we?, just need to animate them right so they look like they are pushing off floor.

We need to have the origin move or they'll walk in place. First animate them like they're walking in place then move the origin (which should move the whole mesh) so it'll match the animations. If you're having a hard time matching the footsteps, like the feet are sliding around, modify the animation so to match the origin movement.

 

random stuff:

Spider swords: I noticed a 'no draw' box above the spider mesh. This is just for attaching a sword/weapon stimlulus I take it.

It's been too long since I looked at it. I think I added it for some odd reason or another I'll get back to you if I remember why.

3ds max bone Q. I know most of you use maya but might be familiar with Max. I have the waist bone on the lantern_bot as a child of origin. But I can't change the veritcal distance between them and can't figure it out.

I want to make the body go up and down a little but it can only do that if I move the origin which I take it will always be at 0,0,0 in game?

In which case the body wouldn't go up down anyway.

If ik is working right in max, you should be able to drag the waist bone up & still have the feet planted on the ground (depending on how high you drag up though). I do have experience in max but not with the ik stuff.

 

0, 0, 0 will always be on the ground (except for jumping, running, or walking) so moving the origin up will actually move the mesh into the ground. You should be able to stretch the bone between the origin & waist, but my max experience is slim.

[Baddcog]

yeah, not sure what my prob was with that origin bone moving with its child. It shouldn't have been doing that, it wasn't rotating with the child. Something weird was going on but that's passed.

 

Now I have an issue that I am stuck on though. I set keyframe at 0, set keyframe at 30. then I go to 15 move the waist down a bit and set a keyframe. Now you'd think the anim would be for waist to move down at keyframe 15 then back up to it's original spot. But instead it is moving up in the air at keyfram 0 and 30, and it goes down to where I put it at 15. Pissin me off, can't figure it out, anyway...

 

I looked at several spider anims, but I'm working on my bot, making new anims.

I looked at idle, attack, walk, death, ect...

I can see death being different of course.

 

But say walk, the back leg and next leg foward are closer to each other at end of anim. So does doom interpolate these between each walk cycle? or do the legs 'jump' from one position to another (I image they don't but haven't watched one in game close enough to tell)

I also looked at a guard walk (not sure which one) and his feet aren't in the same spot begining / end either.

 

I'm still fidging with the IK, and as I remember, it's a pain in the ass. easier to use FK imo. But I'm trying to get a real smooth circle out of the gear piston, would be easier with IK. I think I can do that, just need to figure this up/down problem out first.

[Baddcog]

Just made a 'spotted' anim cause the spider had one. Went in game and it never seemed like spoider spotted me, just started runnng at me. Then noticed in the spider.def that this anim isn't used, but the spider Queen does have a 'anim sight', looks like a sound is attached.

 

Did you guys just decide not to use that anim? Or is there another reason.

 

Oh yeah, what is the actual purpose of the footstep tag in the anim dec.

Is it for sound?

[Domarius]

First animate them like they're walking in place then move the origin (which should move the whole mesh) so it'll match the animations.

Well actually you do it all at once. As you animate, when the time comes to move his whole body forward, you do it with the origin bone, instead of the hips like you'd do in normal animating situations, otherwise you'll never get the feet to match up with the ground moving past, and there'll be slipping and sliding.

 

 

Now I have an issue that I am stuck on though. I set keyframe at 0, set keyframe at 30. then I go to 15 move the waist down a bit and set a keyframe. Now you'd think the anim would be for waist to move down at keyframe 15 then back up to it's original spot. But instead it is moving up in the air at keyfram 0 and 30, and it goes down to where I put it at 15. Pissin me off, can't figure it out, anyway...

You have a problem with animation curves... if you're using Motion Builder you can open the FCurves window and adjust it so the movement doesn't overshoot- its to do with how it tries to make motions look smooth rather than sudden changes in direction. Sorry to be so cryptic, I probably won't have time for this for another month yet...

[Domarius]

Oh yeah, what is the actual purpose of the footstep tag in the anim dec.

Is it for sound?

Yep

[Baddcog]

Yeah, I actually had to use the curve editor to fix that problem. I don't think it should've ever happened that way but...

 

Motion Builder is only for Maya isn't it?

[Domarius]

I'm glad you sorted it out. I didn't expect anyone too new to understand what I wrote.

 

Motion Builder is a stand alone application that mainly uses the FBX format. You can get exporter/importer plugins for both 3DS and Maya but we've only ever got Maya working properly with our workflow. ascottk's the one you need to ask questions about the workflow.

[Baddcog]

Well, I've got this guy almost done. Did have a few Max learning issues that I had to deal with. Still might have a few tweqs left on the anims but he's pretty much done. Don't think I'll mess with Motion Builder then, if it has Max issues I'll just stick to what I know, working good enough for now.

 

Got light and particles attached. Working on AF now. I'll try and write up a beginners guide to the AF editor as I'm still learning it but have figured out basics. My legs are behaving like I want so that's the main thing. Problem with the AF edit is that there are sooo many choices and no guide. Many of the choices don't seem to make sense, takes along time to try everything and stumble across the correct settings.

[Baddcog]

Guess a qusetion I never got to:

 

What anim 'states' are we going to use, which ones are implemented right now.

 

I ask this because I have an anim in the def for anim_search but the lantern bot clearly never plays it, also one for anim_sight, that never played either.

 

So far it seems that idle works, walk works, I don't think run or search are working, but melee_attack1 does.

[Crispy]

The idle, walking, and running animations are all implemented, as is one attacking animation (don't remember what it's called). So is throwing, though that doesn't apply to the lantern bot since it won't be throwing things.

 

I can't think of any others off the top of my head. You're right that searching isn't, yet.

[Baddcog]

OK cool. There are things in the search anim like the game handling head (earphone) movement that I couldn't test, so I'll wait on that.

[Springheel]

The lantern bot shouldn't have an attack animation, since it won't attack. It really only needs the following:

 

idle, walk, run (possibly, but not necessary), search, and death (depending on how the AF works out, this one may not be needed either).

 

We're not 100% sure how turning in place will work, but a 90 and 180 degree turn would also probably be useful.

 

That's really all a civilian bot would need.

 

OK cool. There are things in the search anim like the game handling head (earphone) movement

 

If you can get the earphone to work as a head (ie, turning randomly) then I'd disable the animations for it in all the animations (not just search), and let D3 handle moving it. It will seem much more natural than the constant pendulum motion it has now.

[Baddcog]

It deffinately needs the attack anim. Probably easier than renaming/coding "alert state anim" which is basically what I'm using it for. Basically the 'attack_anim' has the bot getting agitated. He doesn't attack so much as lets the player know he's pissed, this is also what sounds his voice (which works btw), I am working on his actual voice.

 

If you haven't checked the progress of him in the last week run test_baddcog.map again. SVN is current with what I have finished so far including half the new AF file which is better than before too.

 

 

The reason I would like to keep the earphone moving in most anims is that it's his job to search by listening. So if walk anim is playing he hasn't been alerted yet, but still needs to be listening around him. Otherwise it'll seem like he's only listening straight in front of him as he patrols.

However the search_anim will not have ear animations, so when he becomes alert and starts to search the game should make him "listen" (look really since that's his 'head') towards the sound.

So I am looking foward to having the search anim instituted to see how that works.

 

I was thinking of making a death anim. mainly so I can have him collapse, maybe make a death cry and have one long stream of steam escape like his soul is floating away. I'll export an Af pose in the state of collapse. That stuff will be less than 175k.

 

He's got a light attached, however the lantern light texture doesn't seem to be working. It did on a mock-up with an unattached light.

 

Not sure if he will need the turn anims, guess that depends on how they are coded. He turns now, his legs are moving since he does it when his walk anim is running. Give me your opinion after you look at him again. He turns fairly fast so it's hard to even notice if his legs slide.

Of course I haven't set him on patrol and watched him turn during patrol, mainly when he's searching for a noise arrow or me.

[Springheel]

He doesn't attack so much as lets the player know he's pissed, this is also what sounds his voice (which works btw), I am working on his actual voice.

 

I don't think we were planning on giving bots voices, actually. Especially one this size seems kind of small to have any kind of record playing device. Wasn't he just going to use a whistle?

 

The reason I would like to keep the earphone moving in most anims is that it's his job to search by listening. So if walk anim is playing he hasn't been alerted yet, but still needs to be listening around him. Otherwise it'll seem like he's only listening straight in front of him as he patrols.

 

No it wouldn't--the earphone would still move around, it just would move *randomly* rather than a set pattern. Have you seen the way our AI turn their heads randomly while idle? It's the same effect. Not a big deal, but I personally think it might be worth it.

[Baddcog]

That would be fine I guess. I'll try it and see what happens.

 

His 'voice' is just a whistle, but right now I'm using a guards voice to test so it's funny.

 

However there is an issue concering this. His whistle will blow every 40th frame. (I think I specified 40 as the start point).

Anyway, when he runs thru the anim and hits 40 again the sound stops immediately and starts again.

So I can either time it and try to make it a short whistle blast that will end before the anim comes around again, or I can extend the anim so the full sound will play.

I guess most likely I'll try to time it to end before it restarts. Not sure why I've even mentioning it.

 

------------

hmm, went in game to check out the bot again. Has been a few days, maybe 4+ since I last got chased around by him.

Something odd happened in that time, I didn't see any major changes to AI in the SVN log, the last was something by Crispy on the 8th.

"Fixed Ai would not attack in response to "I saw an Enemy"...

Not sure if that's what the issue is.

 

Before the bot would see or hear me almost instantly, almost too quickly, and run his "melee_anim", but now he doesn't seem to notice me half the time. I can stand in his light right in front of him and jump up and down. Doesn't notice me. I draw a noise arrow and his melee anim runs. Maybe it ran right after I let the arrow fly. Either way, he'll stand there and not even notice me in bright light.

 

Was something changed in the last few days that would effect this?

[Springheel]

However there is an issue concering this. His whistle will blow every 40th frame. (I think I specified 40 as the start point).

Anyway, when he runs thru the anim and hits 40 again the sound stops immediately and starts again.

So I can either time it and try to make it a short whistle blast that will end before the anim comes around again, or I can extend the anim so the full sound will play.

I guess most likely I'll try to time it to end before it restarts. Not sure why I've even mentioning it.

 

Tying it to an attack animation probably isn't the best way to do it. What the bot is really doing is calling for assistance, like AI do when they spot an enemy. It should really be using the same system as other AI do (just a different sound fx, obviously) for that, which would solve the problem of it being cut off, or having it happen in a regularly-repeating cycle.

 

AI that don't have an attack animation (civilians) currently just turn to face the player when they spot him, and keep turning to keep the player in sight. That's probably the default behaviour we'd want from the bot, along with summoning other guards with soundprop. We might want the bot to try and follow the player as well...don't know if civilians do that currently.

 

Either way, he'll stand there and not even notice me in bright light.

 

Isn't he blind?

[Crispy]

Something odd happened in that time, I didn't see any major changes to AI in the SVN log, the last was something by Crispy on the 8th.

"Fixed Ai would not attack in response to "I saw an Enemy"...

That was related to multiple AIs communicating with each other. If there's just one AI in the map it shouldn't make any difference.

 

Don't worry about getting his behaviour correct for now. Non-combatant AI isn't working yet. Just concentrate on the artistic side (modelling, texturing, animation) and the programming department will worry about the behaviour.

[Baddcog]

Spring:

 

If I just let him look at the player he won't do anything, I guess you haven't checked out the map again. Using attack makes him use an animation that shows he is agitated and aware of player, not just turning to face him.

His 'attack' on the player IS 'alerting the guards'.

That's a hostile action as far as I'm concerned. Townsfolk would run to a guard, a totally different behavior, that's not hostility, that is fear. Never the less, it doesn't really matter does it? When he spots the player he needs to get pissed off and alert the guards, whether or not it's called "attack", it will have the same effect.

I think you are confusing it because you think attack means 'hit player with weapon', but in this case hge IS attacking the player with his weapon, an alert whistle.

 

If the player moves behind a wall he WILL follow, when he see's player again he gets pissed and 'attacks' (gets agitated and blows whistle. All we're doing is arguing symantics. Please go in game and see what he does now, you will understand. But then again, the behavior has changed so you really have to coax him now and it barely works like it did a few days ago....see post below to crispy

 

 

The whistle will just have to be short bursts instead of a long drawn out whistle, which I think is better anyway. Will have to have the same props as noise arrow??? to atract the other AI.

 

About being in front of him, no response. He doesn't see nessecarily, but being right in front of him in light does need to trigger alert. It would be lame if player could stand there fully illuminated and not alert him. I mentioned this in an earlier post. But I also said in above post that I was jumping up and down in front of him, making sound, ect....

 

-------

Crispy,

 

OK, read above. He is a non-combatant in the fact that he doesn't fire a physical weapon. But he is a combatant in the fact that he does use a weapon against the player (his whistle). He needs to run like a combatant. He just doesn't physically hurt the player, the guards he summons take care of that.

If he is run like the non-combatant townsfolk he would run away and find guard, then why have whistle or light.

His behavior is to keep the player in view, lit-up and whistling until guards come.

 

the problem is a few days ago he worked great, maybe a bit to clever, he could find the player almost immediately and seemed to always know where I was even after hiding for 5 minutes.

Now I have to constantly fight to keep his attention.

He was the only AI in the current map, so that's not what the prob is. He just can't find me, doesn't realize I'm there.

It's fine if you guys are working on stuff, I was just puzzled by why his behavior changed so drastically from the last time I looked at him. Obviously something happened though that effrects the way a single Ai in a map notices the player. Unless someone changed a prop in his def file? I didn't see anything that looked different.

[Crispy]

He is a non-combatant in the fact that he doesn't fire a physical weapon. But he is a combatant in the fact that he does use a weapon against the player (his whistle). He needs to run like a combatant. He just doesn't physically hurt the player, the guards he summons take care of that.

If he is run like the non-combatant townsfolk he would run away and find guard, then why have whistle or light.

His behavior is to keep the player in view, lit-up and whistling until guards come.

We'll keep that in mind when we implement AI for him, so don't worry about it. Rather than spending ages figuring out how to creatively misuse the existing AI code to implement the lantern bot's intended behaviour, your time is better spent on making things look good, since that's what you do best. Leave the AI programming to the AI programmers, that's all I'm saying.

 

I don't know why you observed a change in behaviour like that, but I wouldn't worry about it just yet. You're not really in a position to debug it. Once I'm done with the current AI revamp, I expect either I or one of the other coders will take a look and see what needs to be done to get the lantern bot fully functional.

 

Archers are in a similar state: Complete art-wise, but there's no specific AI programming for them yet. It'll come later. ascottk did make a test archer, but it's just an ordinary houseguard with a very long-range melee attack.

[Springheel]

I feel like there's a bit of a communication gap somewhere.

 

If I just let him look at the player he won't do anything, I guess you haven't checked out the map again. Using attack makes him use an animation that shows he is agitated and aware of player, not just turning to face him.

 

Yes, I did try the map. And the bot constantly played his attack animation cycle, which meant he played the same sound every x seconds. My point is, the attack animation is not the way to handle the situation. What happens if the player is on a crate? The bot won't play the animation, because he won't think he can attack. Likewise, if the bot spots the player from across the room, is he supposed to run up to the player in melee range before sounding an alarm? Because that's what the attack code would do.

 

His 'attack' on the player IS 'alerting the guards'. Never the less, it doesn't really matter does it? When he spots the player he needs to get pissed off and alert the guards, whether or not it's called "attack", it will have the same effect.

 

Code already exists for allowing guards to alert other guards. I'm not talking about what he actually DOES, but the code you're using to try to make it happen.

 

This isn't semantics. As Crispy said, you're trying to bend code to do something it isn't supposed to do. That's going to be messy and inconsistant, at the very least, and result in unwanted behaviour.

 

About being in front of him, no response. He doesn't see nessecarily, but being right in front of him in light does need to trigger alert.

 

If he can't see, standing in front of him won't alert him regardless of how brightly lit you are. He's either blind or he's not. I don't think he needs to be able to see, personally--the whole point of a lantern is so he lights up the area for OTHER guards. But since he doesn't actually attack it wouldn't bother me either way.

[Baddcog]

Well, the reason I was using attack in the first place for alert response is that is the only option I was aware of to use to make him alert. I'm just trying to test him, test anims, make him react how he needs to.

As far as playin one sound over and over, not a prob. It's just a whistle. right now it sounds messed up 'cause he's using a guards voice. Maybe the coders can make the sound not stop or overlap. Maybe there is another code for alert response. Either way that's a one line edit in the def file that can be changed when needed.

 

The standing on a crate thing, well, that hadn't occured to me as a problem.

 

But like I said, I don't want him to just stand there aiming at the player, I want him to play an anim. If it has to be something other than attack and it needs coded fine. Like I said in an earlier post I thought using attack would be easier than new code... I guess I'll have to put a bystander in game and see what reaction I get, But I have a feeling they will just stand there which is not what the bot needs to do.

 

I did increase the melee range to a more realistic distance though, I think that works fine. I'm sure the same system can be used with a new code set-up. There's got to be a limit though, if he's 100 feet away I think that is too far to 'spot' the player.

 

I think there is a communication gap too. I feel like I post stuff and it only gets half read, then 3 people respond, then I have to repost what I posted above. No biggie, I don't always catch what everyone else posts either.

I asked you guys to look at his current state, you didn't say you did so I thought maybe you were thinking back to his previous state.

 

But an example is the post I made about the bot being able to see to an extent.

I know we had talked about him not being able to see, only hear. And hear very well. But I thought about it and thought it might be odd to the player if they are standing right in front of him and he doesn't even know it. The point IS to have him light up the area, but more than that to light up the PLAYER. But if he can only find player if player makes noise, then the player could just stand in the middle of the hall and watch the bot pass by as the player is brightly lit, dumb little bot just keeps going. This would seem VERY odd to me and I'm sure odd to any player who was in that situation. So the bot DOES need some vision, even if it is a very small radius in front of him.

I explained that before but got no response.

 

But then in your last post Spring you say "if the bot spots the player". So in one sentence you tell me he can't see and in another you say he can?

 

@ Crispy: I know you guys are handling the coding, that's cool, I don't even want to think about going there. But I do need to be somewhat concerned about it due to the fact I'm trying to make things work within the code, or need to make you guys aware of code I need to make something work. I'm not going to ride you on it and say I need this and I need it now. But if I don't let you know that something is wrong with his behavior you guys might not realize it, I'm just trying to stay on the same page.

[Springheel]

But I thought about it and thought it might be odd to the player if they are standing right in front of him and he doesn't even know it. The point IS to have him light up the area, but more than that to light up the PLAYER. But if he can only find player if player makes noise, then the player could just stand in the middle of the hall and watch the bot pass by as the player is brightly lit, dumb little bot just keeps going. This would seem VERY odd to me and I'm sure odd to any player who was in that situation. So the bot DOES need some vision, even if it is a very small radius in front of him.

I explained that before but got no response.

 

I don't recall you bringing that up before, but perhaps I missed it.

 

I don't think there is a big problem if they don't see the player. The idea is that these are walking lanterns. Lanterns aren't supposed to see you, they're supposed to let OTHER people see you. These guys 'find' you, summon other guards, who can then see you clearly because it's shining a light at you. Or, if the player is quiet, they have to worry about being lit up just as a (seeing) guard walks by. You wouldn't have a location guarded *only* by walking lanterns. The T2 equivelant would be a will-o-wisp.

 

If he can see, hear, AND has a light, it becomes extremely difficult for the player to hide from him.

 

But then in your last post Spring you say "if the bot spots the player". So in one sentence you tell me he can't see and in another you say he can?

 

Ok, "spotted" was a poor choice of words. How about "detects"?

[ascottk]

I should have mentioned this a long while ago (actually I covered this in the belcher thread):

http://forums.thedarkmod.com/index.php?showt...=5452&st=75

 

Anything that's inheriting from atdm:ai_base tend to stand around when they should be attacking. I think most of the focus has been on atdm:ai_humanoid which has more functionality than the base. I think we should have atdm:ai_nonhuman because ai_base is pretty thin.

 

So I think the problems you're facing with the bot is the lack of ai_base functionality.

[Crispy]

@ Crispy: I know you guys are handling the coding, that's cool, I don't even want to think about going there. But I do need to be somewhat concerned about it due to the fact I'm trying to make things work within the code, or need to make you guys aware of code I need to make something work. I'm not going to ride you on it and say I need this and I need it now. But if I don't let you know that something is wrong with his behavior you guys might not realize it, I'm just trying to stay on the same page.

Yeah, that's cool. Just as long as you don't waste too much time on it.

 

Anything that's inheriting from atdm:ai_base tend to stand around when they should be attacking. I think most of the focus has been on atdm:ai_humanoid which has more functionality than the base. I think we should have atdm:ai_nonhuman because ai_base is pretty thin.

All AI currently use the same script, so I don't know why this is. Like I mentioned in your other thread, we'll look at figuring that out soon enough. "Soon" being a relative term, you understand.