Thursday, November 29, 2007

Cubies: Week 7 - Scene 2 Complete

Hello, it's been a week since I last posted,
and what I've done since then is finish the second scene.

Here is the final playblast (this time the controls are hidden so it looks a lot more like the final result):



The work was done in three phases:
1. First I took care of the minor adjustments to the rig. That took a little less than a day of work to complete. Most of the work was repositioning the cubies in order for their position with the new rig will match the position of the cubies with the old rig in the first scene...

2. Planning the timing - this time I was a little more confident and didn't use the spreadsheet - I just put the major keyframes (every step, jump, etc) as guidelines for the animation.

3. Filling in the animation, step by step. Along the way I added a lot of pauses that were missing from the timing. Without pauses the action looks mechanic and the characters don't look like they are thinking.
The pauses were the hardest thing to animate in this scene, since a walk is a walk (plus, I've animated like 50 steps with this rig already and it gets easier and easier), and I also got used to the timing of the jumps, but staying still while looking alive is quite difficult.
If you move too little, the character looks frozen and not alive, and if you move too much during a pose, it looks like it is working mechanically without thinking, or just looks unnatural.

Thursday, November 22, 2007

Starting Scene 2

In the second scene, the young Cubie is going to wake up the older Cubie, which is going to start walking slowly and steadily while the young one runs around him and jumps on his back.

They will start walking to the right side of the screen, and then we will switch to scene 3 in which the last Cubie will wake up, this time by itself.

But first, there are some things I want to fix in my rig.
As a lesson from animating the first scene, I discovered the following facts about my rig:
  • The knees and shoulders controls where indeed useful when growing the arms, but after that they just stayed static in the scene and just got in the way. Another problem was that the axes of the feet controls where rotated so the height of one foot was controlled by +X (instead of Y axes), while the other foot was controlled by -X (the opposite direction). I am going to try a different approach this time - maybe just using FK for the few frames in which the arm rotates from horizontal position to face the floor.

  • A roll attribute was missing from my reverse foot lock mechanism - for every step I had to animate both the heel control joint and the fingers control joint. I'm going to add a roll attribute to the foot control so I can rotate the foot in both directions using an expression.

  • The pole vector of the ankles IK should be constrained to another control, otherwise it's very difficult to animate. I didn't animate the pole vectors at all for that reason, simply because it wasn't accessible. I don't know whether I could use the pole vectors to make the animation better on this scene but I'm sure it will help in the following scenes.

  • One of the small details that bugged me was that the foot controls were underground most of the time - meaning hidden by the floor. I was still able to select them since I knew where they were, but I think I will raise them to be a little above the foot for better control.


So off I go to fix the rig, and continue working faster and better on the next scene :)

Wednesday, November 21, 2007

Another Playblast

This time, a playblast of the whole first scene, which is 29 seconds long.

The next section of the movie will be done in a different scene file and combined later.

Saturday, November 17, 2007

First Render!

Here are the first 14 seconds of the movie, this time fully rendered.
Enjoy :)

Thursday, November 15, 2007

First Playblast!

To all of you who asked where is the actual animation...

Here is a playblast of the first few seconds I completely animated.
These are seconds 8 - 14 of the movie.

A playblast is not a real render, just a movie that shows exactly what you see in Maya when you work on it.

Maybe later I'll fully render this.

Sunday, November 11, 2007

First Scene Timing

The whole short is going to be "one shot", so there aren't really different scenes.
I want to divide the movie into scenes logically by the actions in each scene.

The first scene starts with 3 inanimate cubes in the frame.
After a few seconds rest, the small cube starts to jiggle, then rests again for a few seconds, and then jiggle again and grow hands. After that he wakes up, starting to feel the ground around him, and then gets up on his feet.
In the last part of the scene the young cubie starts walking around, first slowly and after a few steps more cheerfully, circling the bigger cube.
The scene ends after the young cubie has circled the bigger cube and is curious about it. In the next scene he will wake him up.

I created a Google Spreadsheet that summarize the planned timing of my first scene.
I'm trying to "act it out", as much as you can act out something like a jiggling box.

First Scene Timing

Cubies: Week 4

