I am working on several animations to export to UE4:
- idle
- walk
- run
- crouch
- jump in place/ jump forward
- block
- dodge left/ right/ forward/ back
- shield bash
- sword attack
- reaction - getting hit
I've finished the Idle pose animation in Maya, but my question is, "For the sword attack animation do I need to:"
- For the fist keyframe - start the pose from the idle stance, or from an attack stance? (attack stance as in the moment after you wind up, but before the sword swings forward)
- Animate the transition between idle stance and attack stance in Maya? (or will UE4 handle that with blend animations?)
- Keyframe/animate the sword windup in Maya? (or will UE4 handle that with blend animations?)
These questions also apply towards the other animations that I need to create. Thank you.
Replies
Each method has its draw backs and successes. For instance, if you animate the wind up yourself, from the idle pose, to make it look realistic it's going to take away from the responsiveness of the controls. Not really a good thing, but it depends on the game. If it's a fast paced game, chances are you wont want to do that.
Also, if you`re starting your attack from the idle stance, you also have to make sure that idle is a good idle to blend from. If the character is just standing straight up, as if you`re standing around doing nothing, it wont seem very realistic. In a lot of cases, you`ll want to have a regular idle, but also a combat idle, where if there is an enemy near by, or if you have your weapon drawn, you`re playing the combat idle where they look ready to fight.
Depending on the game, you might also have frame restrictions. I believe that shadows of mordor, the attack cycles have to "hit" by the 12th or 14th frame? I think it is? I could be wrong. But generally they are really quick. So, at 30 frames a second, you have to have an antic and an attack within half a second. If you`ve having problems making it look right when you start in the idle, then you can take away some of the frames at the start so that your animation starts mid way through the back swing. Gives you more frames to play with for the rest.
This is my understanding of it so far. But, admittedly, I haven't personally done combat animations in game yet. My experience is more for non-combat AI and cinematics. Im sure someone around here has though. Hopefully they`ll jump in.
So regardless of if I animate the wind up or not, should there be 2 idle poses?:
Also, animate at 30fps. Really, the only time animators animate at 60fps is probably for slow motion stuff, I think. At least, in my experience. Could be other scenerios though.
As far as starting your attacks from idle or from an anticipation pose... it really depends how much time you have until the "hit frame" In general, for faster/more responsive actions, you will want to start in a pose that is not quite idle, but not so extreme that it causes a noticeable pop when played back in game, where for for slower actions you can get away with starting from a pose that is very close to if not exactly your idle pose. You just have to experiment and see what works best for the type of game you're making. Good luck
1) Is it more commonplace to move/animate the character root in Maya, or keep it at origin, and have the game engine control the root?
Specifically regarding these animations:
- Dodge/ evade - left/ right/ forward/ backwards
- walking/ running - forward/ backwards
- sidestepping - left/ right
- jump - forward
2) How would you go about animating/ blending walk animations? For example, lets say in UE4: when the character walks forward and slightly to the right or left, do you blend two animations together (walkForward + walkRight or walkLeft)?3) For quick combat (similar to Dark Souls or Chivalry) Should follow-through (of an attack) be handled by animation blending between anim-states in UE4? Do you treat follow-through as the same as anticipation, in the sense that I have to decide between realism vs responsiveness?
1) I'd always keep the root at its origin and let the game engine control the root. If you need to move it initially to work out the footsteps and whatnot thats fine but I'd set it back to its origin once you've finished it.
2) In the games I've worked on we usually have 8 directional animations. Forwards, backwards, side-stepping and one for each of the 45 degree angles. Then for your example just blend the forward with the forward-45degree angle. Blending a forward directly with a side-step could give weird results.
3) I'd assume in a game like dark souls the follow-through would just be in the attack animation and then it would blend back to idle once its finished. Unless the player attacks again, then it would blend into the next attack or whatever movement the player initiates next
[url]https://www.youtube.com/watch?v=KkwWxSQOQ-U&feature=youtu.be&t=458[/url]
2. If you're using UE4, you should definitely read up on Blendspaces for this sort of thing. The idea is if you have a walk and a run, you can set the speed for the walk and a speed for the run and then easily blend between them
3. Again I think this is a balancing act to see what works best for your game, I think you have a bit more leeway with attack RECOVERY than you do with anticipations. That being said, you definitely want to animate the recovery, If you just do a quick attack and then put a heavy blend on the end it's going to look and feel pretty bad. Ideally you could set up rules that allow you to break out of the animation after a certain point.
Walk can go in 60 frames, really slow walk, and sprint in 16 frames, all them will be blended in game engine, however its important that your cycle starts from the same legs, if your walk starts from left leg up, passing position, your other cycle like run, jog, sprint should start from the same leg, if not, game engine blend behavior will not be so good as you expected.
Walk Cycles: It depends on the engine / animation system, but for most games you would do multiple sets of left then right footsteps within a single walk animation (maybe 4 cycles). We do this to add variety to the motion and make the walk seem less bland. The thing to be aware of with this is that you need to keep track of what foot you're on (sometimes referred to as the footstep "phase"), so that if you transition to a stop (or to a plant and turn, or whatever other animation), you know whether to play say...a left foot stop, or a right foot stop. Typically the way you keep track of this is to add markup tags (different engines have different names for this; some might call it markup events, or meta-data, or whatever else). This is additional information that you attach to the animation to specify what footstep you're on at any given frame. Usually you do this in the engine but again, different engines have different requirements.
In terms of how many frames for your locomotion cycles, again, that depends on the engine you're using and the specific setup that you're going for. In some cases you would have completely separate states for walk and run, and then you'd transition between the two (again based on on footstep phase). This is sometimes referred to as a "stepped speed" movement system, because you step between the different speed. In this case you don't have to worry about the number of footsteps or frames in each cycle: They're independent from one another.
Alternatively you might have an "analogue speed" movement system, where you gradually blend from one animation to another animation depending on the amount of stick deflection. This one is highly dependent on the engine. Some engines have a pre-made construct for this and you just plug the animations in. In other cases you do it manually. If you're doing it manually, you want to make sure that you have the same number of footsteps in the walk and the run cycles. You also want make sure that they start on the same foot. Finally, you want to make sure that the cadence of the footsteps is roughly equal (so don't have like a limp, where one footstep is slow and the other fast, mixed with a standard cycle). The exception to this last point is that your engine might have a "phase blend" node (again, this is likely called something different in every engine), that will blend each footstep individually. If that's the case then you can put whatever footstep cadence that you want in the cycles.
To make the cycles blend properly (this is with the manual method), you'd speed scale the walk and run animation so that they both match whatever speed your character controller is moving (based on stick deflection). You'd then set the blend value between the walk and run animation so that that's also based on the speed/stick deflection. This way your walk and run constantly stay in sync: If the stick is at 30% deflection, so like a normal walk, you would have a walk scaled to normal walk speed (so basically not scaled much at all), a run scaled down to slow motion, but because of the blend value, you'd see a much higher percent of the walk. If you then deflect the stick to 100%, both the walk and run would scale their speed up to closer to the run speed, and at the same time, the blend would start to show less of the walk animation and more of the run. That's a big difficult to visualize, so hopefully it's clear.
As for the frame rate to animate to, I'd suggest 30fps. That's what most studios do, although I agree for something like a fighting game you might want 60 because it's so precise. There are actually 3 things to think about here: The animation frame rate, as in the frame rate you made your animation at, the tick rate, which is how often the game world updates, and the rendering frame rate, which is how often the game renders a new image.
Unlike traditional drawn animation where a frame is a single drawing and you're popping between frames, in computer animation, the animation frames are defining a curve, and we interpolate between frames. This means that if you create an animation at 30fps, but the tick rate and the rendering frame rate are at 60fps or 120fps or whatever, you will still see movement on every frame. The game is just sampling the curve at a different rate.
Going above 30fps is more work because it's more frames to define. The only reason to do this, is say you want very, very fast, stylized motion (like a fighting game), you may want to have sub-30fps movements, like a very high contrast melee strikes. Of course, if your game doesn't tick at 60fps or doesn't render at 60fps, you wouldn't see it anyway.
Hopefully that helps.