Showing posts with label fcurves. Show all posts
Showing posts with label fcurves. Show all posts

Saturday, 10 March 2012

Tennis ball bounce V6

Are you bored of me yet?!



More timing adjustments! I used the region select tool to bring everything closer together so it's a little faster. I think it's looking better now actually - but there seems to be a weird jump right at the end. The ball seems to kind of... lurch forward. Not quite sure what's happening there - think it might have had something to do with the fact that I neglected to realise that I used the region select tool on the fcurves instead of the dope sheet. Ordinarily this wouldn't have been a problem, but I had it set to "isolate curve" so I only re-timed the keyframes on the y axis, so I reckon that the keyframes on the X axis are just a little out of sync. Hopefully it shouldn't be too difficult to fix...

Once that's all been corrected, I'm going to start looking at applying a little squash and stretch to the ball. Not too much, just enough to kind of emphasize the impact with the ground and the springy nature of this ball. Hopefully it will also help to highlight further problems with the timing and such.

Tennis ball bounce V3

The ball now bounces across the screen rather than a straight line. It's definitely much easier to watch and, hopefully, to critique.


The problems become more apparent now that it's spaced out. Working backwards from the most obvious things, there are problems with the trajectory of the ball - towards the end it kind of lurches forward before coming to a very sudden halt which looks a bit odd. The ball shouldn't stop moving as soon as the last bounce occurs - it should probably still roll around or continue moving across the floor for just a little bit before slowing to a stop.

The timing in general seems to be a problem. The ball, to me, looks a bit weighty - it still doesn't have the energy and power of an actual tennis ball. I still don't think that it bounces high enough - potentially, it could just be a timing thing. If I increase the speed of its ascension it might look a little better. Tennis balls are fairly light and springy - they don't tend to fall too fast but bounce off surfaces with considerable force and speed, so I definitely think it needs to accelerate faster in order to capture that "springiness."

Friday, 9 March 2012

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.

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?

Sunday, 26 February 2012

Post-tutorial wall bounce amendments

Following Jon's (very helpful) critique on Friday I amended my first wall jump exercise!

We both agreed that my ball hit the peak of its stretch on the drop a little too early, and he also pointed out that my ball remained in the squashed position once it began the jump, which looked a bit weird — it needed to stretch as soon as it left the ground. There was a similar issue with the landing — the ball squashed before it even hit the ground.


My first amendment was better, but the ball was still stretched on the drop a little too early, and Jon commented that he felt the drop itself was perhaps a bit slow. I do think that the speed of the jump and fall is a little too uniform, so on my next amendment I made an attempt to speed it up slightly by reducing the number of frames between the highest and lowest points and slightly altering the fcurve.


The faster speed seems better to me, but I think the stretch is still too early! It also seems to me like the ball comes down a little too quickly — I may try increasing the ball's delay at the peak of its jump, or just slow down the beginning of the drop a little.

I also went back and tried to correct the same squashing/stretching issues in my other bounce, the one with multiple jumps:


Something still seems at odds to me about this one, but I'm not quite sure what it is exactly. I think that maybe the ball hangs in the air a little too long on the first (and smallest) bounce, or maybe that it doesn't hold its initial downwards/preparatory squash long enough. The ball's squashes on each impact with the ground are also quite quick/sudden, so maybe I need to look at holding the squashes on-screen for just a little bit longer?

Friday, 24 February 2012

Softimage - interpolation experimentation V4


Yet another update. Still having difficulty ironing out that bug with the looping! It's bothering me. A lot.

Aside from that I've altered the ball's hangtime in the air. It's looking better, but I think it's still a little too much? I also think that now the ball drops around that first corner a little too fast. Arrrghh!! Am I never satisfied?! (The world: "no!")

Luckily it's a simple fix, just altering the slope of that first curve so it's a little shallower. I do feel that this is actually really, really helping - I'm far from confident, but I do feel I understand the fcurves a lot more than I did a week ago.

Just to talk a little about what I changed this time:


First thing, to get the nice overshoot at the top of the right side, I just brought the height of the curve a little above the position of the next keyframe. This gradual slope caused the ball to slow into a position slightly above the point reached by the next keyframe, then slowly dropped back down into it before continuing the movement. I also lessened the width of this curve on both sides, so that the ball wasn't hanging in the air quite so long before dropping back down.


The same principle applied for the overshoot on the left side; I dropped the curve a little lower than that keyframe. There's quite a sharp curve here, which shows the ball's acceleration to the bottom of the drop.


