Slide homework V2

Second attempt at the ball and slide task, this time reverting back to good old fashioned keyframe animation!

This isn't entirely finished; the drop of the ball is totally off and I'd originally wanted to have it bounce away as it hit the ground. I've sort of hit a brick wall with it, though, for reasons I'll get to in a moment.

I think it started out rather well - though a little quick on exiting the slide, I think the timing going down and shooting off at speed was heading along the right lines. However, I began to get really confused once the ball was on the table. I found that, where I'd not really considered my timing too much in advance, I was kind of working on the fly - which can sometimes work very nicely - but in an unfamiliar software environment it can be pretty detrimental as you're not really learning anything about the tools or how they can be applied. You're not entirely sure what you're aiming to create, so it's hard to see how the tools can be applied to achieve the desired effect.

I think I was skipping a lot of fundamental stages, creating too many keyframes (which should have acted as breakdowns) before I'd even set down the main keyframes, so the predictive/automatic inbetweens were going crazy and causing me to get very confused with my timings! Without laying down the basic timing it's very hard to get convincing animation in any case. You'd think I would have learned this by now!

I think that a lot of it is due to the unfamiliar environment. As I said in a previous post, 3D seems like such a radical departure that it's easy to forget that the same basic principles apply. "Keyframe" seems to mean something completely different when applied to digital animation, and I think that screwing up on this attempt has helped me to re-evaluate how I'm using the software. I've somehow convinced myself that 3D/digital animation requires a whole new skill set, which is of course completely untrue. It should simply be an extension of the pre-existing skills; applying what I already know to a different architecture.

I can now completely appreciate what Jon meant when he talked about the importance of planning in digital animation. That isn't to say that I've been totally thoughtless about these tasks - I've certainly been considering timing, but I think I'm too impatient, too anxious and too keen to get to the final result and prove to myself that I can do it. I imagine that's fairly common?

Anyway, going back to the animation itself; it doesn't look too bad now that I look at it - I think the basics were there - but by the time I'd gotten the ball onto the table I was so confused  by the mass of keyframes staring back at me that trying to fix it seemed an impossibly daunting task.

I'm going to go back a bit and try really thinking about this - timing it properly, considering exactly what I want the ball to do and laying out the keyframes on paper first - just like I would (or should) do with any conventional animation. It will then be much easier to pinpoint where my breakdowns need to go and which frames need tweaking by hand. I might even try my hand at one of those impossibly scary animation charts... doesn't matter how much I read about them, I still seem to be frightened off by the prospect of numbers!