This is what I was working on the past week:
  • A few more fixes to my rig. The rig is now finally complete, I think, and I've done some testing on it by animating the first few keys and it worked very well so far.

  • Fooling around with photoshop for a bit, I created a Rabiffe / Girabbit for a CG forum challenge. That took some time away from animating :)

  • I created a character set in Maya that contains all the different aspects of my rig - IK controls, rotation controls, joints, lattice and blend shape. I think the main benefit of a character set is when using clips in the trax editor, which I do not plan to use currently, but I'm sure it will be useful along the way.

  • I referenced the rig file from my animation file - the animation file contains 3 characters which are all referenced to the rig. Once I change the rig file all 3 characters will be affected. For example, I created the character sets after referencing the file, and 3 new character sets were added to my animation scene.

  • Finally, I got down to putting some animation keys into the scene. I thought I would start out by keying the key poses and extremes - but as I worked I kept animating small bits, missing the whole picture.
    This of course yielded some very crappy animation :)

    I think the main problem I have now is timing - everything moves too fast, but some of it moves a little too fast and other stuff move way too fast. So I decided to look for some references...

  • I've been reading Richard Williams' "The Animator's Survival Kit". I'm in about the middle of it, and it's a very good book.
    Unfortunately, it does not answer the basic question of "how many seconds does it take for a lifeless cube to grow hands and go live". Oh well :)
All in all, I think this was a rather good week, and I'm looking forward to struggling with the keyframes all over again once I finish the book.

Wednesday, November 7, 2007

Fooling Around With Photoshop

I've been a bad boy... This is what I did today instead of working on Maya - the Rabiffe!



It's for a forum challenge in cgtalk.co.il.
Those are the references I used:



Tuesday, November 6, 2007

More Rigging Issues

Yesterday I discovered some more problems with my rig.
I finished fixing all of them for now - until next time...

Problem 1:
  • Symptom 1: When the arms are retracted all the way using the blend shape the cube wall is not as it is in the blend shape - it has some ugly bumps. Also when blending half way the arm does not look like it should. Moreover, each arm looks different...

  • Symptom 2: After much research, it turns out the cause of symptom 1 is that the skeleton was not in the bind pose.

  • Symptom 3: When using ikBlend = 1, even though the IK didn't move, the skeleton is no longer in it's bind pose.

  • Cause: The problem was that one of the IK was probably attached to the skeleton when it had rotation values different than 0 (the bind pose).

  • Solution: Delete the bad IK. Rotate the joint back to the bind pose. Create the IK again. Attach the control's ikBlend to the new IK's ikBlend attribute.

Problem 2:
  • Symptom: In the other arm, the IK was ok but when the rotation of all joint was 0 the geometry did not look the same as in the bind pose. When the skeleton was back in the bind pose one joint had non-zero rotations.

  • Cause: After moving the joints, the "Reattach Selected Joints" command was executed when the joint was rotated. This caused the skeleton to look right when the joint is rotated, and deform when the joint rotation is 0.

  • Solution: Detach the bad joint from the skin using "Detach Selected Joints" when it is in the bind pose (not in zero rotation). Rotate the joint back to zero. Reattach the bad joint using "Reattach Selected Joints".

Problem 3:
  • Symptom: The lattice works correct only when the object is in (0,0,0) location. When the skeleton is moved up by the main control or the group, the lattice works as if the lattice shape was never moved from the origin (even though the shape is moving with the object).

  • Cause: I think the problem is that the lattice was attached to the geometry before the skeleton was binded.

  • Solution: When it happened before I deleted the lattice and created it again. Then it was created after binding the skin and it worked correctly. Then I used a method I was told about in the CG forums:
    Right click on the geometry -> Inputs -> All Inputs...
    This opens a window called "List History" which shows all the inputs of the object, much like in the attributes window, except in this window you can move the transformations position in the list, for example grab the lattice (the input is called ffd1) and move it up the hierarchy and above the skeleton, as seen in the image below.



Now the skeleton, the blend shape and the lattice all work fine and affect the geometry together. I checked and double checked.

Anyway, the lesson is you should always test, test and test again everything about the rig before moving on, to catch these problems early.
In my previous line of work we would call it "QA" :)

Monday, November 5, 2007

Cubies: Week 3

The last week was not very productive - a lot of research with not much real work done.

It took me a week to complete these couple of tasks which I thought would take two days:
  • Adding a reverse foot lock to the skeleton for better controls of the legs.

  • Finding a solution for the IK/FK blending. I hope the solution I chose will be good enough for my needs.


This week I'm going to continue working on a detailed storyboard.

Sunday, November 4, 2007

IK/FK Blending Methods

This last week I worked a lot on IK/FK blending.

Most of the week was pure research, and I didn't find a method that I really liked for doing it. Those are the methods that I considered so far:

1. The Maya built-in IK blending:
When you create an IK handle in Maya, it has an attribute called "IK Blend". This attribute goes from 0 to 1. When it is 1, the joint that is affected by the IK will be in the exact position of the IK handle. When it is 0, the IK handle is ignored and the joints can be rotated normally as if there wasn't an IK.
When the IK blend attribute is 0.5, the joint position is affected by both the rotation of the joints and the IK handle, and it will be somewhere in the middle.

Pros:
* This method is very easy to setup - all you need is an IK handle attached to your skeleton.
* You can key the joint rotation when the IK is active (IK blend = 1) and then your FK will "snap" to your IK.

Cons:
* When the IK is active, it's hard to see where exactly the joints will be positioned if the IK wasn't active (there is a mark "FK" which is only visible when choosing the IK).
* When the IK is not active, you can see the position of the IK itself but you cannot see the position of the joints on the way (for example the knee joint). This means you have much less control of where your joints would be whenever you animate the transition between IK and FK.
* When switching from IK to FK the skeleton will "jump" from one position to another. The IK is not attached to the FK and the FK is not attached to the IK. A smooth transition between IK to FK or the other way around will require a lot of keyframes on a lot of attributes, including the rotation of the joints, the position of the IK, and the IK blend attribute itself.


2. The 3 arms setup:
As far as I know, this setup is the most common setup for IK/FK blending.
It requires 3 arms: One is the "real" arm, one is the "IK" arm, and one is the "FK" arm. After you create these 3 arms, the IK is always active on the IK arm and there is no IK at all on the FK arm.
Your wrist control can then control only the IK arm and your elbow and shoulder controls can control only the FK arm. The real arm is positioned based on an attribute similar to the built in IK blend, which is now a blend between the two other arms.

Pros:
* This setup gives you absolute control of both your FK skeleton and your IK skeleton, even while you are animating the other skeleton.
* Snapping the IK to the FK or the other way around in order to switch IK to FK in one frame (instead of blending it over a few frames) is easier.

Cons:
* This setup is quite complicated, and if you want your controls to follow the real arm (while controlling the IK/FK arms), it gets even more complicated.
* The real skeleton will still "jump" when moving from IK to FK or the other way around. The large amount of keyframes is still necessary to combine IK and FK animation smoothly.


3. Constraining the IK:
I tried combining the first method with point and orient constraints on the controls. When IK blend = 1, the orientation of the controls is constrained to the orientation of the joints that is calculated from the IK. When IK blend = 0, the position of the IK control is constrained to the position of the skeleton.

Pros:
* Blending from IK to FK can be done instantly (on a single keyframe) since there is no "jump" - the IK control and the skeleton are always located in the same position.
* Less keyframes are necessary when going from IK to FK or the other way around.

Cons:
* This setup is very complicated, and requires a lot of connections and expressions.
* It is still necessary to keyframe an IK blend attribute (even though it can go from 0 to 1 in a single frame).


My goal was to find a way to animate the IK when I need to and the joint rotation (FK) when I need to without having to constantly change and animate the values of IK blend. This is the method that I finally chose:

4. Parenting and rotating the IK:
I parented the IK control to the elbow control, and the elbow control to the shoulder control. This way when I rotate the controls the IK rotates around them and the overall result is almost as if I rotated the knee, while the IK is always active (IK blend = 1).
This method is not perfect - if I will need real FK control I would have to set the IK blend to 0 and rotate the skeleton joints manually. That means I will be using the first method for this. Most of the time this will not be necessary as rotating the IK handle will be good enough.

Pros:
* The setup is as simple as the first method.
* In some cases rotating the IK around the elbow will give the same result as using FK.
* In those cases it won't be necessary to change or keyframe the IK blend attribute - it will always be 1.
* In special cases I will be able to revert to using Maya built in IK/FK blending.

Cons:
* After moving the IK, the rotation will not be around the elbow since the elbow already moved. This might cause unnatural movement of the arm, in which case it will be necessary to use complex IK/FK blending like in the first method.
* The shoulder control cannot be parented to the main control of the character (otherwise the IK will have no meaning). When the character will move while the IK is active, the shoulder control will not be in its place and rotating the IK around it will have the same effect as rotating the elbow control after the IK was moved.
* When using the built in IK/FK blending, all the cons of the first method will apply. Hopefully this will only occur in special cases and not every time I need FK, because most of the time I'll control the character with the IK.


As I said earlier this is the setup I will use.
I'll go over the specific details of the setup I created in another post.