Category: 3D Animation Fundamentals

Preparations

I spent some time browsing the available rigs in the UAL asset library when considering my ideas for this project. Though the Hulk would’ve been fun, I decided the gymnast was a better option for a couple reasons; the first being that a small and agile body would be both a challenge and great practice for me to maneuver in precise, acrobatic positions, the second being that the minimal, tight clothes would allow me to better learn what I’m doing without the distraction of attempting fabric animation or preventing object phasing. Now, as with any typical young American, Simone Biles comes to mind immediately whenever gymnastics are mentioned. I allowed myself to spend some time watching her performances during the 2016 Rio Olympics before coming to the decision to use her floor performance in the 2018 World Championships. The clip below is actually probably the least impressive part of her routine, but I thought that more jumps and less triple backflips would not only be easier for me but also help me learn more about weight.

Once I’d selected my clip, I spent the entire first work day and part of the second sketching out a storyboard. I ended it at her final pose, but intended to allow the video several more frames afterward as a “cool down”, where I let the body adjust to its position and practice smaller, realistic, subconscious movements.

Preparations Continued

I could barely wait to begin animating. But unfortunately, technical difficulties lay ahead. When I opened the project in the UAL Maya Launcher through VMware, I was able to view the texture and assets that come with the rig, but I was met with the annoying difficulty of my Alt button not working. I’m not sure if it’s because I have a Mac or a USA keyboard or a combination of the two, but I was stuck using the onscreen keyboard. After a couple of poses, however, I realized that working that way was simply not sustainable to a productive workflow and switched back to working on the project without VMware, resigning myself to the back-and-forth of downloading my project between the two remote desktops when I wanted to do serious animation work vs when I wanted to render.

As an aside, I did purchase myself a UK Windows keyboard to ease this difficulty. It arrived after I’d already finished all the keyframes for this project, but I’m very excited to make use of it in the future. It makes me feel very cool as I stare at my screen for hours on end.

Day One

After a couple of days of technical difficulties and preparation, I began animating. I found it surprisingly easy compared to my last project, and had finished almost half of the key poses within only five hours, whereas the Knight took me almost four days merely to finish the blocking pass.

I attribute this to me knowing more about how to work a rig, as well as the lack of distracting clothing. I was able to go into this one with the knowledge of which pieces of the rig to never touch, and so didn’t make the mistake of animating the root control. I also was able to use the knee controls to my own benefit rather than them being a source of stress and confusion. One thing that I will say that has frustrated me a little, though, is that I’m unable to animate her ponytail much without skin folds on the back of the neck behaving oddly, so I wasn’t able to put in as much fun hair movement as I had hoped. I was extremely surprised and happy with my success on this first day, and absolutely couldn’t wait to see this hyperrealistic rig in action, so I transported myself and my project back to VMware to render, out of curiosity. Every time I do this you must imagine me with my project files in a virtual briefcase at the virtual bus stop waiting for the digital 12 to Oxford Circus.

I was beyond delighted with how the rig looked in action, but after many hours of gazing awestruck at my work, I realized that the right arm looks a little bit janky on that second jump. It flaps around bizarrely like a robot getting stuck. I resisted the urge to prolong my work day and made a mental note to resolve it first thing the next morning.

Day Two

I went into Day Two with more confidence than I ever have on an animation exercise. I fixed that arm joltiness easily by simply taking a peek at the graph editor and deleting keyframes during the jump that were unnecessary (ones that followed a path they would have anyway, or ones whose motion I could recreate by editing the curves). Although I planned to dig more deeply into the graph editor for next week and merely plot out my keyframes for the blocking pass, I did also edit the curves so that the jumps look a little more realistic- when the feet leave the ground the line is linear, and while they are in the air, bending to an athletic point, they’ve got more time to adjust.

Day Three

I finished my keyframes on Day Three. Overall, I still felt very proud of them, but I was very aware of how jolty and floaty some of the jumps look, especially in the final twisting split. I wanted to wait to work on it, though, for academic feedback, so that I didn’t mess up my keyframes trying to work on a polish ahead of time.

I utilized the time at the end as I had originally intended: I was going to add in a closeup where we see the gymnast breathing heavily after the end of her rigorous routine, and a look of nervousness or excited anticipation on her face indicating her confidence in her performance and possible expectancy to be graded. I felt drawn to do a closeup by the realism of this rig; which I had never worked with before.

I am very interested in facial animation such as lip sync and expression, and I although it didn’t exactly fit into the parameters of this project, I wanted to find some way to experiment with it a little.

Day Four

After almost an entire day of playing with cameras, HDRI globes and frame rates, I was able to produce this. I have to admit that despite its flaws, I am beyond overjoyed with it, and if you were to tell me a month ago that this is my work I wouldn’t have believed you at all. I’m especially proud of the breathing at the end. It’s exactly what I had visualized and it came to me very easily. In my opinion, the expression, arm movement, heaving chest, and neck bending look natural and professional. Despite being a body mechanics project, that’s the part I would show off.

That being said, although I was happy with it, I couldn’t get past that joltiness during her twisting split at the end. I’d also come to notice how broken her wrist looks in that final pose. And so despite being just about ready to submit the project the night before, I decided to take one last crack at it in the final day to polish up that twist just a little bit, without letting myself go too far into the polishing end of things.

Day Five

And so I rendered one more time, keeping my eyes out for little things without necessarily committing myself to a polish. I fixed the broken wrist and I tried to simplify some of the joltiness in the twisting split. I did this by once again deleting keyframes that were unnecessary and editing the curves a little bit, as well as keeping an eye on where the knee controllers were at all times. I also spent some time making sure her chest, waist, and neck looked natural and comfortable between poses. I’ve put some work into the fingers and toes, but ultimately I plan to work on those as well as add in more breathing throughout during my polish pass.

…..And here it is. The jump looks better, which was my intention. Overall I think the quality is better. There are still some changes I’d like to make, but that’s what the polish pass is for, and I’m still very happy with my work.

