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?

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...)

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.

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!

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.

Wall jump homework V1

Got stuck in to some pretty complex stuff today, dipping our toes into the fcurve editor in some more detail. I never quite got around to understanding it fully during my own experiments so I was looking forward to a more guided and structured approach!

Homework for this week is to animate a ball trying to jump above a wall - the idea is to experiment with some more advanced keyframe tweaks using the fcurve editor to really nail the timing and get some personality into the ball. I'm going to start by completely ripping off emulating Jon's example, just to get a feel for the more structured way of working and try to get the hang of the fcurve editor.

Again, started by just roughly making a quick plan of how I wanted the ball to move. I scrawled out some beautiful and accurate drawings of the ball in the various poses that I would need, before moving on to figuring out their relative positions against the wall. Then I spread them out so I could see them more clearly and get a feel for how many keyframes I would need to lay down to get started.

The fact that it's such a simple animation certainly helps, but it's amazing how much a bit of forward planning streamlines the process. Within about 15 minutes I came up with something that's actually quite workable:

It's all done using the basic transformation tools - the wall is simply a squashed cube, the floor is a grid and the ball is a sphere. The sphere was animated using keyframes on the translation and scale parameters - following Jon's advice I animated one parameter at a time to save confusion, starting with the translation. When I was happy with that movement I added in the squash and stretch using the scale tool. It really helps to keep things simple and organised!

The next task is to mess around with the timing. I think the overall speed of the bounce is too slow so I'll probably shift everything a little closer together to speed it up a bit, before cracking into the fcurve editor to muck around with the timings on the jump/fall.

I'm aiming to have the ball spring into the air with relative speed, slowing down as it reaches the peak of its jump. I'll have it hang briefly in the air for a moment before hurtling back towards the ground. That should hopefully get me more accustomed to using the fcurves so that I can more confidently start mucking around and experimenting with other timings!

Slide homework V3, take 5

And here it is with tweaked timing on the roll across the table. I have nothing else to say about it, other than the fact that this is the angle it looks best at. Viewing it from the front reveals how terrible the rebound off the ring is! So I'm cheating and covering it up.

Slide homework V3, take 4

Still messing around with this one, trying to get that recoil off the ring just right. It's trickier than I thought!

   

It's kind of random, but I ended up looking at the above video for an idea as to how the ball might react on collision with a solid object. It looks like it actually keeps spinning in pretty much the same direction, so I tried to emulate that in the animation:

I'm still finding it quite difficult to get the timing on the rebound just right - the ball always seems to delay right before changing direction and no matter what I do, I can't seem to fix it. This was my best attempt. I guess I'm not quite getting the hang of manipulating keyframes! I did manage to reduce the delay slightly but that caused the ball to shoot off way too fast which I wasn't able to easily fix, given the relatively small amount of frames between the ball's position at the ring and the edge of the table.

I sped up the exit from the slide/entry to the table a bit but now, looking at it, it seems way too fast - a very sudden change in speed from the ball's descent down the slide. I'm going to tweak that once more to try and get a more consistent speed and then call it a day. 

I'm actually a bit more pleased with the rotation of the ball now, though - I had it change direction on the drop to the floor as it bounces away and it seems to have worked fairly nicely. One small success!

Slide homework V3, take 3

Made a brave attempt at altering some of the timings. Most notably the ball drops with significantly more weight than before - it certainly looks more like it's dropping rather than floating! I also attempted some timing adjustments on the exit from the slide, making it a little faster as it flies out the end and hits the table. I'm still not at all happy with the change in direction after hitting the ring - the physics feel totally off to me. I don't even have anything remotely ball-shaped to reference, and clips on Youtube are only so much help!

I've made some minor adjustments to the ball's bounces as it hits the floor as well, manually tweaking a few frames to give a slightly smoother arc. I've sped up each successive drop as well and brought the smaller bounces a little closer together to help give the idea that it's losing energy.

I can't quite seem to put my finger on why the recoil off the ring looks so off. It would certainly help if I had something to reference. I've got a slight feeling it might just be that the change in direction isn't quite sudden enough. It looks as if the ball hits the ring with a fair bit of speed, so it should probably fly off in the other direction a little more suddenly. Think I'm going to have to keep playing around with it.

