Saturday, 10 March 2012

Tennis ball arc research

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.


Friday, 9 March 2012

Tennis ball bounce V2


Redone ever-so slightly. I've tweaked the positions of a few keyframes and curve slopes to increase the hangtime of the first two bounces. I think the whole thing's looking a bit too slow overall, feels a little sluggish somehow. I don't know how much of it looks weird due to the lack of squash and stretch - I think that, once I've put that in there, it might start to look a little better. As I said before the strict up-and-down movement is problematic. I find it quite hard to look at and analyse for some reason - my eyes tracing the same path again and again in quick succession make it quite hard to read so it's a little difficult to pick out what's up with it.

I think the last series of bounces (the really small ones) are probably still a little sharp. They don't hang in the air at all - I don't know if tennis balls do that? As they lose energy, do they drop from the peak of their jump much more quickly? All things I'd failed to consider beforehand; back to the videos...

Tennis ball bounce V1

Rough sort of thumbnail sketchy-thing based on the timings observed from the reference footage.

It's messy and probably quite innacurate - it's fairly difficult to work from such limited footage. Hopefully once I'm able to shoot my own, I'll be able to put something a bit nicer together, but this serves as a sort of basis.

From this, I put together a quick first draft laid out roughly according to the timing and spacing on the diagram. It needs a lot of tweaking but I think the basic principle is there.


It's pretty basic keyframing stuff so far with some minor tweaks to the fcurves to slightly alter the timings. Nothing major so far - no squash and stretch or rotation at all.  This will all come later, once I'm happy with the timing and spacing and so forth.

Some things I've noticed straight off the bat - the ball doesn't look like it bounces quite high enough to me, especially on the second bounce. It appears to be a really cheap tennis ball - one that's heavy, comes in a 3-pack from Poundland. I'm going to increase the height of the successive bounces a bit, and I think it ought to hang in the air a bit longer at the top of each bounce, too. It seems as if it hits an invisible ceiling at the top of each bounce, coming to quite a sudden halt - I don't think I've given it enough time to slow into the peak of its bounce so I'll probably space out the keys a little more.

It kind of looks like it loses energy and power too quickly and too suddenly, so I might even look at adding maybe just one more bounce in there towards the end, just to make it a little more gradual. Part of the problem might also be the fact that it bounces in a perfectly straight line, up and down in a very mechanical fashion, which looks pretty unnatural. I'll probably space it out and have it bounce across the screen just a little bit.

Tennis ball bounce reference footage & research

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.

Thursday, 1 March 2012

Bowling ball drop rotoscope V3


More playing around; altered the speed of the first drop, changing around some of the timings on the successive bounces and also tweaking the rotation during the rise and fall of each bounce.

It's still not looking right to me - I think now that it drops too suddenly on the second bounce, so I need to slightly adjust that one. Widening the top of the curve should sort it.

I'm actually wondering at this point whether it doesn't bounce quite high enough on the third bounce - it's obviously losing energy, but having such a short hop doesn't give much room for acceleration. I'm thinking that maybe we don't get a feel for its weight because there's not enough time/space between each keyframe to show the difference in speed as it climbs and drops again? Or something?

Bowling ball drop rotoscope V2


Started cleaning up the rotoscope; first I lengthened and slowed down the shot, which massively improved things. I think it's looking a bit better now; the main things I had to alter were, as said previously, the speed of the ball's drops and the hangtime at the peak of the bounce. I messed around with the rotation slightly as it's falling, and also reduced the distance that the ball rolls away.

I'm not terribly happy with the rolling at the end - it looks off to me, but I can't seem to put my finger on exactly what's wrong. I feel as if maybe it starts rolling too soon after landing - I can't explain it, but it looks as if the ball is sliding more than anything. Perhaps the rotation doesn't quite match up to the speed of the movement? Maybe it's the timing on the movement?

The initial drop seems a bit too slow as well - the ball lacks any real weight and I think some of the successive bounces need a bit of tweaking as well. They're a little choppy? Overall, I'm not too sure about any of it - the ball, to me, doesn't seem to carry any particular weight of character. Maybe it hangs in the air too long as well?

Bowling ball drop rotoscope

Taking a brief break from fcurves, thought I'd have a bit of fun playing around with Softimage's rotoscope options. You can basically attach an image to the back of any viewport to use as modelling reference. That in itself isn't especially useful for my purposes, but in addition to static images, Softimage allows you to attach image sequences as well.


I found a video on Youtube of a guy dropping a bowling ball in front of the camera and decided to try playing around with it.

Mucking around with trying to convert the file to an image sequence appears to have messed up the frame rate (it was probably originally shot at 29fps, come to think of it) so the final version appears to be on fast forward, but hey ho.


To attach the sequence, click on the display option dropdown in the top right of any viewport and click on 'Rotoscope' which will bring up the 'Rotoscopy' property page.


Clicking on New > New from file then opens up a dialogue box - by default, Softimage looks in the 'pictures' folder for all rotoscopy images. I used the terribly-converted bowling ball image sequence, which Softimage then pins to the back of the scene.



Scrubbing the timeline will play back the image sequence! Magical. The only problem is scale - as you can see, simply dropping in a primitive sphere reveals how tiny the image is, which isn't always ideal. In most cases you could simply scale down your object but in instances where you have a complex character rig, you don't really want to scale it down too much.


The other option is to enable the 'attached to camera' checkbox in the rotoscopy property page. This basically fixes the rotoscope to the lens of the camera so you're able to pan around with the camera and line up your object over the rotoscope without altering its position. You can zoom in and out of your object without effecting the scale of either the object or the rotoscope.


When you're happy with the positioning, you can turn on 'enable pixel zoom' (the square magnifying glass at the top of the viewport' which locks the position of the rotoscope and object together. 

Sorry if that made no sense. I'm still very tired!

Anyway, I didn't get too fancy with it. I just wanted to see how it worked, mostly, so literally all I did was trace the position of the ball with keyframes - no fancy fcurve editing (yet)!


Wireframe:


No distracting background:



Of course direct rotoscoping never usually works - for things like ball bounces the results can be decent enough, but in the case of more organic or lively motion (particularly walk cycles) the resulting animation can lose a lot of the original personality and weight. Rotoscope and motion capture can be a great starting point for overall timing and to get a very basic animation down, but they usually require so much cleanup afterwards you may as well be animating from scratch!

Anyway, I actually think that the rotoscope looks mostly OK - there's certainly a feeling of some kind of weight, but there's a lot of tweaking and refining that could be done. I think the overall speed is probably a bit too fast, mostly due to the problems in converting the frame rate - so I'll probably sort that out with the region select tool in the dope sheet. Once the speed is sorted out it should be a little easier to pinpoint the exact problems with it, but I think generally the series of successive bounces could use some work. Looking at the original footage there is a noticeable pause at the peak of each bounce before it comes back down, which mine definitely lacks. This should be easy enough to fix.

As an aside, I also think that the ball rolls away a little too long at the end, but that could simply be due to the fact that the rest of the animation is too fast in comparison.