Notes

When I watched the video detailing the corrections I must make, the audio did not work, but I was able to get the gist of it. My biggest issue with the first attempt was the reason for the “jolty” movement, and also was the cause of my major confusion pertaining to the root controls. I had been frustrated that there were several purple controls that were “tied” to the ground and could not figure out whether my entire animation was incorrect because of it. Turn out, I was right that the controls shouldn’t move, but I made a major mistake in assume that one of them should.

My biggest problem was that I animated the root control and moved individual parts of the spine to match, rather than animating all the forward motion directly from the motion control. This is what gave the knight a “stop motion-y” look and made it much harder on me than it needed to be. If you compare the original with the new version you’ll see that it’s a lot smoother and looks more effortless.

Another thing I focused on is overlap. I dug deeper into the graph editor and made sure that with all motion comes a secondary and tertiary motion, similar to the tailed ball exercise, and the Aang rig we discussed in class. The shoulder swings forward, then the elbow, then the wrist. The base of the spine, then the middle, then the top, then the neck.

I completed the motion of the feet and legs first, trying my hardest to make my work indistinguishable from Luke’s first two steps he gave me as an example. Although that’s an extremely lofty goal for me right now, I did okay. A big part of that was making sure that my steps were not too big, and that the forward motion of the body correlated realistically with the body language and a comfortable walking pace. I edited most of my steps to be smaller and smaller. In my original storyboard, I’d drawn quite large steps, in an effort to emphasize the walk style,

-but when translated to animation, these large steps looked like jolty lunges and seemed unrealistic and unbalanced. I finished the foot motion much more conservatively, and, looking back, I decided to go in and add a more cartoony heel and toe roll, to make the steps a little bit less robotic.

When I went about animating it the second time, I was able to complete my animation within two days, rather than the five it originally took me, not to mention the fact that it looks better. This was a source of immense pride for me. There were a couple little stylistic details I went back and added in at the end just because I liked them, though somewhat toned down, like the enthusiastically respectful flair when the knight bears his shield and brings his fist to his chest as he kneels in front of….. his offscreen commander.

I started by creating a storyboard for my stylized walk cycle, plus a little animation at the end.

Above is the video footage that I used to create the storyboard.

Making Friends with the Rig

After I’d gotten a good reference to use and created my storyboard, it was time to move on to the rig and getting used to the controls. The first thing I noticed was that in this particular rig, translation will move the mesh out of place, and I’m meant to rely on rotation instead. I was also grateful to find that the rig had a scale constraint, so that I couldn’t accidentally cause obvious errors by having pieces of the rig enlarge or shrink. Every good rig will have a scale constraint. Other examples would be a point constraint, which constrains translation (not something a rig would usually come with, but one that you could use yourself when animating), orient constraint (rotation) or an aim constraint, which ensures that the child points at the parent, often used for eyes.

 Another thing that I noticed regarding this rig was that when I use the waist control to bend the legs, the knight squats in a weird bow-legged way rather than straight down.

This is just something to be aware of when I use the controls further- I must always make sure that the knees are pointing in the correct direction.

It took me an unexpectedly long time to get the rig into the first pose. Many of the controls, I found out, actually move pieces of the armor and not the body itself. I spent some amount of time considering just accepting that this rig is beyond my skill level and choosing a different one in shame, but I’d already made the storyboard. After a bit of work, though, I got the hang of it and put my knight into his first pose:

Something else I hadn’t realized about this rig is that there is no way to adjust the toe roll that I can tell. There are controls marked toe roll but they affect the foot position. Perhaps this is because the armor is supposed to be very heavy and stiff, rather than leathery as I had drawn it in my storyboard. I also couldn’t seem to understand why many pieces of the rig appeared broken or disjointed like this:

In this gif, there is no key set on the wrist, but even if there was I can’t understand why it wouldn’t move with the elbow as the other arm does. I attempted to parent the joints and realized that it is the mesh that is not moving, while the skeleton itself has no problem:

I decided to employ my common tactic of starting over, on a hunch that I myself had broken something accidentally while struggling to figure out the rig. Controls were everywhere, things weren’t working, and I noticed I’d made some mistakes early on anyway. Sure enough, the controls worked fine. I try to keep my starting over to a minimum, but at least I was going back in with new knowledge and was no longer held back by my own mistakes.

Much to my frustration, though, I found that there was no way that I could see other than to let some of the controls get messy. This small- as I like to think of it- vertebrae, for example. It does not seem to move with the rest of the body and when I try to “put it back” it disrupts every frame. 

Starting over still had merit though, as I could make sure my knight was moving forward correctly. Maybe I’ll be a little more kind to myself and make it a much-less-polished pass. It’s not the time to worry about fingers, toes, fabric, and breathing yet.

Against all odds I finally made it through my first two steps (24 frames).

You can see that I’ve brought the confident, puffed-up march from my storyboard one step further in most of my keyframes, giving it more arrogance and bounce.

You can also see in this playblast the “messy” controls” I meant that have been frustrating me so much. There are two that stay put in one spot and can’t be moved without damaging the animation. As I said before, I believe that these are similar to the root control and are not supposed to be animated, as I can’t see any way to effectively do it, and they are labelled “Root Part 1” and “Root Part 2” (with 2 being a subset of 1) in the Outliner. I know that the sword and shield both have similar purple tangents that ensure the object continues to point in the same direction while the character around it moves. It is possible though that I am entirely mistaken. For one thing, the piece of spine is the most vexing to me. I can’t understand why the spine would need a stationary root like this, but when I open the rig up untouched, sure enough, that piece of spine does not move with the rest. Furthermore, when I try to move it, the action oddly can’t be undone, and seems more like some kind of pivot point. I have much less doubt in my assumption that the yellow controller at the starting point is also not meant to be animated, as when I experiment with it, it stretches the mesh unnaturally.