I lessened it slightly, but it's still a little too extreme. In retrospect I think that the problem with the glitchy loop is because I've put the overshoot in the wrong place. A better place to put it would be just before the last keyframe, as opposed to after the first. That way the ball can overshoot before the last keyframe, which will be identical to the first, allowing it to loop straight back to the exact same position and continue its drop. It just makes more sense that way (to me at least...)

Thursday, 23 February 2012

Softimage - interpolation experimentation V3


Slight update! I've added a little overshoot to either end of the ball's climb, which softens things out and adds a little more realism to the whole thing. There's a weird kink at the very end caused by looping the video - I think the start and end positions don't quite match up or something. Need to figure out how to get the overshoot without it jerking like that!



I actually shunted the position of a couple of the keyframes around a little bit, mostly the second one. I moved it a little further to the left so that it hit the lowest point of the drop a little more quickly, solving the problem of it falling too slowly at the beginning.

I need to look at fixing the kink at the end now, as well as reducing the ball's hang in the air at the right side.

Softimage - interpolation experimentation V2

A slightly more complex experimentation this time. I wanted to try and have the ball move in a semi-realistic fashion down a steep slope, rolling along the bottom of the curve and up the other side. Almost like a skate ramp - the ball would of course lose momentum as it begins the steep climb, so it probably wouldn't quite make it to the top before it rolls back down again.

Maybe viewing the video will make more sense...!


Looking a little shoddy thus far, but I think I can tweak it to fix it up a little. I cheated a little on animating the ball itself, but seeing as this is mostly an fcurve exercise I think I can get away with it! I drew the path using the bezier knot tool as described in one of my earlier posts. I tried to keep the angle of the slopes relatively consistent so that it would have an equal distance to travel on both sides. I then just set the curve I'd drawn as the ball's motion path by selecting the ball and using Create > Path > Set Path. The ball then locked itself to the first bezier knot point and the animation is automatically set to follow the path using a splined interpolation - a relatively lifeless speed and not at all realistic. 

Opening the animation editor reveals that the ball's speed and motion is controlled by fcurves! (I didn't screenshot it, sorry!) So I set to work tweaking and messing around with it.

The curves for this one are a little convulted, but I'll do my best to try and explain them...


The first thing I did was activate the animation ghosting for the ball so I could get a clearer picture of how my timing was without needing to play it back every time. This allowed me to much more accurately tweak my curves as I was able to see immediately after adjusting them how it would effect the animation.

Originally, the ball was a little too 'sharp' on the curve at the bottom. It followed the shape almost exactly so I needed to round it out a little bit so it didn't jump too sharply on the corner. I simply added a couple of keyframes either side of the lowest position at the bottom of the path and dropped the Y position a little, so that it remained on the bottom of the curve a little longer.



Starting from the first keyframe, I wanted it to slowly accelerate out of the highest point and pick up speed as it dropped down the slope, hence the sudden spike in the curve. I wanted it to keep a continuous speed as it turned the corner and uses the energy gathered from the sharp drop to propel itself up the other side. Gravity would be pulling down on the ball all the while, causing it to gradually drop in speed as it nears the top of the slope, eventually pulling it back down and causing it to roll back up the other side.

There's a very wide curve on the top keyframe that keeps the ball at its current level before gradually beginning its descent which rapidly escalates into a steep drop, increasing the speed of the ball. 

I think that I've sort of got the effect I was going for - it's getting there, at least. I think that the ball probably hangs in the air too long at either side of the curve, so I need to reduce the width of that curve so that it drops a little sooner. This might also allow me more time to adjust the acceleration so that the increase in speed is a little more gradual. I think that it gets too fast too soon as it falls from the right side. Conversely, I think it's too slow in picking up speed on the initial drop from the left side - simply shifting the width of the curve so that it's a little more equal on both sides should rectify that.

I also think that it stops too suddenly as it returns to the starting position, almost as if it's hitting an invisible ceiling. I'd like to add a little overshoot to that, so that it flies up a little further before dropping back down. Tweaking the curve so that it extends slightly below the final keyframe should give me that result.

Hopefully that all makes sense...!

Softimage - fcurve interpolation experimentation

More experimentation with interpolation and fcurves. Another set of three balls, each with the exact same keyframes, but with different timing as defined by their fcurves.


(Magical looping Vimeo version coming as soon as it gets processed!)


The first ball is a fairly standard example of slow in/out - the ball starts at a high speed and rushes out of the starting pose, gradually losing speed and slows in to the ending pose. It slowly retreats back out of this pose and slowly picks up a bit of speed as it makes its way back across the scren.


