Shoot 'Em Up

6B pencil on A4 copy paper.

The reference for this drawing is the poster of the movie "Shoot 'Em Up":

Life Drawing: Face in the Rain

6B pencil on A4 copy paper.

The reference for this drawing is taken from a modeling catalog.

Cubies: Week 8.5

Forgive me blogger, for I have sinned...
It's been more than two weeks since my last update.


I have been called for duty in the IDF for 3 weeks. This is the second of them.
But that's not a good enough reason to stop working, (after all I am still home every evening) and so I did, and I proudly present the next complete scene.
I didn't update much since I was actually working on more of the same: Animating, animating and animating. There isn't much I can say about that :)

This time I did a playblast of two scenes together: first the big Cubie wakes up and then a third Cubie comes into play.
Together it comes to 30 seconds, which is something in which you can start seeing the big picture.

That means in total I have about one minute of action, and I expect the whole movie to take something like 2 minutes - lots of work ahead!



What I have learned the last two weeks is, animating 3 characters takes about 3 times as much as animating one character, and a little more. Not a big surprise there...

Thanks for watching :)

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.

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

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.

First Render!

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

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.

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.

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:

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" :)

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.

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.

Reverse Foot Lock

I looked into the Reverse Foot Lock method, and there are indeed a lot of advantages in using it.
So today I deleted my previous foot controls, created a Reverse Foot Lock and added a control that is the parent of the reverse foot skeleton.

Tomorrow I'll try implement my method of IK/FK switching again, and we'll see whether that works. It gets even more complicated with the Reverse Foot Lock...

Constraint Weight

A better way to control when the constraint is active is to use the constraint weight, instead of the NodeState which I used so far.

The expressions to do that look something like that:

ctlLeftFoot_orientConstraint1.j_LeftAnkleW0 =
     1 - ctlLeftFoot.UseIK;

and

ctlLeftFoot_pointConstraint1.j_LeftAnkleW0 = 
     1 - ctlLeftFoot.UseIK;

* Update: this doesn't work as expected. I'm going back to NodeState...

The Elusive Blend Point

When you create a point constraint in Maya, and then key the constrained attribute, Maya automatically creates an attribute called "Blend Point". This attribute works like ikBlend: When its value is 0 the constraint is off, and when its value is 1 the constraint is on.

An orient constraint similarly creates an attribute called "Blend Orient".

Can I use these properties to blend ik/fk in my current setup?

I don't know. Googling "blend point" + maya yields the outstanding number of 22 results. Googling "blend orient" + maya yields only 2.

From my tests so far, it works fine as long as I don't forget to key everything before I start animating - the translation, rotation, Use IK, Blend Point and Blend Orient properties of the control as well as the rotation of the joints.

I'm going to try to animate like this, and only if I will have problems I will work on the 3-skeletons solution for ik/fk blend.

Up To Date!

I declare this blog up to date!

I tried to put everything I could remember from the past three weeks in here, and now it's time for the daily progress to begin.

My missions for the next day (or couple of days?) is:

1. Read more about IK/FK blend and apply it to the character's arms.

2. Read more about the reverse foot mechanism and its alternatives.
I think I will have to use something of this sort after all.

After that's done, I will continue to create a storyboard using my rigged characters.

Lattice Problem

I attached a lattice to the cube with no arms, and everything worked great.

After that I started working on my first shot, and found out everything was great only when the Cubie was positioned in the origin point (0, 0, 0).

This sucked.
The lattice seemed to move with the model, but no matter if I moved the parent group, ctlBody, or the model itself, the lattice effect was only according to the origin point. In fact, if I moved the lattice up, and then grabbed one of it's lower CV's, it would pull the surface as if I was moving one of it's upper CV's. So the lattice position did matter (too far from the origin and it wouldn't affect the surface at all), but in a really weird way!

Solution:

• Delete the lattice.


• Select the surface.


• Delete by type -> Non deformer history (delete history would mess with all the previous rig and blend shape)


• Create the lattice again.


• Group the lattice to the parent control (ctlBody).


• Everything works! The lattice even moves with the character :)