All I can find online regarding this subject is a thread on cgsociety.org that insinuates purple controllers mean they are hidden and I should make sure visibility is on; however, under the show tab in Maya, everything is selected.

This is one of those things that make learning something new somewhat embarrassing. I feel that I am correct in my assumption but at the same time wouldn’t be surprised in the least to learn there’s a simple answer I’ve overlooked.

I put my theory to the test in a simple way:

When I stretch every object far to the right, Root Part 1 and Root Part 2 stay put. Thus, I can conclude that this piece of spine will not prove to be an issue later down the road and that it is in fact not meant to be animated. 

End of First Full Day Animating

This is as far as I got by the end of the day- as you can see I incorporated one more little gesture in for even more stylization. I’d say that the biggest issue is the choppiness, but for the purposes of this project, splining isn’t necessary yet. That said, if I have time I would prefer to go back in and get that resolved. Although there are some clear issues that must be addressed, I feel that I’ve made incredible progress throughout the course of the day, considering when I first started with the rig I was unable to find many controls. I also am proud of my progress in contrast with the walker: this first day is leaps and bounds better than that whole first week.

Second Day Animation

This is my progress at the end of Day 2, just finishing up the rest of the base animation I had planned on my storyboard. I had a much shorter day today, only working on it for a few hours, just enough to get to the end. By no means does this mean I’m done, though. Not only is the animation quite choppy, but there’s significant toe dippage beneath the ground plane, and I haven’t yet animated the fabric or the fingers. This is about as unpolished as it gets. The longer I look at it, the more mistakes I see, but it doesn’t stress me out as much as it does just interest me in fixing it.

Plan: Complete the main animation → fix errors → polishes (fabric moving, fingers, etc).

Third Day: Fixes, Fixes, Fixes

Looking at my animation fresh, the first thing I did was move the chest forward a little in the walk that comes between the salute and the kneel- the knight’s back looked broken there. As I did so I realized that the leg actually moves through the shield during this segment.

(slowed down to show this better)

Sure enough on closer inspection the shield also passes through other objects (such as the hilt of the sword) during the animation. So the first thing I will do is fix any object phasing like that, and then after I will work on the toes dipping through the ground plane.

Object phasing fixes were relatively easy. Not wanting to make anything too messy, I simply allowed the left arm to come a little bit further out and sideways for the duration of the animation. As I was doing this, I noticed that the shield handle is loosely resting on the knight’s arm rather than him actively supporting it, so I rotated the wrist to always be slotted into the shield grip in a way that follows the laws of physics. While I was doing this, I decided to go ahead and key the finger positions for the left hand, which stay gripping the shield handle throughout.

This was followed by me staring intently at the hand in each frame to make sure the necessary wrist movement doesn’t upset this. It only became a problem at the end, when the pinky phased through the handle during the knight’s kneel to the floor, but I keyed a separate movement for the pinky to accommodate this. 

The next thing I wanted to fix would be harder. Due to the knee controllers being separate from the legs, I’d been frustrated by the knee armor pointing the wrong way.

When I mentioned before that the knight seems to squat oddly when the waist is moved down, it is a direct result of this; although the legs seem to move perfectly fine, the knee guards seem to be set to move side to side and only point forward when the legs are bent out in a bowlegged way.

You can see here that although the knees guards are facing the same direction as the foot, the leg is bent oddly out.

I tried simply rotating the mesh, but it caused this:

That’s when I realized it was even worse than I had thought.

After attempting to straighten the knee guard, the knee aim was all over the place. I deleted every key I had set early on trying to combat the issue and was left simply with a bowlegged walk. But when I place the aim straight in front of the knee, I get a nice, straight walk, and this is what I see:

As you see here, the leg and knee itself are completely fine, but it is the knee guard that is the issue. The problem is when I try to adjust the knee guard, the rest of the leg moves with it, throwing off the animation. Before jumping to the conclusion that the rig itself is broken, I popped open the untouched version of the rig once again to make sure that I myself hadn’t caused this issue.

This is what I’m attempting to communicate in this gif. I opened the software and the knee aim is set to the sides of the knees, but they face forward. I try- and confirm- my belief that the leg itself cannot be animated from the knee aim. When I move the foot up, the knee guard stays straight, with the aim moving to accommodate, but the thigh is in the wrong position. When I move the knee aim to get the thigh to face forwards, we lose the knee guard.

All I can think is that there must be something to move the thighs other than the knee aim that I’m unaware of, but I can’t find anything else.

In addition, I just find it weird anyway that the legs would be made to automatically bend outwards rather than straight down. I haven’t seen that on a rig before.

I believe I have exhausted my efforts on my knee controller analysis and all I can think is that either the rig is made incorrectly, or there is some setting or outliner asset I am meant to understand that is simply beyond my skill level. This and the rig not appearing to have a toe roll are both the biggest issues with this rig for me.

The next fix I tackled was the toes dipping through the ground plane- easy enough, I just watched the plane from below and moved the foot up on each keyframe it dipped, as well as took a look at the graph editor each time there was an issue on an in between.

After that I decided I wanted the nose to remain pointed snobbily skyward after the salute rather than straight ahead (my original intention was that he is looking towards the person he will kneel before), because I felt that straight ahead took a lot out of his puffed-up chest and made him instead look like he has scoliosis. I did also make it a little less extreme.

Next I added hip and shoulder movements for a little extra effect, the hips “carrying the leg” and the shoulders sloping down on each step left and right.

I’m feeling pretty good about obvious fixes and may be ready to polish, but first I just want to make sure the left leg isn’t snapping on the first step-

-and fixed.

Before I finished up for the day, I spent some time animating the fingers on the left hand. 