Looking at the animation ghosts for this ball reveals the movement in more detail. The spacing between each frame reveals the ball's gradual deceleration into the end pose. I've found that looking at the ghosts as I'm working has helped me to get a better grip on how the slope of the curve is altering the timing without needing to play it back.


The second ball appears almost cautious as it very slowly creeps out of the starting position then suddenly rushes forward to the ending position, leaping back and inching slowly back to the start. The movement is indicated by the curve's very gradual incline for the first few frames, suddenly spiking upwards as it draws towards the right side of the screen. It comes back almost as fast as it entered, slowing down again as it reaches the starting position.


The third ball is, again, a fairly standard slow in/out. I just wanted to play around with the unified slope orientation option mostly - it looks almost identical to the first ball, but the difference speed at either end is slightly less extreme and there is a little more of cushioning between the start and end points.

Softimage - fcurve interpolation types

In an attempt to better understand the fcurve editor, I'm going to be doing some far more basic examples of how the curves effect the timing/speed. To start with, looking at Softimage's preset interpolation types:


The three balls all have keyframes set at the same points. Although they reach the start and end points at exactly the same time, the way in which they reach those points is very different. In other words, the speed is the same, but the timing is different.

The first ball uses the default "spline" interpolation. Each keyframe will be connected by a smooth curve or "spline" (tried looking up what a spline actually is, but it made my brain hurt), eases into or out of each keyframe, creating very smooth and organic animation.


The curve shows how the ball gradually accelerates out of the starting position, then gradually slows into the second keyframe (the highest point on the graph represents the furthest distance travelled). It then slows out of that pose and comes back in the opposite direction, easing back into the starting position.


The second ball uses the "linear" interpolation type, which as the name suggests is a constant rate of motion with no "cushioning." Objects with a linear interpolation will have their keyframes connected by straight lines, terminating in sharp points at each keyframe, representing a constant speed and sudden changes at each into and out of each keyframe. The result is very mechanical and robotic, potentially useful in animating cameras or lights where such organic motion as offered by spline interpolation isn't always needed.

This ball's rate of motion is steady and unchanging. It starts and ends at exactly the same speed with no acceleration at all. The change of direction is very sudden and sharp with no cushioning from one keyframe to the next.


The last ball uses a "constant" or "stepped" interpolation which keeps the keyframe's current values (position, rotation etc) stationary until the point of change, at which point it will "pop" or "snap" straight to the next one with no in-between movement. This is primarily useful for blocking out the keyframes of an animation without any pesky inbetweens, making it easier to check that the flow from pose to pose is correct. It could also be useful for camera or lighting cuts!

You can see from the graph that the ball's x position remains at the same level until frame 25, where it suddenly snaps upwards to the far right of the screen (highest point on the graph). Again, it remains in this position until frame 25, where it suddenly pops back to the lowest point on the graph - the starting position.

It's mostly the spline interpolation I'm interested in at this point. I certainly understand the principle of how it works, I think it's just going to take a lot more practice to get my brain used to interpreting the curves as speed and movement. I'm going to use the same setup as above - three balls moving at the same rate - but altering the fcurve for each one so that I can better compare the results and, hopefully, start to understand how certain timings "look" as a curve.


Saturday, 18 February 2012

Fcurve experimentation - ramp roll V1


Setting myself a couple of little exercises to try and get to grips with Softimage's keyframes and fcurve editor. I decided to try what I thought would be a fairly simple task - get a ball rolling down a ramp before slowing to a halt. It was trickier than I thought.

I didn't know of any better way to get the ball to roll down the ramp other than to manually keyframe it every few frames to ensure it stuck to the surface of the ramp - if left to its down devices, Softimage would have simply allowed the ball to take the most direct route to the next keyframe - levitating the ball away from the ramp, or cutting straight through it, etc. This caused a few problems with the fcurve editor as each new keyframe places a new point on the curve, so adjusting the angle became a case of having to ensure that the curve ran continuously through each point. That meant a lot of handle adjusting and balancing.

It's looking really dodgy so far. I had trouble figuring out how to get the ball to accelerate on the ramp and slow to a stop at the end - it sort of does that, but it stops far too suddenly and the ball speeds up upon exiting the ramp. It should be easy enough to fix, once I've played with the curves a little more.

Wall bounce homework V2, take 3


Added some more bounces towards the end as the ball loses its energy, also tweaked the fcurves in a similar fashion to the last exercise to give the impression that the ball is throwing itself upwards with more force with each successive bounce.

I'd foolishly only been viewing it in RT playback whilst I was tweaking the curves, so now seeing it at true speed in an external video player has flagged up a lot of issues with the timing. Looks to me like the ball hangs in the air just a bit too long and it drops a bit too slowly as well. I could either re-adjust the overall timing using a region, as before, or I could slightly alter the fcurves to rectify this. I'll probably experiment both ways and see what happens!