I have actually added some rotation to the ball as well, but you can't see it owing to a lack of pattern or texture. I captured a version with the wireframe visible so you can actually see the rotation:

I actually prefer it without the rotation if I'm being honest - I think it's a bit distracting, but that might be because the rotation doesn't make any sense. I have absolutely no idea how colliding with the ring would effect (or is it affect?) the rotation of the ball, and as I said I've got nothing to reference. I went with my best guess and tried to just have it change direction to roll in the direction it's moving but that looks pretty clearly wrong to me.

I'd like to try adding a nicer rotation to the drop and bounce, as well as have it slightly teeter over the edge of the table just before it drops. I think in order for that to work I'd need to have a gradual deceleration after it hits the ring, so it approaches the edge a little more slowly.

But hey, it seems to be shaping up at least! 

Slide homework V3 update

Little update on the previous animation, I've plotted out the ball's drop from the table. It bounces a little as it rolls away - there's a minute amount of squash as it hits the ground, but I think it still needs a little tweaking. I think the arc of the bounce is getting there but the inbetweens need a little manual tweaking to get it smoothed out.

I rendered out a  couple of angles so you can see it a little better:

Bit of an issue as the ball goes down the slide - as you can see in the side view, it's a little too low and the ball clips through the bottom of the slide. Luckily that's simple enough to fix, just need to adjust the position on some of the frames.

There are a lot of timing problems with the last section - notably as the ball bounces off the ring. It's too slow and moves very uniformly - ideally, I think I need to speed up the ball's entry onto the table and have it knock against the ring with just a little more force. The ball could then lose energy as it rolls towards the edge of the table, pausing as it teeters on the edge, before dropping down. The drop itself also lacks any speed or weight - I've not yet adjusted the timing at all, so that will be my next task. After adjusting the timing on the drop I may need to tweak the squash as it hits the ground first time, depending on the speed of the impact. I don't imagine it's a very heavy ball, nor is it too much of a drop, so I don't think it should fall too heavily.

Regardless, it seems to be coming together! The rough motion is there, it's really just going to be about tweaking the timings and adding a bit of polish now. I plan to add rotation to the ball once I'm satisfied with the movement.

Slide homework V3

Here's a little progress on my third attempt at the slide task. It's not yet complete but I figured I'd take a breather and just talk a bit about what I've come up with so far and how the approach I've taken has been working out. These sort of half-finished progression posts are quite helpful I find!

So, this time I sat down and thought about it much more carefully, spending some time plotting out the path and action that my ball would take. I ran through the sequence at different speeds in my head and on paper, timing myself using a stopwatch and taking a very loose average of the timing that worked best. I plotted the rough keyframes on this sophisticated and totally accurate diagram: 

Using the chart as reference I was able to copy the keyframes over to the 3D counterpart, which really helped me to get to grips with the timing. I also took a brave stab at timing/spacing charts which you can see dotted all over the page - though certainly far from an industry standard I feel that taking the time to have a go at them myself really improved my understanding of how they worked. I've read lots about thinking in rhythms and spacing and beats but I just didn't really understand how to apply any of it. I think it's one of those things that, no matter how many books you read on the subject, you actually have to give it a go before the penny finally drops. 

I hope that made sense.

Anyway, though the resulting animation probably doesn't look too much different, the process and workflow of actually creating it was more logical and far more straightforward. A little forward planning really does make such a monumental difference - and a far less stressful experience.

It's not quite complete yet, as you can see. I still need to tweak a little of the timing as the ball exits the slide - I kind of feel that its entry to the table is a little too slow. I think it could stand to be a bit faster so that the impact with the ring causing it to roll off the table makes more sense.

Aside from that, I had a crack at giving the balls a little more weight and personality by squashing the red one as it pulls back and stretching it as it lunges forward, to give it a bit of strength. I think the impact of the peg with the blue ball has a little more kick as a result! I'm relatively satisfied with the path of the ball down the slide itself, aside from the aforementioned speed issue.

The next major thing is to get the ball to roll off the table and look at giving it a bit of bounce as it rolls away. Then I can go back and start manually tweaking the inbetweens to create breakdowns and ensure that the path of the ball is as natural as possible.

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! 

Slide homework V1