Although the changes may be small and unnoticeable to most, they are very important. Comparing this with yesterday’s, it’s satisfying not to see that toe dip. Here is my progress update for this day. Also- I came to the conclusion that my original was simply a bit too fast for the confident strut I’d created. That speed was more suited to a brisk running walk. So here I’ve slowed down the frame rate. I’m considering keeping it slowed down, but maybe not to this extent; I’ll find a middle ground. This slow frame rate does give me a really good opportunity to see some of my errors a little more clearly though, and now I’ve got a good idea what I want to go in and fix tomorrow. Specifically, the last down-pose looks a little bit too extreme, and the chest jiggles oddly immediately after the knight gets back up. Lots to do tomorrow!

Day Four: Fixes & Fabric

Here is a gif showing the changes I’ve made in regards to what was mentioned before. The easiest way for me to see these mistakes is by upping the frame rate and rendering with a tracking camera, but that takes too much time to do over and over again. 

Now that I’ve made these changes, it’s time to get down to the nitty gritty of the fabric animation, which I am less than comfortable with, so I’m not trying to get too fancy with it.

And here it is, my first attempt with the fabric on the right side of the body. Maybe I’m speaking from naivety, but I’m very happy with the results. I animated all three fabric controllers as one piece in order to keep things simple for myself, and simply had the fabric follow the motion of the hip, swinging back and forth. At the very end I had the bottom half of the fabric move outwards separately, so that instead of phasing through the floor it flows out as the body moves down and comes to rest folded around itself.

For the fabric hanging down from back, it was a bit easier. I acted it out with a cardigan tied around my waist and found that the fabric moves outward on contact poses and inward on passing poses. An easy way to think about it was simply just having the fabric follow the motion of the leg that is moving farthest back, but slower, as it is relying on gravity.

But I felt compelled to make it more complicated, just because I knew how for once. So I decided to go back and animate the bottom half of the fabric using the same principles as the tailed ball exercise (the bottom half following the top half, following the very bottom- the hem of the fabric- offset by a couple frames). I plunged into this task eagerly and this is the result:

I have to say I’m happy with it. 

The front piece was actually much, much harder than the back.

I’m not sure what it is about the front that makes it so incredibly difficult, but it has to do with the fact that it’s a shorter piece of fabric, which means that the movement is much more dramatic as there is less of itself weighing it down. I actually animated the entire thing twice and got rid of all my work, being unhappy with the results. I had an extremely challenging time even making sure that it does not phase through the legs. When the legs are raised, the cloth must be pointing almost straight up to avoid the thigh phasing through. After almost two hours, this is rough, first half of the animation is all I had to show:

You can see that my technique is making it very fluttery, like the back cloth, to make the dramatic movement a little less intense. Unfortunately it is extremely hard to get the cloth to animate correctly without phasing through the legs.

This is my work at the end of this full day animating fabric.

I have to say that while my work on this project has previously made me proud of my progress and excited to see what else I can do, my work today fills me with unhappiness. I know that the front cloth looks scrunched and wrong and that it would be the first thing anyone in the industry would notice, but just my work on the fabric today took over five hours and this is the best I could do. With one more day to work on mistakes before submitting, hopefully I can at least make it look somewhat decent in time. I’m beginning to doubt every aspect of my animation.

Final Product

And here’s the finished product.

I have to say that of all the projects I’ve done so far, this one I think is simultaneously the best and the one that disappoints me the most. This really took a lot out of me. I can’t stop staring at how jolty it still is, despite having spent so much time in the graph editor trying to even that out. I’m well aware of how bad the fabric looks, barely following the laws of physics. And the longer I look at it the more the legs seem to snap. 

I think now’s the time to be grateful for the progress that I did make. I started out on the first day spending hours just trying to figure out how to control the rig, whereas now I find it easy to jump in and change a keyframe without throwing anything off. Not only did I animate joints and fabric for the very first time on this rig, as well as animate a character holding a prop throughout, but I also am a lot more cognizant of objects phasing through others. It is difficult to see my own mistakes and not have the knowledge yet to fix them as I’d like, but, as always, Maya is a wide open door of possibilities I will simply have to discover in time.

I decided to use the iphone as a prop, constraining it to the ball. I floated it in front of the walker as though held by a Veggietales character, and angled the “head” down as if completely absorbed in the phone. This gave me the idea to add in a little bit of danger for emphasis that this character really is not paying attention at all to his surroundings.

However, everyone I showed it to either could not tell that he was supposed to be holding a phone or were unsure why he didn’t react to the car. To reinforce the idea I added on some headphones and had the phone emit a bright cyan glare. When I showed my partner this updated version he said, “I’m concerned about him”, which was the reaction I was going for. Now that I’d spent some time getting invested in my idea and constraining both props (the iphone and the headphones) it was time to get down to the nitty gritty and focus on smoothing out the small details.

Fix 1: The Toe Dip

The first and most obvious issue was what’s always been the bane of my existence with walk cycles: toes dipping below the ground plane on in-between frames.

As annoying as this is, I’ve found though that it is easily fixed by making the Translate-Y curve between the two points linear:

Sometimes, but rarely, I must go in and adjust the splining to be a little bit faster or slower in relation to the two key frames. Keeping a close eye on the toes, frame by frame, is a meticulous task, but only until those were done could I begin thinking about polishing further.

Fix 2: The Electric Slide

The next thing I wanted to get fixed is the sliding problem:

The walker appears to slide on this step as if on ice.

This is what the Z-Translate curves look like at this point (frames 70-85). I ended up fixing it by dialing down the translation on the offending foot at the passing pose by a lot- from 1 to about 0.2. The result looks like this:

I then went back and did the same to all “passing” poses.

Fix Three: Bend and Snap

Last but not least, I wanted to make sure that the leg movements look smooth and natural, and polish out any twig-like snapping that might be happening. If this happens, it simply means that the knee is going from a bend to a straight position too quickly, and so the answer to this is lowering the heel, easing out the keyframes to be a little less exaggerated, or bending the knee a little bit more.

While I did this I actually went back and decided to slow down the whole second half of the animation while I was at it, because the walker had been traveling noticeably farther/faster towards the end. 