Just for added excitement, here's a quick snap of what my curves for the y position looked like:


Looking at the curves I can definitely see that the ball lags too long on the first bounce. It's a very wide curve, so I'll shrink that one down just a bit and see about adjusting the slope of the ball's descents from each jump.

Wall bounce homework V2, take 2


Slight alterations made to the first bounce. In addition to increasing the height of its peak, I increased the time it took to reach that point by a couple of frames. This gives it enough time to reach the peak and start its descent with less of the sudden snap that it had before.

I think it's looking a little better, but hopefully some timing tweaks made by the fcurve will improve it even more.

Wall bounce homework V2

Similar to the last exercise but this time I wanted the ball to execute four consecutive jumps in its attempt to get over the wall.


Timing's a bit shoddy so far - these are literally just keyframes on the postion/scale parameters. I think the last two jumps are okay but the first two look off to me. I think it needs to bounce just a little higher on the first jump, or at least reach its current point a little sooner. I think there's too big a change in maximum height reached between the first and second jumps so that there's not really the feeling of successive power being built up. I need to alter the points at which it reaches its maximum stretch on rising and falling as well.

I'm also thinking of adding a set of successively smaller bounces after the final jump as it comes to a rest and loses energy. Should have done that first really!

Friday, 17 February 2012

Wall jump homework V1, take 2

I've dived once more into the terrifying waters of the fcurve editor and emerged very wet, very cold, and not necessarily any braver for it!

I attempted to alter the function curves to add a little more personality to the ball's jump, as well as re-timing a few of the keyframes using the dope sheet, in accordance with the changes made by the fcurve editor.

It took me a fair bit of tinkering to figure out how to alter the curves to best effect, but I think I finally have something fairly decent:


The overall result gives the impression of a ball leaping into the air to catch a glimpse over a very high wall.

The first thing I did was speed the whole thing up by using the dope sheet's "region select" tool to squash all the keyframes together a little more.


With the tool selected, simply drag a selection over the keyframes you want to re-time.


Then, holding shift, drag the handles on either side of the region and drag left or right to reposition/re-time all the selected keyframes. I think you can actually reverse keyframes using this tool as well, if you drag the region far enough in the opposite direction!

I reduced the overall duration of the animation from 41 frames to about 35; the result is just slightly faster but it adds a little more energy to the ball's bounce.


Once I was happy with the timing I switched over to the fcurves editor to alter the speed/timing of the ball's jump by adjusting the slope of the y axis' curve. By selecting "isolate curve" under the view menu you can temporarily hide out all the other curves and view only the curves of the selected parameters. Probably not necessary in this case but is tremendously useful if you have a more complex animation with a lot of curves all over the place.


I didn't get screencaps of all my curve alterations (there must have been at least 50 billion) but this was the one I ended up with. 

The large, sweeping arc at the top represents the ball's delay at the peak of the movement. it moves gradually more slowly as it reaches the height of the jump and remains relatively airborne for a few frames before gradually beginning its descent, picking up speed as it nears the ground.

Huh. Typing that out made much more sense than it did as I was trying to understand it in my head.

It's kind of embarrassing how long it took me to figure it out; it's a relatively simple idea and I mostly understand the principle of it, I think it's just a bit deceptively mathematical and my brain is having trouble getting to grips with it. I find that I'm having massive trouble reading these curves and graphs as speed and timing - my brain just won't process it. I think I've managed to whittle it down to a basic understanding of "the steeper the slope, the faster the movement," but when I start thinking about inverted curves I start to get confused again. 

I'm hoping that it will start to get easier and more natural with practice. I've never been mathematically gifted and anything vaguely resembling numbers tends to frazzle my brain more than I care to admit.


Anyway! I then went back to the dope sheet and altered some keyframes in accordance with the new timing of the ball's ascent and descent. I shifted the stretch poses as it rose and dropped a little further along, so that they would reach the peak of their stretch at a slightly later point (giving them enough time to squash into the next pose without appearing too sudden), as well as off-setting the squash at the top of the movement so that it occurred one frame later. The result was a tiny bit of overlap as the ball reaches the height of its jump and the bottom continues upwards to catch up, 'squashing' it at the top of the movement.

I'm still not at all comfortable with my use and understanding of the fcurves. I'm going to start a few more tests and try to get some different results - applying the curves to a variety of personalities/types of bounce etc. should hopefully give me more of an idea as to how the angle and slope of the curves effects the animation.