Quite simple ha? I've been messing with it for a whole day, for fuck's sake.
Pardon my French.

Blend Shape

I used blend shape to retract the arms into the cube. It sounds simple and easy, since all you have to do is pull all of the CV's in the arm and align them with side of the cube, and you're done.

But what is cheap to do very often also looks cheap, and that is the case here. If I would choose this simple solution, there will be at least two problems:

1. When the arms are retracted, the edge of the cube will not be smooth, because it has an overlay of several "layers" and there are some sharp edges.
2. When the arms pull out a little bit, when they just started growing, the hands (or feet) will look completely flat. Instead of growing from inside the arm, it will look like they were folded above it (which is basically what we've done).

To fix these problems the CV's should be aligned in such a way that when they are folded back there will be one single curve without overlays.


After fixing that, I found out that when the change is linear from the cube with no arms to the cube with arms, the hand start growing right away, and it doesn't look so good either. I think it looks more "real" if the hand start growing only after the arm has reached a certain point, say half the way.

Then I tried using "In Betweens" in the blend shape. I don't know why but I had a problem there. Whenever the blendshape attribute was set to 1 (meaning to retract the arms all the way), the arms was not only retracted, they made a hole in the cube side, as if they were turned inside.

Eventually after a lot of testing with the in between properties and the blendshape, I decided to do it "manually": I now have two blend shapes, one for half way and one for the end cube. The no arms cube is blend-shaped into the half way cube (NoArmsBlend). Then the original model is blend-shaped into the no arms cube (ModelBlend).
This requires the following settings for each position:

Attribute     Original Model    Half way    No Arms
ModelBlend    0                 1           1    
NoArmsBlend   doesn't matter    1           0

I then added an attribute to ctlBody named "Retract Hands", which goes from 0 to 1 and controls the two blendshape attributes using expressions.

This gives the following stages of growing the hand. Blend shape objects are on the right. Notice the "Retract Hands" property:

UseBackground Material

I was wondering how to create images with "invisible" floor - meaning you cannot see where the floor ends, there are no walls, the image background is all of the same color, but you can still see the shadows objects cast on the floor. In my opinion, this gives an instant professional and clean look to the shot.

It also saves a lot of work on set layout :)

I asked in an Israeli animation forum how to do that and got my answer: Using the "UseBackground" material which Maya supplies.

Cubies: Week Two

* As mentioned earlier, I started working on this project 3 weeks ago. But since I've been working at half capacity I will call it two weeks...

This last week I made some progress with my rig, as well as some unfortunate going-backwards episodes, due to various problems I found with the existing rig. The focus of the week was thinking about the story and how to make it possible.

• First thing I needed is to retract the hands of the cubies. This was done using a blend shape which is controlled by the main control of the character (ctlBody). That was not an easy task to make it look good, so it took most of the week, after testing different methods.


• After retracting the arms, the model looks something like that:
  
  


• From the model with no arms, I started thinking about the jiggle and deformations of the cubies before their arms grow. For that I created a lattice which is also controlled by ctlBody (you can see the lattice in the image above. note that the lattice only affects the body, while the hands are outside the lattice).


• Finally I declared my rigging "done", and started working on the composition and story board. The first frame of the first scene will look like this (materials and lighting are not yet done):
  
  



• Unfortunately, I found out some more problems with the rig the last couple of days so now I have to repeat some of the work. This concludes this week in a pessimistic tone...

Maya Wiki

I have used Lostpedia to ponder and speculate about the last episode we have seen. It currently has 3,301 articles.

I have used WoWWiki to learn about different aspects of World of Warcraft. It currently has 44,841 articles.

There is also a Psychology Wiki with 20,251 articles; a Muppet Wiki with 15,462 articles; and even, how wonderful, a Pokemon Wiki (6,838 articles) and a Dragon Ball Wiki (458 articles).

Why can't there be a Maya wiki??? It would be so much easier if there was one place where you can find explanation of every property, some best practices and common problems.

The Maya Help is not that bad, but a live wiki could be really great :)

