Help with animations
Moderator: Moderators
Help with animations
I have recently started redoing models in Expand and Exterminate, and am wonder if anyone could help me script a walk animation for a 4 legged bot...
- bobthedinosaur
- Blood & Steel Developer
- Posts: 2702
- Joined: 25 Aug 2004, 13:31
They have six legs, not four. I've got this dog-like 4 leg walk script. But if I recall, in E&E the legs are short and not long, clawed and not hoofed, and planted on the side not on the underneath, so this won't do.
Hey, um... I don't want to be a butt-head or anything... but the way that this thing's joints are currently designed, it cannot possibly walk.
The joints where the legs join the body need to become ball-joints or universal joints, so that it can rotate in Y as well as X at the same time, giving the legs a proper forward walking motion. The thing about the unit you're vaguely copying from is that it was animated using IK, and if you look at it... it's not even vaguely realistic. IRL, you'd actuate it with a pair or more of hydraulic actuators to turn the joints. You can actually do that kind've thing in Spring, if you turn off animation smoothing and use NOW steps that you've set up in Servo, if you wanted to get really fancy, although there is this wee problem about how certain orientations are reversed (kind've painful issue, wish UpSpring was fixed so that was no longer an issue).
At any rate... ball joints for the "hips", because just like human hips, or for that matter just about every walking animal... walking is a complex motion involving movement and rotation through all three axii at the same time. What you have right now will never look right.
And yes, before everybody yells at me... the Strider cheats. I gave it the barest suggestion of a ball-joint join under the "shell", but mainly counted on people just not being able to perceive it accurately, because it's hidden and the legs are moving pretty fast. I wouldn't exactly hold it up as a great example of unit scripting (er, unlike the Archer, whose walk-cycle was coded mainly by DRB)...
The joints where the legs join the body need to become ball-joints or universal joints, so that it can rotate in Y as well as X at the same time, giving the legs a proper forward walking motion. The thing about the unit you're vaguely copying from is that it was animated using IK, and if you look at it... it's not even vaguely realistic. IRL, you'd actuate it with a pair or more of hydraulic actuators to turn the joints. You can actually do that kind've thing in Spring, if you turn off animation smoothing and use NOW steps that you've set up in Servo, if you wanted to get really fancy, although there is this wee problem about how certain orientations are reversed (kind've painful issue, wish UpSpring was fixed so that was no longer an issue).
At any rate... ball joints for the "hips", because just like human hips, or for that matter just about every walking animal... walking is a complex motion involving movement and rotation through all three axii at the same time. What you have right now will never look right.
And yes, before everybody yells at me... the Strider cheats. I gave it the barest suggestion of a ball-joint join under the "shell", but mainly counted on people just not being able to perceive it accurately, because it's hidden and the legs are moving pretty fast. I wouldn't exactly hold it up as a great example of unit scripting (er, unlike the Archer, whose walk-cycle was coded mainly by DRB)...
Because if it doesn't make sense, it will not look cool when it moves. People have a very intuitive sense of motion, and if something doesn't make any sense, it's hard to convince them otherwise. With Spring, you have to be extra careful, because you can't cheat with stretching or distortion, like you can with IK systems.
Trust me, making the Spider look half-way decent was a royal pain... there are pretty good reasons why Nature has never created any animals with that leg configuration
Trust me, making the Spider look half-way decent was a royal pain... there are pretty good reasons why Nature has never created any animals with that leg configuration

Theoretically that "armor" on top of the part of the leg attached to the torso is covering over what would be a ball joint configuration, aside from the body/leg interface would the rest of the armature work at all, honestly I cant get it to animate quite right...
also argh what unit are you referencing, that I designed it based ofF of? Just curious, as I actually based this somewhat off of the light combat unit in earth 2160 combined with elements of the old EE URC bot model..
also what is IK?
To add to this.. If the current design is no good which of these other options might you suggest?