The Ultimate Fix: Enlightenment

I went to go move my laundry and found myself paying attention to my walk. Then it occurred to me why I was seeing some of that backwards-foot-sliding motion: once the foot is planted, it stays in that spot, and the rest of the body moves forward around it until it is lifted up. I feel that when I had done my walk cycle originally I’d been stuck in that habit of thinking of it as key poses without understanding how or why the walker must move in that way. I had originally made the mistake of animating the root control, and when I fixed that I still didn’t understand the problem- I had animated the entire walker to move forward at every single keyframe, rather than relying on the forward motion of the leg to carry the rest. That’s why the walker still looked a bit slide-y no matter what I did.

And so I sat down and eagerly redid every single keyframe. This time I studied the channel box editor and keyed the foot control to stay at the same Translate-Z location for the entire time it is on the ground until it lifts up, and I just animated the body and the other foot around that. Here is my graph editor showing the feet staying put throughout the duration that they make contact with the floor:

I found this actually resolved a lot of things- speed, for instance, as the walker is only able to move forward as much as the last step will allow, if that makes sense. 

Finishing Touches

Despite reaching this breakthrough that solved most of the surface issues and perhaps fixed the actual mistakes, I still feel that my walk cycle needs work. Most of what’s disappointing me about it is that it feels very stop-motion-y or robotic looking, and I think this is because I made the rotation of the ball/head too predictable and repetitive. Mostly, I felt that the X-Rotation I applied to give the ball a “bobbing its head to the music” feel was not working and instead hurting the realism of my animation. Keeping in mind that “every piece of the animation should always be unique”, I got back to work on the ball.

I think that it may now be just about perfect. I’ve smoothed out the leg animation, added in a couple “head” rotations, and tied it together with the secondary action of the headphones being blown slightly forward by the momentum of the car, still unbeknownst to the walker.

And here’s the render:

My biggest issue with my original walk cycle was that I had animated the root control rather than having the feet themselves move forwards. I started over, and this is the product.

(original below)

1. Getting Comfortable with the Tail- Day One

 When I started out, I had a bit of trouble getting used to the tail. This was because I was thinking of it as I would a walk cycle; pose-1, pose-2, pose-3, trying to key each shape the tail should make at specific points.

I actually spent a couple hours unsatisfied with my work until I reconsidered my method. It became a lot easier after I began thinking of the tail as a series of arrows, where each arrow points the direction that the one before it did last, with the movement originating from the base. I also reviewed my notes from the lecture and found it useful to remind myself that the tail must “point toward where it came from”.

In this sense there is no specific pose the tail must be in: the most realistic way to use it is to think about the way gravity would affect the base and animate the rest of the tail in turn. I would change the position of the base, then go down the chain and move each segment of the tail a couple frames after one another.

Knowing this, I was able to think of other ways to use the tail, i.e. for balance and emotion.

I also chose to add some sinking-log animation, not only for weight but for secondary action, in order to make the scene a bit more interesting and believable. I also found it fun to have the beaver balance a little bit with his tail as the logs bobbed up and down in response to his weight. I chose the beaver rig after deciding to incorporate the sinking logs, because I felt that tons of fallen trees were a bit too sad if you don’t have the hope that maybe a beaver did it to build himself a home.

After my first couple bounces, it was time to find out whether my motion trail was smooth, and whether it shows overlap of each tail segment.

Well….. There’s overlap for sure, but it’s not exactly smooth. Time to fix that. A quick smoothing out, and it already looked much better:

The biggest difference I notice after the tail arc smoothing is that looks much more natural when the beaver lands on the first log. Satisfied with my work and feeling much more comfortable with my tail abilities, I decide it’s time to move on.

2. Floatation Frustration- Day One

I’ll now be discussing my process with this clip, in which the beaver turns and jumps far out of the river onto a larger log:

Surprisingly, it wasn’t the tail this time that caused me the most trouble. It was something I thought I’d gotten the hang of during the ball bounce exercise: an unrealistic trajectory. In my defense, however, the difference between the ball and the tailed rig is that this character is assumed to have some sort of muscular system he is using to propel himself, rather than using simply momentum and gravity to dictate the height and speed of his jumps.

Here is the odd “floating leap” I was having trouble with. I was animating the ball movement before adding in the tail motion when I came across this problem:

As you can see, the beaver sort of sails through the air without much realism, completely shattering the work I’d put into his weight. Cautious about what I’d find, I cracked open the graph editor to take a look under the hood:

I edited the Y-curve to be linear at the points of impact, and sped it up more at liftoff and touchdown, but it only helped marginally without really resolving the issue:

Hesitantly, I tried the X-curve:

As I’m sure you can predict (as I should’ve) that this did not solve my problem. What it did is cause the beaver to swerve around in a little detour rather than taking a diagonal path.

In the end it occured to me that I had included extreme squash on both impacts and no stretch. I tried it and sure enough, that did the trick. The long leap now looked believable, albeit cartoonish:

Oh, well. Goes to show not to forget about the simple details. I thought it fair to mention this simply because I had spent so much time trying to figure it out.

3. End of Day One- the Little Hops

With my brain sizzling on the griddle I finished the last little bit of animation I had planned to reach my stopping point for the day. 

The Little Hops.

The little hops were a nice easy way to phase out the day. All I had to do was make sure to keep those impact points linear.

I started work on the tail, but my brain had become scrambled eggs. I shelved the little hops to continue tomorrow with a fresh pair of eyes, looking forward to adding a jump up onto a tree limb for my sixth and final bounce. Here is the finished work for Day One, a little more than halfway done:

For the next day, I planned to finish my work on the action after landing on the log, as well as polishing up speed.

4. Turn Around, Bright Eyes- Day Two