Controls

All of my controls are NURBS circles. It looks faster than drawing the curve of each control, and it is usually pretty intuitive.
Maybe when I'll have more complex characters I'll draw arrows and such as controls...



Here is a list of the controls for my character skeleton:

ctlBody - Controls the body and is the base control for the whole character.

• Parent of: The body joint.


• Pivot point: The body joint.

ctlLeftFoot - Control the left foot.

• Parent of: The foot IK, and the children foot controls ctlLeftToe and ctlLeftFingers.


• Pivot point: The left ankle joint.


• Attributes: I added a new attribute named "Use IK". This is a boolean attribute which controls the ikBlend attribute of the IK. That way you can specify in the control itself whether you want it to control the foot or do you want to control the foot using FK.
  The connection between UseIK and ikBlend is done using the connection editor (no expressions or driven keys).


• Constraints: When I use FK, I want the control to follow the foot when it is rotating. That's why I added a point constraint and an orient constraint for the foot control according to the ankle joint.
  Since the control is controlling the IK, this will create a circular reference. The solution is to use the "Use IK" attribute to control the NodeState of the constraints.
  When UseIK = 0, the NodeState = 0 which means "Normal" - so when the IK is not used the control follows the foot. When UseIK = 1, the NodeState becomes "Blocking" which means the constraint is not active.