I'll be honest; I had absolutely no idea how to even begin approaching this one! I think I was so wrapped up in wanting to make something impressive and amazing and perfect that I just flailed around, trying to think of the cleverest, easiest way to animate the ball. I also thought it might be a nice idea to practice with some of Softimage's other animation tools... probably a mistake, considering I'm still not all that proficient or confident with keyframes! 

In this first example, I tried using the Create Curve tool to draw a path for the ball to follow:

Underneath the Create > Curve section of the Animate mode, there are a series of options that allow you to create curves or paths in different ways. I chose "Draw Cubic by Knot Points"... mostly because that's the only one I could find a tutorial for.

It works in a similar, albeit slightly more baroque, manner to Photoshop's pen tool. It's a little different; the pen tool allows you to adjust the curve/handles of the path after making two connecting points, but Softimage only allows you to manipulate the curve after placing the third - and the curve is set automatically depending on the position of the knot points. Here, for example, the depth/angle of the curve is drawn from the first and third points in the direction of the second. It's almost like the second point is a magnetic field and pulls the curve towards it, outwards from the knot at either end. That's a horrible analogy but it's the best way I can think to describe it, because it's really weird when you first use it!

The knots can be manipulated with the translate tool; use the 'Point Selection' mode (shortcut: T) to select the desired knot and then the translate tool to manipulate the curve.

Once I'd figured out roughly how the tool worked, I was able to trace a rough path of the ball's intended route down the slide and across the table:

First big mistake was not really planning how I wanted it to move; I just kind of went with the general flow of how I thought it might naturally progress down the table. I didn't think it too likely that the ball would travel through all of the rings on its course, so I had it bypass a few.