also argh what unit are you referencing, that I designed it based ofF of? Just curious, as I actually based this somewhat off of the light combat unit in earth 2160 combined with elements of the old EE URC bot model..
also what is IK?
To add to this.. If the current design is no good which of these other options might you suggest?

Here are a couple of shots. I think you can make it work, it just needs minor alterations of the hip joints, is all.

In this first shot, you can see how I blocked out the motion series, starting with the Neutral pose (gray). Always, always, always start with Neutral Poses at 0 or 90 degree angles, if you can help it, and move the parts via NOW during Create(), instead of fighting with the engine about rotational math. Only use angles on bits and pieces that aren't going to actually move, like the relationship of the "foot/shin" to the "knee".
As you can see, there is a very wide distance between the Final position (red) and Start position (green). Timing this transition is, in fact, the key thing. The time it takes to get from First Rest (yellow) to Final is the exact amount of time it will take to get from Final to Start. With me thus far?
Now, for the second shot:

In this shot, I am showing disjointed animation timing, a must-have for most four-legged walking critters (in my opinion, at any rate). The first versions of the Spider had perfectly synchronised right/left mirroring for the legs. This was mechanically "perfect", but it looked... to be frank... really wrong.
The reason for this, and I'm not saying this is "right" or "wrong" in some absolute sense... is that people's expectations of four-legged walking motion is highly conditioned by the real-world examples of four-legged animals we see every day- dogs, cats, horses, etc. None of these animals walk with perfectly synchronised strides!
The reasons for this are actually mechanically sound- it eats a lot less energy to move with a desynchronised stride for the distance travelled, because the animal can use its weight to aid motion and wastes very little energy on balance or counter-acting rotational forces. There are counter-examples of this (think about a cheetah's running motion for a moment) where animals are using synchonised motion at a very high speed, but even at high speed, most animals use desynchronous motion, such as the complex motions of a horse while galloping (where at one point during the cyle, all four legs are off the ground, resulting in a desynchronised 5-step motion cycle... one of the reasons why artists and animators alike have always been fascinated with horses).
In short... de-tuning the synchronistic elements of your animation and putting things out've step looks a LOT more realistic. For a more practical study... go read through the Strider's BOS code, it's included in NanoBlobs.

In this first shot, you can see how I blocked out the motion series, starting with the Neutral pose (gray). Always, always, always start with Neutral Poses at 0 or 90 degree angles, if you can help it, and move the parts via NOW during Create(), instead of fighting with the engine about rotational math. Only use angles on bits and pieces that aren't going to actually move, like the relationship of the "foot/shin" to the "knee".
As you can see, there is a very wide distance between the Final position (red) and Start position (green). Timing this transition is, in fact, the key thing. The time it takes to get from First Rest (yellow) to Final is the exact amount of time it will take to get from Final to Start. With me thus far?
Now, for the second shot:

In this shot, I am showing disjointed animation timing, a must-have for most four-legged walking critters (in my opinion, at any rate). The first versions of the Spider had perfectly synchronised right/left mirroring for the legs. This was mechanically "perfect", but it looked... to be frank... really wrong.
The reason for this, and I'm not saying this is "right" or "wrong" in some absolute sense... is that people's expectations of four-legged walking motion is highly conditioned by the real-world examples of four-legged animals we see every day- dogs, cats, horses, etc. None of these animals walk with perfectly synchronised strides!
The reasons for this are actually mechanically sound- it eats a lot less energy to move with a desynchronised stride for the distance travelled, because the animal can use its weight to aid motion and wastes very little energy on balance or counter-acting rotational forces. There are counter-examples of this (think about a cheetah's running motion for a moment) where animals are using synchonised motion at a very high speed, but even at high speed, most animals use desynchronous motion, such as the complex motions of a horse while galloping (where at one point during the cyle, all four legs are off the ground, resulting in a desynchronised 5-step motion cycle... one of the reasons why artists and animators alike have always been fascinated with horses).
In short... de-tuning the synchronistic elements of your animation and putting things out've step looks a LOT more realistic. For a more practical study... go read through the Strider's BOS code, it's included in NanoBlobs.