I got back to work on the little hops with new determination. The tail animation gave me no trouble at all, and I had a lot of fun with it. However I was finding a lot of trouble with the slow rotation at the beginning, in which the beaver pauses after landing before turning to jump towards the end of the log. Reminiscent of the floating leap I had dealt with earlier, I found that the turn looked extremely mechanical, despite having added some lifelike motion to the hops afterward.

Tail good, turn mechanical.

Motion curve of the little hops tail animation.

And so I tried experimenting with the turn, trying to find a less animatronic looking solution. There was to be a turn right after this too, as the beaver turns again to look at the tree branch, his next target. If I could find a way to resolve the first turn I could find a way to resolve the second and vice versa.

Ultimately, this was my decision to add some life to the turn:

I tried for a while to simply have the tail wave in the opposite direction of the turn, but the turn is too slow; it didn’t look realistic. And so I added two elements to make this turn a little more realistic. 

1. Little details-when the beaver lands, the tip of the tail bobs up and down briefly. I did this to add some information about the weight of the tail, as well as give an idea that the jump required some exertion and the beaver is now pausing to relax his muscles and take a breath- which I also attempted to convey by slightly squashing the ball at the same time as the tail bobs back down, which is as much as this little thing can “breathe”.

2. And more noticeably, I decided instead of having the tail follow an arc, relying only on gravity, I’d instead give it a bit of musculature. I decided to have the tail sort of help propel the beaver upwards into his jump (which the “breath” earlier can also be preparation for). Although the tail does not smack the log, I gave it some wind-up action for anticipation effect; to help the beaver get ready to make his jump and put some force into it. When I was considering doing this I thought I remembered seeing a Disney film in which a beaver walks on his tail and took a brief detour down the rabbit hole, but I could only find this from Lady and the Tramp:

….My beaver propeller is somewhat of an in-between as far as this cartoonish exaggeration and the less flexible tails that real beavers do use during their work day.

This bit of animation looks a lot better now, and I believe I’ve solved the “mechanical” issue:

Yay!

V. Day Three

The home stretch was just a clip in which the beaver jumps from the log to its landing place on a tree branch. For all intents and purposes I must state that beavers can’t climb trees in real life.

The first part of this segment wasn’t too hard, just a simple long leap which gave me time to show off the classic tail animation that had now become second nature.

The second half of it was a little bit harder, I had my heart set on having the beaver do a couple little happy, short jumps to signify its excitement at having reached its destination despite its expressionless face. The difficulty with this was that I had to have the tail wave up and down twice within two very short, 10 frame movements, without coming to a rest.

After a little bit of adjusting, though, I realized that it wasn’t as hard as it seemed at first if I just ignore what the ball is doing and return my focus to the “arrow system” I described earlier- keying the tail segments to point where the last one was pointing earlier. 

In the course of the two hops, the end of the tail undergoes a lot more movement than the first two tail segments do, in keeping with its relative lightness that I’ve given it throughout my animation.

I went through and fixed a couple things- most importantly, I decided that my propeller tail looks odd pointing outward off the log, and should be pointing straight out behind the beaver. Not only does this look better, but it makes more sense with the laws of physics too, as a sidelong “propellor” would either unbalance the beaver or him off course of the log. I also tidied up the speed somewhat throughout the animation. After staring at the animation for hours upon hours, I decided it was done.

Finally, here’s the finished product:

Blocked animation, or stepped animation, is often used in computer animation specifically to give the animator a sense of time without the distraction of the software’s automatic interpolation. Using blocking, we can make changes quickly and correct any mistakes before things get too complicated.

1. Previs

As discussed in class, I started off with previsualization, blocking out the stages of animation- the walker moves across the Z axis by -13 over the course of the animation. If the walker finishes moving forward at frame 96 before turning around, I’ve given it time to complete four full cycles, or eight steps.

12 frames after it reaches its destination, it spins around and returns to its starting point. Upon finishing a simple previsualization, I was ready to begin blocking in my key poses. But, of course, I’m not experienced enough yet to just jump into a walk cycle without studying any sort of references.

II. References

As usual, I consulted my own copy of The Animator’s Survival Kit, the incredibly helpful work of Richard Williams, who won two Academy Awards for his work in Who Framed Roger Rabbit. The walk cycle he uses is both simple and accurate:

I did go back and find the resource that was shown in class, as well, by John McMurrough.

I also saved these useful notes that I found on the website of Andrew Banta, an animator and alumni of Purdue University, who studied this same exercise back in 2010.

In regards to our discussion of good vs bad references, the Banta one is good, most importantly because it utilizes a 12-frame cycle, labelled accurately (not to mention depicting the same rig that I’m using), but the McMurrough one is best because it’s got a better description of all the animation that needs to happen and the little notes section at the bottom is extraordinarily helpful.

III. Key Poses

Using primarily McMurrough’s chart as a reference, I whipped up these key poses for the first contact, with stepped curves.

I then watched the animation and made some changes on frame 12. After doing so, I continued onto the second half of the cycle:

Here’s the complete cycle. 

Looks good to me! Now to repeat the process three more times, for a total of four cycles and 8 steps….

IV. Three Cycles Later

And there you have it, frames 1-96, with simple pose blocking. The walker does not move forward in this blocked animation, because all of the animation is stepped; therefore, the walker simply appears at its destination at 96 rather than slowly making its way there. However, I did afterwards adjust the Y-Translation to be linear just to see if the walk cycle still makes sense; i.e. if it is too fast or too slow, etc. Below is the version with a linear Y-Translation.

I did not incorporate the turn around or walk back as we only discussed an 8-step cycle in class and may delve into further instruction before starting the journey back. That being said, I’m excited to see my walk cycle finalized!

1. Creation of the Ball Maze

I began first with creating the maze, envisioning the animation I wanted and the way each material would interact with the ball. I realized quickly that I should create a storyboard and drew one out, breaking the animation into four segments.

Storyboard

