I'm still not totally sure on the whole arm movement thing so I've been examining some other reference a little more closely. I found this lovely example on Youtube:
The flexibility is amazing and puts me to shame. My cycle looks like arse in comparison.
Ignoring my bruised ego, the arm movement is very nice! I promptly shoved it into Photoshop and brutally ripped it apart for the purposes of analysis.
I've done my best to identify where the key poses in the cycle are — not sure if I hit them 100% accurately but they seem to be roughly in the right place. Obviously there are differences in my cycle and this one — the torso here is much more flexible but in a way it's a good thing. Viewing a more exaggerated animation means it's much easier to examine how arms are following the body.
The contact poses are interesting because of the forearm placement. They're poised up and ready rather than lowered, as I'd been toying with, which I think was giving me problems as it was making things a bit 'busy.' It's also a nice pose in general — having the arms almost tensed like that gives a much more cautious look to the character. The wrists are very nice too!
As the character drops into the down position the torso moves forward and the elbow follows. The forearm relaxes very slightly and comes down.
As the body starts to rise again the forearm is brought closer to the chest and the elbow, again, starts to come back. The character rises into the 'up' position and the forearm again lowers very slightly.
The second contact is slightly further forward than the first one, to counter the leg.
As previously observed most of the shoulder movement seems to come from the twisting of the chest.
That diagram is a bit cluttered, so it's probably easier to see with the body:
Serves to give a better idea of the shoulder and elbow in relation to the body.
It seems to have been helpful, though now I'm worried I've mucked my cycle up completely and that this method won't work. It's certainly given me something to toy around with, though, which can only be a good thing.
Taking a bit of a break from the standard walk cycle for a bit I decided to make a start with a more "characterised" walk cycle. I opted to do a "sneaky" style walk, because... well, I just did. There's plenty of reference already available too - The Animator's Survival Kit has quite a nice section that goes into the mechanics of sneaks fairly well:
Similar to our conventional walk cycle, Richard Williams also provides us with a solid formula to work from:
I thought this would be an interesting kind of walk to attempt to emulate with the Moom character, especially with all the bending and twisting going on in the torso. I find the arms quite interesting too, I love the way they're posed almost timidly. They remind me of a little hamster! I think it would be possible to get some really nice head and wrist movement with this walk.
To save myself a great deal of stress, I decided to adapt this formula for my characterised walk cycle. Just copying the frames is no good by itself though, it doesn't really give you any indication of the timing or any real sense of the weight. Observing and performing the action yourself is always the best way to go.
There's a disappointing lack of reference footage online for this particular sneak, but I did find a short clip from the DVD set that kind of demonstrates it:
It's not brilliant but it does serve to give you more of an idea about how the weight shifts in relation to the movement of the legs and so forth.
I also did a sketch of the key frames from the diagram - it's pretty much just a carbon copy but I found that having to draw the poses myself gave me a much better understanding of how the body was poised, how the hips were tilted, where the weight was, etc. Even if you're just copying it's always good to draw things yourself - it gets you actually thinking about the mechanics of what's going on.
Following these examples, I started blocking out the walk cycle using Softimage's "stepped" interpolation method. Being able to set up and view the key poses without Softimage's rather distracting automatic keyframes. It allows you to much more easily check the flow between each pose and quickly see where things don't align.
Getting the poses right was actually a lot trickier than I originally anticipated. Due to the way the rig is set up it's really tricky to try and get the curve in the spine just right — I tried all sorts of methods including some ridiculously over-complicated method involving translating his chest object to bring it in line with the hips, but it just looked weird. Ther doesn't seem to be any way to adjust how much he leans forward with this rig — tilting the hips and chest does not re-position his upper body at all, and translating his upper body control moves his entire body. As a result he doesn't lean forward quite as much as I'd like, but I think it's looking okay.
There are also some slight issues with the foot slipping around — his back leg goes back too far on what I think is the passing position, when he leans forward. It needs to stay stationary to give the impression that he's pushing himself forward.
Switching to splined interpolation allows us to see that his foot definitely slips back, and there's also a bit of a weird 'bump' in his torso around one of his contact positions. I think there's a stray translation keyframe in there somewhere that got left behind.
Various attempts to start blocking in the remaining keyframes for the arms, none of which were particularly successful.
Version 11
I think this one could probably have worked had I tweaked it a little more; there's a bit of a kink in the arm when it comes forward on the down position. I tried to have it carry on forward, as in Richard Williams' cycle, but to be honest following his diagram for the arms has always given me issues. I find that the motion is a little too formulaic and robotic-looking. It's a great basis for the keyframes and understanding the principles of the movement, don't get me wrong, but I don't think that having the entire arm continue forward works too well. I think that for best effect only the forearm needs to continue forward - the upper arm could stay mostly still, or even have it start to come back already.
Version 12
In this attempt I tried to work some slight joint breaking into my key poses, thinking they were as 'key' to block out as the positions of the arms. With the way that Softimage interpolates keyframes, though, it probably wasn't the best idea. The arm wobbles about a bit weirdly - again, with some adjustments it could have worked, but I think it was just a bit too complex at this stage.
Most of the movement came from the shoulder in order to 'break' the joint - looking at the fcurves shows the problem:
They're all bumpy and uneven as Softimage tries to calculate the path of motion. With some manual tweaking to smooth them out it could possibly have worked but I don't really think the poses themselves were strong enough to really warrant the effort. Back to basics.
Version 13
Looking at this version after a break it doesn't look as bad as I'd initially thought. I should have kept the rear arm stationary - it's a bit distracting - but arguably I think I've sort of hit the key poses for the arm fairly well. I think the only thing is that perhaps it delays too much as it's forward; perhaps I should start moving the upper arm back a little sooner as the forearm continues forward. The weird bump issue with the up and down is still there; I really have no idea what's happened, as all the keyframes are exactly the same. I can only assume that something's gone wrong somewhere with the interpolation.
Even with Richard Williams' diagram I'm finding it very difficult to line the arms up correctly, particularly on the 'down' position. Walk cycles in any medium are difficult but I'm finding the whole thing compounded by Softimage's lack of an onion skin. Continuing the swing forward on the down position is tricky to align without it jerking about weirdly (as seen above) - at one stage I even started looking up some similar 'casual' walk cycles in an attempt to understand how they'd posed the arms on their own rigs and to see how the interpolation was working.
I found some very nice examples:
What's interesting about this one is that nearly all the movement is in the wrists and forearms; the biceps and shoulders don't go very far at all. It's a lovely, subtle movement.
Owing to our limited rig, though, something like the above might not be wholly possible. So I found something a little more 'typical' and similar to the Williams example.
Again, some really lovely overlap and the upper arms don't travel so much. Using the above as a guide I tried to roughly emulate (read: shamelessly copy) the positions to get an idea of where I might be going wrong.
Version 14
I managed to sort out the issue with the bumping at this stage; somehow, the fcurves got slightly altered on the hip object. I have no idea how but the curve was completely out of whack and had inverted itself; simply altering the slope of the handles to smooth it out fixed the problem.
The arm's pretty similar to V13. I think it's alright, though arguably I don't think I've hit the poses as well as before. The arc of the swing isn't really there - it kind of travels diagonally from its position on the down pose to the reverse contact, so I need to look at sorting that out.
The arm also remains mostly stationary on the down position, not really doing anything at all. As above I need to continue the forearm going up and maybe even start to move the upper arm backwards.
I'm going to mess around with it a little more and see if I can sort that arc out!
I slightly altered the bounce so that there was a little more delay between the peak and the drop. I think having a slightly "choppier" drop works well for stationary balls, but when you start to introduce motion and arcs it looks a bit weird - you can't have the ball suddenly clip to the floor whilst maintaining the slow and steady forward motion.
I think it's looking alright, but I'm not too happy with it. I don't think it really moves enough in an arc, especially on the first bounce - it seems to hit an invisible wall then suddenly drop down. That's possibly why it looks so odd on the medium closeup view? I need to smooth that out and perhaps increase its forward movement just a tad.
It's only noticeable on the side view, but the ball's initial drop is once again bothering me. I think it starts too quickly - I need to ease it out of that forward shove before it drops.
Going back to one of my reference videos, I also noticed something about the second bounce:
You can't really notice it without going frame by frame, but the ball actually remains on the ground for an extra frame before it bounces back up into its last, tiny jump. I'll need to look at incorporating this into my own animation I think, see how it looks.
Getting hold of and dropping a bowling ball myself isn't really too practical, so I've been poking around online. Fortunately it's a fairly basic exercise in animation so there's plenty of pretty clear reference footage to use!
It's quite interesting to note how the ball rolls after being dropped in one video, but not in the other. I'm guessing it's because in the first video the ball is given more of a push forward as it's being dropped, whereas in the second it's simply released with his fingers and so drops straight down.
It's a bit difficult to determine the height from which it's dropped, but I wouldn't think it's much more than a metre. The ball hits the floor quite quickly but doesn't seem to accelerate as fast as the tennis ball - it actually seems to have quite a steady rate of motion. It hits the ground after about 10 frames - the same as the tennis ball - and bounces just once or twice (the second bounce is tiny, the ball barely leaves the floor) before rolling away.
I'll probably do a couple of different versions - one without the roll, and one with the roll, to see what looks best.
Finally got my greasy mitts on a tennis ball that bounces properly. How exciting! I've now been able to shoot my own reference footage for the ball, which I hope will make my life just a little bit easier...
(Please excuse the mess. I've not hoovered yet - I swear I'm not always this grotty)
I did a number of drops, just to get an average. I'm guessing the carpeted surface may have affected the bounce somewhat; but I'm just going to say it makes it more like the grassy surface on the scene file!
I don't really know which shot I'm going to use for reference. It's tempting to do one that's a bit different instead of a generic bounce, but there's the danger that it wouldn't look right when viewed through one of Jon's preset cameras. I'm probably just going to stick with the last bounce on the first video... it's a bog-standard looking bounce, but it seems a fairly safe option. Plus I'm getting a bit sick of tennis balls by this point!
Poking around on myUCA, I found the reference videos that were very kindly posted up. My own set of shuttlecocks have actually arrived now, so I'll be able to shoot my own footage to use, but I thought it might be helpful to practice animating a basic drop of a shuttlecock before I get into throwing them around.
Analysing the video, I was able to break it down somewhat and figure out the main timings:
It's actually quite a tricky one to plot in thumbnails. I got a bit confused somewhere along the way - started out alright with the first graph by just showing a few of the poses and a few scribbled notes, but the second graph started to get a bit confusing where I started trying to get in more of the exact motion. I started by sketching it all in one place then halfway through started spacing it out (mostly cause I didn't have enough room on the left. Didn't occur to just sketch it going in the opposite direction) - it's fine for purposes of checking the poses but it doesn't make much sense in terms of what the shuttlecock is supposed to be doing. I should have refined it further and made a clearer, more final chart that makes sense to look at before trying to animate. Perhaps that's where I went wrong.
But anyway, looking at the video reference, the shuttlecock drops very quickly to start (weighed down by the tip), taking about 9 - 10 frames to fall. It hits the ground, tip-first and bounces back up again, slowly sagging to the side as it does. It doesn't bounce very high, and it pauses for a couple of frames but continues rotating slightly before it starts to fall. It lands on its side and the tip strikes the table/ground which causes it to bounce back up. The feathers of the shuttlecock hit the table as well which knocks the tip back forward - so you get a sort of wave effect as it rises and falls.
Bearing all this in mind, here's a first attempt:
This is mostly just a first draft, nowhere near complete yet - as always, little more than keyframes with no fcurve or timing alteration. That will all come once I've got the basis of the motion sorted out.
Just to review what I've got so far, the drop itself as the shuttlecock enters the screen is far too slow. It's only 10 frames, as per the diagram, but I don't think I really dropped it from high enough. If I increase its starting height then it should speed it up quite nicely.
It doesn't really bounce high enough after striking the ground, making it seem quite heavy. All I'll need to do is just increase the height of its peak and it should be a bit better.
The last problem is the bounce at the very end as it comes to a stop. I don't know if it's the timing, or some mistake in the keyframes, or even if it just looks weird because it's bouncing on the spot - but it seems to be a bit of a kink as it bounces off the table. I really can't put my finger on it - it's weird, when I step through it frame by frame, it actually looks fine, so I wonder if it's just in the spacing or timing?
After tweaking that, I plan to spread things out so that the shuttlecock bounces across the floor rather than up and down in a straight line - see if that helps things any - and then start looking at altering the curves and timing to give the shuttlecock a sense of weight. In accordance with the video I'd like to delay the shuttlecock at the peaks of each bounce for just a couple of frames and keep it rotating as it hangs in the air.
The process of animating the shuttlecock so far was pretty simple. Using the reference video posted on myUCA, I simply went through frame-by-frame, identifying key poses for the shuttlecock and simply replicating them within Softimage using the rig controls.
The shuttlecock rig is quite nice because it only has two controls - rotation and position - but I do find it very difficult only being able to view keyframes for one set of parameters at a time. This makes offsetting and re-timing things quite tricky as I need to keep flipping back and forth between each rig control to check the location of other keyframes.
I think the biggest mistakes I made in terms of workflow were not planning properly and also animating the shuttlecock bouncing in place rather than mimicking the motion in the video and having it go across the table. You'd think I'd have learned from the bouncing ball exercise that that's a bad idea!...
Thinking about spacing the tennis ball out so that it's not bouncing up and down in a straight line, I had a look back at some of the videos to try and get to grips with the pattern of the arcs after the ball first hits the ground.
Using the same videos as reference, I took the frames where the ball was at its lowest and highest points, dropped the transparency (acting as a sort of onion skin) and, from there, was able to loosely scribble the path of the arc that the ball took.
Forgive the horrible scribbly lines... I'm running Windows through an emulator which doesn't have native tablet support...!
Anyway, as you can see, the ball takes a sharp arc upwards but doesn't travel very far away from its original position. Each successive high point of the ball almost overlaps its previous downward path.
Slight difference in this one, the ball doesn't drop straight down after he drops it - presumably it's a bit windy or something - but usually, the ball will pretty much drop straight down, providing there's no other force acting upon it. The ball will be propelled slightly forward after its initial contact with the ground and will start to bounce away from its original position. Again, you can see it's quite a steep climb, but it doesn't really move very far away.
I also found this interesting image floating around online:
A stroboscopic/high-speed capture of... a bouncing tennis ball! It demonstrates the path of the ball very nicely... and you can even see the rotation. Interestingly, as the ball loses power, the arcs appear to get a bit wider and the ball travels slightly further. The bounce also appears to be a little slower, judging from the spacing, not quicker as I'd originally thought. (No idea why... thinking about it logically, it makes no sense. I suppose that if you just watch a ball being dropped because it's bouncing lower and lower it appears faster?)
Anyway! Very useful stuff, so hopefully I can now make a bold attempt at spacing out my animation and getting it to look a little nicer.
Started doing a little planning for the first of the three ball bounce exercises - the tennis ball. I did try in vain to get hold of my own ball to film, but was completely unsuccessful. The only ones I could find that weren't professional grade were 74p from Pets at Home and didn't bounce properly - so, until such a time I'm able to get hold of one, I'll have to make do with raiding Youtube.
I did find an interesting website called Animation Physics that offers a large number of handouts covering details of real-world physics and their application to animation. It's incredibly heavy reading and very, very mathematical. Their handout on the physics of timing and spacing refers specifically to dropping and bouncing balls of varying types. It's very heavy stuff, with lots of precise formulae and calculations regarding drop speed and air resistance etc. I wasn't able to make complete sense of it but I did manage to pick out a few key pointers that I thought would be useful:
The spacing between poses of a falling object can be calculated using a principle called "the odd rule." Basically, it means that the spacing of the object will increase following a ratio of 1:3:5:7:9:11. So, following the first pose (or drawing, whatever) the second will be spaced three times as far, then 5 times, then 7, etc. etc.
To be totally honest, it sounds really convulted and confusing and mathematical - I think, to really dumb it down, what it's saying is "make sure a falling object gets faster." Which makes those last two paragraphs completely redundant. Oh well.
The tutorial does come bundled with some lovely reference clips however, including some rather excellent footage of a ball being dropped in slow motion:
It's fair to assume that it's probably not a tennis ball - it looks like one, but doesn't bounce as high as you'd expect one to. It only reaches a third of its initial height, when tennis balls tend to reach around half their original height (as shown in the videos below.) It is useful for analysing overall drop speed and spacing, however!
There's an astonishing lack of bouncing tennis balls online, but after a bit of digging I was able to unearth a couple of other decent clips:
This one is particularly interesting as it breaks down the speed of the ball's drop in a fair amount of detail. The video highlights the fact that the ball loses half of its height with each successive bounce - it's dropped from a height of 2 metres, which means that with each bounce it would hit 1 metre, 1/2 metre, 1/4 metre, 1/8 metre and so on until its energy is exhausted.
The height isn't specified in this video, but if we assume that it's also dropped from about 2 metres we can again see that the ball's height is roughly halved with each bounce. The ball bounces around 6 times until its energy is completely depleted and it comes to a rest. The ball takes around 16 frames to drop from its apex (peak) and hit the floor - using this as a basis we could assume that a ball dropped from 1 metre would take around 12 frames (half a second) to hit the floor. Giving the ball 4 -5 bounces until its energy is depleted would make the total time around 2 - 2 1/2 seconds (about 50 frames).
I'm starting to sound very mathematical, but I'm just using this as a rough guide to get me started, a basis to work from - I'd imagine that the final animation will end up deviating from these times somewhat! What's physically correct in reality doesn't necessarily look good on screen. A lot of the timings will be tweaked by eye in order to avoid getting something stiff and a bit lifeless.