To attach the ball to the path, I selected the ball and used the 'Set Path' property found under the 'Path' section of the 'Create' menu. This locks the object to the beginning of the path and animates it along the curve drawn using the cubic knot tool... thingy. (That's the technical term!)

This will bring you into 'pick' mode; simply click on the path you want to lock the object to, and the object will then snap to the first knot on the curve.

The resulting animation is, unfortunately, a rather lifeless movement along the path. The movement is slow and unchanging with no life to it whatsoever; try as I might, I simply could not figure out how to alter the speed of the object. No keyframes appear to have been created, nothing in the animation editor, and I wasn't able to dig anything up on Google. I would imagine that figuring out how to alter the timing (if at all possible) could potentially yield some very nice results and make path animation a great utility, but at this point it doesn't seem worth worrying too much about. Animating with keys gives you much more control over the animation in a much more straightforward manner. I think I just got a bit ahead of myself! Still, experimentation is usually a good thing, right?

Croquet animation V2

Just realised I forgot to post my re-done croquet shots! Whoopsie!

I made some very minor tweaks to the croquet animation, probably not terribly noticeable with Blogger's horrible video compression! I altered the timing as the mallet swings back so it's a little faster and added a minor delay, just before it swings down. The downward swing could certainly use a little speeding up; seems a bit slow, considering the speed of the backwards swing. I tried to add a very slight overlap to the mallet after it finishes its swing; it drops back very slightly before coming to a rest. It's only minor and I think that if the swing was a little faster and the overlap a little more exaggerated, it would probably feel a bit looser and more lively.

I think the ball, despite my best efforts to create a slow in/deceleration, comes to too much of a sudden stop at the end. I've been finding Softimage's "predictive" inbetweens a little confusing to get to grips with, though I can't pinpoint why; I suppose it's best to go back and manually tweak them by hand in order to iron out the bugs, much like in After Effects, though it's not such a problem here with such basic animation. In the shot below you can see a large clump of keyframes; my attempt to "slow in" the ball to the ending pose.

I think I'm gradually getting to grips with the dope sheet. It certainly is more intuitive than the regular timeline... and it's not quite so headachey as the animation editor (which I know I'm going to have to conquer sooner or later!)

You might notice the weird red and blue afterimages following the ball in the screenshot above; that's the animation ghosting, Softimage's answer to onion skinning. It took me a while to figure out how to enable it!

Basically, you need to select the object(s) that you'd like to onion skin - in this case, the blue ball - and manually enable the ghosting feature. Open up the property page for the object (shortcut: Alt + Enter) Within the visibility tab there's a small button that says "Ghosting" - if this is checked on and ghosting is enabled within the viewport, you'll get a lovely wireframe trail showing you the position of the object on all the previous frames.

The option to enable ghosting within the viewport can be found in the same place as the headlight or object view options:

Simply check on the "Animation Ghosting" option and hey presto:

Lovely onion skinning! It's already proving infinitely useful in figuring out things like timing and just generally planning the animation. I'm hoping that, with a bit more practice, I'll begin to gain a better understanding of how things like timing and weight can better be achieved in Softimage. It's easy to forget that, even though the environment has changed, the basic principles remain the same. I'll probably go back and do some more tweaking to this a little later on now that I can better see what's wrong with it.

Lesson 02 — Explorer, Keyframes & Dope Sheet

Great lesson, learned a whole bunch (despite blog-related embarrassment...!) — the dope sheet I found particularly useful. I'd not previously been aware of it at all and it certainly answered many of the frustrations I'd encountered in my previous attempts at keyframing.

Initially, we were introduced to the basic animation interface and default timeline. We were shown how to set up the camera/output preferences - I'd been having great frustration with previous exports where all my stuff came out skewed no matter what I did so it was a relief to find out what I'd been doing wrong!

File -> Preferences -> Output Format

There are a number of preset output formats - however, these will be optimized for TV display, i.e. NOT square pixels. Best to use a custom preset! 

Ensure 'Maintain Picture Ratio' is UNCHECKED.

Pixel ratio: 1

Resolution: 1024 x 576 (widescreen)

Remember to double-check frame settings - should be working at 25fps. 

Hit 'Apply settings' to... well, apply the settings!

After setting up, we started by animating a simple object using basic keyframes on the default timeline. No fancy timing adjustments or dope sheet witchcraft here.

I, rather uncreatively, picked a sphere. And made it fly uncreatively across the screen. Hey, this was a technical exercise! Achieved simply by keyframing the scale and position values of a primitive sphere object.

We were then introduced to the dope sheet which allows for much more refined animation by providing greater control over keyframes. The dope sheet can be accessed by View -> General -> Dope Sheet, or alternatively by opening the Animation Editor (shortcut 0) and then clicking Editor -> Dope Sheet.

The dope sheet is, effectively, an expanded version of Softimage's default timeline. It displays all keyframes for all parameters of the selected object all at once - far more intuitive than the regular timeline, which simply displays all keyframes on one row which can cause a lot of really unnecessary confusion.

You can select and move all keyframes for all parameters by clicking the giant green square in the topmost row - very useful for making quick timing adjustments! Alternatively, you can select one or more keyframes for specific parameters simply by clicking the corresponding coloured square for each parameter. (Hold CTRL + click to select multiple keyframes)

We were provided with a premade scene file with a croquet mallet and ball. Using the dope sheet, we basically had to use the mallet to knock the ball from A to B, using the dope sheet to adjust timings where appropriate. 

Only really had 15 minutes to do this, so it's pretty unpolished at this stage and the timing's really squiffy. I tried to delay the hammer slightly before it comes swinging down to give it a little more character, though it still needs work. I'm thinking I may hold it at the furthest position for a little bit to add some anticipation. The ball is very static too - there's no feeling of contact or weight when the mallet strikes the ball and it moves very uniformly. I'm going to try and alter the timing so the ball decelerates before coming to a stop. I'm not entirely sure how to improve the impression of power when the mallet connects with the ball; I'm going to simply need to experiment with it a little bit. Maybe if the hammer swings a little faster it would help?

I've also gone over Jon's awesome exporting tutorial which, again, solves a lot of problems I'd previously encountered with exporting, so expect a post on that soon! 

Softimage XSI: Keyframes and the animation editor

Sounds like a great title for a film -Keyframe and the Animation Editor! Easily the next Harry Potter...

Anyhow, figured I'd do a little post on keyframes just to act as reference. I also find that this sort of recap is really helpful to me - having to go back and re-explain everything I've covered in words really gives you a good perspective as to whether or not you've truly understood something. If you can explain why and how you did something, it's gives you a more flexible knowledge of applying it. Or... something...

These things make sense in my head.

At the bottom of the screen is the timeline. It's fairly straightforward, works much the same way as any other timeline; it displays frames! Click a frame and it takes you to that point in the animation. Keyframes are represented by those little red boxes.

At the bottom of the window is a gigantic icon of a key - here I have auto keying turned on (which basically sets keyframes automatically whenever the value of an object is changed) so my big key is greyed out. However, turning that off for a moment, the key will appear green which means you can set a keyframe at that point in time.

(Auto keying appears to still be turned on at this point - ignore it, it lies! I turned it off!!)

Click the key to set the first keyframe at the beginning point of your animation. The key will turn red and a keyframe will appear in the timeline.

We can then select a new point in the timeline (frame 20, say) and change the value of our object to set the new keyframe at that point.

Now if we select the scale tool (for example - it works with any of the transform tools) and change the value (in this case, squashing our ball flat) the key will turn yellow. This means that a value has changed, but a keyframe has not yet been set!

Click the key and it will turn red, indicating that there is a keyframe at this point. The new keyframe will appear on the timeline, and an animation will be created.

It works much like After Effects or Final Cut or anything of that nature really, just with a slightly less fancy interface! You can also set keyframes with a keyboard shortcut - K.

Editing keyframes isn't readily explained and so confused me for a while but it's actually pretty simple once you know where to go! To shift the position of keyframes on the timeline, hold shift and drag across them - they will gain a white border to indicate that they're selected. To move them, position the cursor over the keyframes (a hand icon will appear), hold the middle mouse button (hand will "grab" the frames) and drag to move them along the timeline!

You can also right click selected keyframes and right click to cut, copy or paste keyframes. You can also delete 'em from here!

This is probably the most useful way of getting your initial, basic animation down, but it's very limited and doesn't give you terribly fantastic results by itself. The real tweaking and refining seems to come in the form of the Animation Editor that I talked about previously:

This big, scary chart shows you the curves of your keyframes, plotting its motion/position through time and space. It's terrifying and I didn't understand it at first (still not entirely confident with it) but I've spent a bit of time looking into it and it's beginning to make more sense now.

It basically plots the keyframes of any given parameter of an object on a chart. By default it displays EVERYTHING, which for a complex animated scene means lots of wiggly lines everywhere, but you can filter the display and select what you want to see with the menu on the right. Here I've selected the "pos y" movement - i.e. the up-and-down movement of a bouncing ball. The little green dots are keyframes!

The bottom row of numbers on the chart are frames. The numbers on the left basically represents the value of the parameter - so, effectively, dragging the keyframes left and right on the chart adjusts the timing whereas dragging them up and down alters the spacing or shape or whatever (in this case, for example, dragging a keyframe upwards would move my ball higher into the air on that particular frame).

But that's not all! You can also really fine-tune the slope of each curve to adjust the timing and spacing accordingly. Using the keyframe/animation editor select tool (keyboard shortcut Y), click on the keyframe (or keyframes) and these little bezier handles appear.

You can drag these around and alter the slope of the curve, tweaking your animation accordingly. You also get a nice onion skin-type thing that shows you the old curve for comparison.

You need to be careful with the editor however as it can actually place frames between frames (called "ticks") is probably useful in something complex like a walk cycle or other complex movement. However, in this instance, it would be more of a hindrance. To turn it off, click on Edit in the Animation Editor and make sure "Auto snap to frames" is checked! I wasn't aware of it at the time so I ended up with a lot of these "ticks" all over my timeline... quite confusing and made editing the timing/spacing very difficult.

I knocked up a quick ball bounce using this editor to try and get a feel for how it worked. It wasn't entirely successful, but it's getting there.

The timing's a bit off - I think there needs to be more of a clear acceleration as the ball drops and I possibly need to hold the squash for just one frame longer? The second and third bounces are too jittery - there needs to be a clear distinction in height and speed to give the impression that the ball is losing energy as it comes to a stop. They're very similar right now - it kind of judders then suddenly stops. To be honest most of the problems were due to my lack of knowledge of the interface (weird as that sounds). I couldn't figure out how to achieve those things because, at the time, I didn't understand how the animation editor worked or how I was supposed to alter the timing properly. I now have a bit more understanding, though, so hopefully I'll be able to improve things on the next attempt!