While sketching my storyboard, I traced over a PNG of my maze setup to give myself an accurate sense of spacing. As I did so I became aware that some objects needed to move down or up, etc, in order for my intended animation to work. So, after completing my storyboard, I went back into Maya and finished creating the scene, re-spacing, and tweaking color and translucency on both the funnel and “trampoline” to allow my animation within the objects to be displayed. I also added a material to the ball once again to view my rotation more easily. 

Ball Maze Setup

Time to get rolling!

2. First Segment- Day One

Animation 1 was the easiest, as I was expecting. It helped me feel out the space I’d created and the physical characteristics of my little basketball. In this first segment, the ball simply slides down the ramp and whams into the wall on the right. 

I spent some time adding a very small squash/stretch bounce as it reaches the bottom of the ramp, giving it a little momentum from its downhill roll.

The curve I spent the most time on was definitely the Translate-Y curve, as I debated back and forth how noticeable I wanted that little bounce to be. A longstanding goal of mine is to be better at animating from the graph editor and having to rely less on key frames.

As the ball smacks into the wall, you can see that I’ve added a small pause there for the full effect of this exaggerated squash. The next segment will be almost entirely squashes as the ball ricochets off the lower level walls, and this pause creates anticipation.

3. Second Segment- Day One

This one would be more complicated, and I knew it would require a lot of patience and attention to detail in regards to my squash and stretch as well as timing.

Before anything else, I keyed the Y-Translations, using my storyboard as a guide.

Much timing as well as squashing work will go into this, not to mention the exaggerated stretch of my “trampoline” that will be added in to anticipate launching the ball out in segment 3. Most importantly, though, I needed to make sure that the actual points of contact look convincing and accurately represent the laws of physics- the worst scenario would be to do all that work on each “pose” and then realize the trajectory looks off.

The biggest difficulty I faced when I got started was attempting to make the impacts look realistic. I started off like this, which looked completely incorrect:

But realized quickly after taking a second to think analytically that both impacts must be linear at their peaks. I rewatched the lecture from the ball bounce exercise- we made those points along the ground linear because due to gravity/momentum the ball must come right down and right back up- otherwise it will appear that the ball is floating or being pulled along. The part of the curve that can be changed can only be during the ball’s trajectory. 

I changed both curves to linear, but the effect confused me….

Despite my changes, the ball still appeared to be sailing along in the air, and barely hitting the “ceiling” at all. Experimentally, I attempted to replicate the curve I had on the first bounce (from the wall to the floor), as that one looked more realistic:

This time, the ball certainly popped up noticeably, but it was clipping through the ceiling and pausing oddly. 

Once again I sat and thought for a long while, breaking down the issue rather than just putting a lot of work into random guesses. I came to the conclusion that the entire arc of this bounce must be linear, and in fact it has to happen a lot sooner. The ball moves almost straight upwards, with great momentum from its fall, and travels a much shorter distance than it did on the first bounce. Therefore it must happen a lot faster, with no time for a lazy, bouncy trajectory. Both the second impact and its journey into the “trampoline” are affected by this and must be mostly linear to convey the ball’s weight and the speed it has gathered.

I moved the keyframes up and adjusted the graph accordingly.

Voila, the completion of Segment 2. I allowed the ball to slow a little at the point where it is caught by the trampoline.

4. Third Segment- Day One

I had intended to leave Segment 3 for another day, as I knew how exhausting Segment 2 would be (it was), but I was so excited to do this short and exaggerated, cartoonish little clip that I decided to plunge into it for fun.

This segment is my favorite part of the ball maze. In this clip, I’m using the secondary action of the “trampoline” to give an emphasis to my basketball’s weight and momentum. I also get to use some overlapping action here as the trampoline snaps back into its original position after the ball has already left its net, not only reminding us of the ball’s weight but giving an idea of the material and weight of the trampoline, too.

V.  Final Segment/Finishing Touches- Day Two

This segment proved to be more challenging but not overly so.

Continuing my personal challenge to use as little key frames as possible and animate from the graph editor, I discovered that I could key only the back-and-forth translation and simply exaggerate the slope in between, in order to cause the ball to appear to be travelling around the curves of the funnel rather than across it. I felt very triumphant in this discovery.

However, as I excitedly showed this to my partner, he pointed out that due to the ball’s momentum, it would not immediately begin spiraling and instead would smack back and forth on the first couple bounces before beginning the spiral. I watched it many times and decided he was right. I sadly deleted my first arc on the graph editor to create this more realistic animation:

And so I decided I was done. I had a lot of fun with this little project, challenged myself, and came out a better animator for it!

Final Product:

Getting the Ball Rolling

I created the beginning of my ball bounce animation while following along in class, and so when I began to work on my own, I’d already added a translation along the X-axis and Y-axis as discussed (Y-translation 10 at frame 1, 0 at frame 12, 8 at frame 24, 0 at 34, 6 and 44, 0 at 52, and so on and so forth diminishing its height by 2 each bounce and each bounce decreasing in time by 2 frames on each arc).

I was, however, a bit lost on how to adjust my Translate-Y curve in the graph editor, as I seemed to have the wrong tools selected. I went back and reviewed the tutorials and managed to get it figured out.

I edited my translation curve in the graph editor so that it looked like this:

I also added in a couple frames after translation along the Y-axis hit zero, to allow for the ball to slowly stop rolling along the ground (I later changed this from 99 to 108 as it would allow me to work in a less messy 24-frame-divisible format). Happy with the timing of my ball bounce, I decided to move on to the final touches- rotation and squash and stretch.

I. The Squash and Stretch Struggle

Spoiler: I was severely mistaken in thinking of these as “final touches”, as the squash and stretch caused me the most frustration of all and ended up taking many hours.