• I just found out this solution is only good when you don't key any of those attributes. Once you key the IK position, it will not snap back according to the point constraint. Once you key the rotation of a joint, it will snap back to the keyed position as soon as you set "UseIK = 0". I'll have to figure out what is the *right* way to do IK/FK blending :(

ctlLeftToe - Controls the left toe.
Its pivot point is the left toe ball joint, and it is not a parent of anything. Instead it controls the orientation of the toe ball joint using an orient constraint. It can only rotate, translate and scale attributes are locked and hidden.

ctlLeftFingers - Controls the left fingers.
The same as ctlLeftToe, the pivot point is the left fingers ball joint, which is controlled by an orient constraint.

ctlRightFoot, ctlRightToe and ctlRightFingers are the same for the other leg.

I have the feeling there is yet a lot to learn about how to rig a biped, create IK/FK blend and so on. There must be some "text book solution" to these problems :/

IK

There are only two IKs in this character's rig - one for each leg.
The IKs go from the ankle joint to the shoulder joint and uses an RP solver.

The pole vector of the RP solver is directed up when the toe is directed down.
Once we group the IK to a control (see next post), the pole vector is rotating with the group, so the knee is usually aligned correctly. The pole vector can be adjusted, but so far I never needed to do that.

The toes and fingers are not IK'd. I decided to set a control that simply rotates them with no IK. I also decided not to put a reverse foot mechanism. I hope that won't turn out to be a big mistake...

Skeleton

Some notes about the skeleton that is shown in the previous post:

• The body has only one joint. Deformations of the body itself and retraction of the arms into the cube will be done using different deformers.


• Each arm has one joint for the shoulder, one for the knee and one for the ankle.
  These joints are completely free and can move in all axes.


• Each feet has 4 additional joints: toe ball, toe, fingers ball and fingers.
  The two ball joints are separated so the fingers and toe can rotate separately and independently of each other.

Cubies: First Week

• Realized that for the arms to look good when growing, and be able to function both as arms and legs, they need to be rigged in a T-pose.
  Therefore I needed to change the model.
  Now it looks like that:
  
  
  


• Started basic rigging of the character using a skeleton.


• Added controls for the feet and body.

After the first week the model + rig looks like that:

Cubies: The Story

So now that I had a character, I also needed a story.

This is where I tend to get stuck. Finding an interesting story is very difficult.

What I have so far is this:

1. Growing hands

• The cubies start with no legs. They are just cubes in the beginning.


• In the beginning, there will be two cubes on screen. One is a little smaller than the other.


• After a few frames of standing still, the little cube begins to move and jiggle, and it looks like there is somehting inside it.


• After a few seconds of jiggling, the little cubie will start growing arms! (and the audience is in shock!)

2. Waking up papa cube

• The little cubie will "find out" his arms, and start probing his surroundings with his little paws.


• The little cubie is excited, he is getting up on his feet (hands?) and starts jumping around happily, surrounding the bigger cube.


• The little cubie start pushing and nudging the bigger cube, trying to "wake him up".


• Finally, papa cube is starting to slowly extract his arms as well until they are fully grown.

3. Papa cube walking

• Papa cube starts to walk, he is heavier and slower then the little cubie.


• Little cubie is still excited, jumps around papa cube and climbs on his back.

Now would be a good time to finish the short film if things gets a little messy. The two cubies will leave the screen and that will be the end.

However, I would like it better if there was another section:

4. Mulfunctioned cubie

• Papa cube and little cubie are walking to another cubie which still doesn't have any arms.


• The other cubie is a grown up - same size as papa cube.


• They try to wake the other cubie.


• The other cubie is waking up, however, there is a problem!


• Two options for the problem: (a) The arms are too short, so he cannot walk on them, or (b) one arm is ok, but the other doesn't come out all the way.


• The other cubie starts jumping on one leg, because that is the only way he can walk. (Another walk cycle! In the same project! yey)


• The cubies try to help the other cubie: little cubie is holding one arm while papa cube is pulling the other.


• The arms of other cubie finally come out to their full extent. Since both cubies are pulling the arms, papa cubie is falling back, while the other cubie and little cubie with him fly around him to the other side of the frame. Preferrably they will fly towards the camera.


• The cubies get up from the various positions to which they fell. They start walking together "towards the sunset".

The end.

I will try to keep future posts shorter, for the sake of the readers.
Though I can't promise anything :)

Project 1: Code Name "Cubies"

This project started with the idea of this simple model:



I was thinking about using this model for my first project for the following reasons:

1. Its simplicity will obviously make it easier to focus on animating and rendering rather then modeling and rigging. It will also make it easier to change the character rig later in the process in case there is something wrong with it.

2. Using the arms as legs and the legs as arms is something I think will add originality to the project, because everybody are doing "regular" biped rigs and walk cycles.

3. As a first project, this character will allow me to focus on weight and attitude (heavy vs light, happy vs sad, etc) which are the basics of animating.
In a way, this project will be my "3 balls" exercise.


I will call this project "Cubies" until I find a better name.
I think it will feature 3 of these cute little characters.

Some Background

So, who am I and why am I doing this?

My name is Yanir Kleiman, and I am 27 years old.
I have been a software developer for the past 10 years. I also have an MSc in computer science.

So how come I'm trying to create a showreel now?

Computer animation has been a dream for me for a long time, but it wasn't the only one. Somehow I lead my life fulfilling other dreams so far.

About 2.5 years ago, I decided I want to go for it, and took a Maya course. Maya is a 3D animation software, which is used today in some of the biggest studios to create both special effects in films such as "The Matrix" and pure animation films such as "Ice Age".

Shortly after I took the course, a friend of mine invited me to join a new-born startup company, and I decided to postpone the animation dream for another, took the opportunity and started working in that startup.
Unfortunately that didn't leave me much time put some serious work to my animation projects, which is why today I don't feel I really got better knowledge of Maya and the profession than I had two years ago when I just finished the course I took.

So about a month ago, I quit my job and dedicated myself to this career change.
I am hopeful this will be the first step on my way to fulfill this dream.

Currently I am working from home to create a showreel. When I have something done I will decide whether I'm going to go to school or look for a job in the industry.

Good luck to me :)

Welcome

Welcome to my showreel blog.
This blog will log my attempts at creating an uber showreel that will either get me a job in the 3D animation / visual effects industry or get me into a decent 3D animation / visual effects school.

I am working on this showreel alone, without a school or a mentor, with the generous occasional help of the various forums available. More on this in a specific background post...

I will try to make the posts in this blog as short as possible, but also as frequent as possible, so I will be able to somehow measure my progress along the way.

Thanks for reading, comments are always welcome :)

Yanir