I easily added the rotation first, keying rotation along the X-axis to 0 and ending it on -900 at frame 108 (a little over 2 and a half complete rolls). However, I quickly realized that by adding rotation first, I made it difficult to add my squash and stretch in afterwards, as my scale tool arrows pointed in different directions each time the ball hit the ground and I would have to go in and messily adjust each keyframe accordingly. So I deleted my rotation curve in the graph editor  and set to work creating the squash and stretch first. I worked for quite a while on it, adjusting it to my liking. When I was finished with my squash and stretch, however, I found it ended up messy anyway…..

I stared at this graph for a while, replaying the animation, before cautiously deciding that I liked the scale anyway and it was safe to move on. All I had to do now was add in my rotation. I keyed 1 for 0 again and 108 for -900. Immediately, problems arose. The ball rolled extremely quickly but only after it had finished bouncing.

I took a look at my graph editor.

It confirmed what I was seeing. It didn’t take me long to realize the cause, though- I have recently gotten into the habit of selecting “key all keyable” on every frame I work on each time I input a new number as a kind of “bookmark”. This prevents me from messing everything up by forgetting to key the movement of one tiny thumb joint- or, God forbid, an entire limb- and having to search endlessly to find which frame this was forgotten on. In theory this works, but I used this practice poorly by keying everything before adding some of the main components of my animation in.

In frame 80, I have Rotate Z set to 0 because everything is keyed. Thus until frame 80 the ball cannot turn.

I went into my graph editor under the Rotate Z curve and began deleting all keyframes except for the first and last. 

So that it looked like this:

Problem solved. Easy peasy. Or so I thought…..

I triumphantly pressed play and the ball rolled along the ground, but unfortunately, I ran into the same exact problem I had anticipated originally. As the ball rolled, my squash and stretch adjustments gave the ball the dreaded football shape and it clipped through the plane/“floor”. 

Football shape.

Football.

Infuriating. 

II. Troubleshooting the Issue

After a brief rage quit I realized part of the reason that it was so hard for me to accurately squash the ball while it was rotating.

I had been working the entire time with my scale pivot point in the middle of the ball. The pivot point needs to be on the top of the ball for a good squash. This is also the reason my original squash and stretch animation was so messy. I moved the pivot point to the top of the ball.

I deleted my entire squash and stretch animation (Scale-X curve) and decided to jump back in. But unfortunately, changing the pivot point also affected the rest of the animation I had already done, and (I believed) there was no way to create my squash and stretch to the best of my ability without changing the pivot point……and so, I ~started over completely~.

Not really so bad, actually- I got the X and Y translation down again in no time as well as adjusting the curve, and it was good practice. Right off the bat I made sure my pivot point wasn’t in the center of the ball. I actually chose the bottom, as it would be easier to ensure that the ball does not clip through the “floor”. This time I also made sure not to let myself automatically select “key all keyable”.

I also edited the X-translation curve so that the ball appears to slow down its rolling towards the end before coming to a stop:

….and came to the conclusion that this was a more effective way to give the appearance of the ball slowing rather than editing the rate at which it rotates, which I kept linear.

But as I got back into the squash and stretch, I realized that it doesn’t matter the order in which I’ve created my animations, the pivot point must stay in the same place throughout the animation or parts of the animation will be damaged. My “revelation” that the pivot point was the source of my problems was either not true or not relevant. I would have to either find a way to rotate the ball without moving the pivot point to the center or I could find a way to create a realistic squash and stretch with the pivot point in the center. I chose the latter, seeing no way to accomplish it the other way around (if the ball were to rotate around a pivot point on its exterior, it would cause unintentional translation along the Y-axis).

III. My Solution

The part of my squash and stretch that was giving me trouble in conjunction with my rotation was the ball clipping through the floor/stretching oddly when it hit, so I decided what I need to do in order to “squash” the ball to the “floor” realistically was make sure the pivot point is always at zero- aka not rotated- when the ball is in contact with the floor. So I went about my rotation differently.

I keyed the Rotate-Z channel to either 360 or -360 for each frame where the ball is on the floor. This way the pivot point stays at its original position, and the ball automatically completes a full rotation during each arc. As the ball slowed down towards its stop, I set the last cycle to go only from 360 to 180, and as the ball rolled to a rest I keyed the last frame for 210.

I intended to assign a simple pattern to the ball so that I could get a good idea of how realistic my rotation looked, but unfortunately, Maya crashed every single time I opened the attribute editor regardless of whether I chose phong, blinn, or lambert.

Disaster.

But, I managed to think of an alternative:

I was able to view the rotation via the direction the pivot was pointing, and this allowed me to learn a lot more about what needed to happen. I went back and alternated the frames between 0, -90, 180, 90, and 0 instead of having the ball complete full cycles between each arc.

It was still hard to see whether this was better without the attribute editor, but when I went to add squash & stretch, I did not encounter the football shape glitching through the floor. I carefully added my scaling following the classic format, as seen in this chart by Richard Roberts:

….applying this to Maya, I set all scale keys to 1 for each peak of the ball’s arc, and “stretched” the ball on each frame before and after the impact, “squashing” it on each frame impact.

Happy with my work, but noticing that the effect became a bit too intense towards the slow-down end of the animation, it was off to the graph editor, where I edited my scale charts, making sure the peaks declined over time.

IV. Final Edits and Peer Help

Thanks to the help of my peers (specifically, Crystal), I was able to get my attribute editor up and running and, as I expected, found that my rotation could use a little work. This is what my project looked like:

As you can see, the rotation clearly reverses briefly on the last half of the second arc and flips again at the end. I suspect this problem was created when I messed around with the curves in the graph editor.

Turns out I was right the first time about the rotation. Rather than completing cycles between 0 to 360 on each arc, the curve on the graph editor should look somewhat like a straight line,

(although those keyframes are necessary as the ball losing momentum + the pause at the top of each arc means that the rotation can’t be linear). Numerically the rotation values are decreasing by 90 at the peak and bottom of each arc, with the first frame being 1, the 12th being -90, the 24th being -180, and so on until -990. I’ve had the ball finish at -1130 as it slowly comes to stop.

The final product looks like this: