Block Controll

This tutorial deals with the block controller. We'll discuss some general concepts on this controller, some tips on how to make it work properly, and a look at some issues and limitations when using it. So, let's get started.

The block controller's main purpose is to let the user be able to define certain action, to store it in the controller, and recall it later so it can take place again so it can be re-used without having to re-animate the whole thing again or having to copy/paste the appropriate keyframes and adjust them so they work on a new position in space. This is a rather romantic definition, because we'll find that there are some limitations to this controller we need to know in order to be able to use it with the minimum hassle and maximum efficiency.

First, we'll go over the procedure to create a block controller with stored animation, and how to use it. I've used a rather simple scene to illustrate this, but it works. You can afterwards try on your own to recreated the block controller's effects.

Restart MAX. Now, I've used two simple objects here. A sphere and a cube. Create the cube in the perspective window, and the sphere in the left or right windows, just below the cube. Now, for a simple animation, select the sphere. Go to frame 10 and click on the animate button (n hotkey), and move the sphere upwards a bit in the left viewport. Click on the animate button again, and select the keyframe at time 0 in the trackbar, and shift-drag it to frame 30. That does it. Play the animation, and you'll see your ball performing a small jump. Now, link the sphere to the box. Grab the box and move it to the left side of the screen (front viewport). Go to frame 100, click on the animate button, and move the box to the right side of the screen. Turn the animate button off. Now the sphere jumps while following the box from the left side of the screen to the right.

Ok. Now, let's recreate this jump a little bit ahead of time. Open your trackview. Look for the global tracks, and click on the plus sign on it. The last track on the list should be named block control. Click on the plus sing on it. There's an 'available' track. Now, click on the assign controller button. The only available controller for this track will be MasterBlock. Assign it that controller. Now, the MasterBlock track will have a plus sign on it. Click on it, and you'll notice a blend track there, and a huge space between the MasterBlock track and the blend track. That space is where you'll assign blocks of animation. Let's try that now. Right-click on that space, and a little menu will appear. Currently, there's only one available option in that menu: Properties. Click on that. A dialogue box will appear showing all the blocks that you've defined for that track (currently none), and some options to manage those blocks.



Yes, each MasterBlock track can contain several blocks of animation. That's useful, so you won't have to define one MasterBlock track for each block you wish to create. Just bear in mind that your motions shouldn't overlap, or the first one will be blocked out by the second one. If you're to create overlapping motions, use several MasterBlock tracks. Ok. Let's get back to where we were. In the properties dialogue box, click on the Add button. A small window resembling the track view window will appear. Expand the tracks until you see the sphere's position track. It should be black, meaning it is available. The block controller will not let you select tracks it considers invalid to create a block.



Select that track and click ok. A block parameters dialogue box will appear. This box lets you choose a name for the block you're creating, a color, and from which to which frames are the tracks selected (you can include more than one in every block) going to be included in the block. Select any color you wish, name the block 'sphere jump', and set the frames from 0 to 30 (the frames the sphere has been animated).



Click ok. Click ok in the properties dialogue box. That does it. You have a block of defined motion called 'sphere jump', which uses the sphere position track as its 'source'. Now, you'll add blocks of motion into your animation. Right-click anywhere in the space of the MasterBlock track. Now, the menu will have an option called 'sphere jump' above the properties option. In this menu will appear all the blocks you've created for this track. Select the 'sphere jump' block in the menu. A small blue (this is the default color) box with one keyframe at the beginning and another at the end will appear on the track. Move it somewhere in the middle. To position it accurately, select it and right-click on the block. A small window will appear. The options in this window are Relative Motion (more on this later), and start and end frames. Set the start and end frames to 30 and 50 respectively. Leave relative motion checked. Click ok. Play your animation. You'll see your sphere jump twice in your animation. Want another jump? Just right-click on the MasterBlock track, and add a second block to your animation. Select it and drag it somewhere afterwards the first block. Now, one interesting and useful feature of block controllers. Select the rightmost keyframe in the block, and drag it to the right. The block will stretch and become larger.



Now play your animation. The sphere jumps three times, but the last jump is slower that the previous ones. This is because you 'stretched' the motion. This way, each block can be shorter or longer, thus affecting the animation contained in it, making for very quick changes in each motion's timing.

Ok. Let's take a quick look at the track named 'Blend'. It's the track just below the MasterBlock track. What this track does is control how much of the block's motion is sent to the final motion of the object. What this means is that you can still manually set keyframes of motion (or any other animation method) to your object, and then blend the original keyframed motion with the block controller's motion, allowing for some complex layering effects. On the more simpler side, this would allow you to turn on or off the output of a certain MasterBlock track. Try it. Add to keyframes to the blend track of the MasterBlock track containing your sphere's motion (the only one at this point). Move the first keyframe to the middle of where the first blue block is, and the second at the middle of the second block. Leave the first keyframe's value set at 1, and set the second keyframe's value to 0. Play your animation. You'll notice that the first jump of the sphere (the original keyframed one) is untouched, whereas the second one is a bit more faint, and the third one is very subtle. This is because the blend fcurve is sending less data to the final output of the object's motion. Think of it as a multiplier curve applied to your block.

LIMITATIONS

Lets now see some of the current limitations of this kind of controller.

ABSOLUTE/RELATIVE MOTION LIMITATION.

This is some strange, probably faulty area of the block controller. Each block has a Relative Motion checkbox. If unchecked, the block controller switches to Absolute Motions. From my basic understanding of the terms 'absolute' and 'relative', I could say that what this checkbox does (or should do), is allow the object to repeat the changes in the block (movement) to repeat somewhere else, or at the same position over and over again in either the scene or relative to another object (if linked... please refer to my World Space/Parent Space paper for more information on this). This would be helpful in designing absolute repeating motions. However, this is not the case. As soon as you uncheck the Relative Motion checkbox, the object moves to an offset position. And the motion is not exactly what one would expect. Besides, if there are two adjacent blocks of the same movement unchecking this in one block appears to affect the other block as well. So, either this is some feature that works in a way beyond my comprehension, or it's a broken control. In any case, I haven't found a situation where I'd like this option unchecked.

LOCAL/WORLD COORDINATE SYSTEM LIMITATION.

One of the limitations was spotted by Florentijn Bos, from Stereomatrix/Kasander Film. Try the following. Create an object with something pointy on it, just to show where it's facing (I used a sphere with one pulled vertex using soft selection). Animate it the following way. Go to frame 30, and animate it moving forward. Now, animate it rotating on its Z axis so it now faces 90 degrees to the left (I use local euler XYZ rotation controllers by default). Play back the animation, and you'll see your object moving forward and turning to the left at the same time. Now, create two blocks of animated data (following the directions outlined above), one must contain the object's position track (the movement), and the other should contain the object's local Z rotation. Name them 'move forward' and 'turn left' respectively. Now, position a 'turn left' block at time 40 (so it goes from/to frames 40-70), and create a 'move forward' block at time 70. Play back the animation. What happened? The object, instead of moving forward, moves in the direction of its original motion, which now is backwards from the point of view of the object's orientation.



This is most likely not what you intended (at least it wasn't what Florentijn was trying to achieve). What I believe is going on is that the block controller derives its calculations with reference to world coordinates, not the object's local coordinates. This leads the controller to continue with the motion you set up using those coordinates. Since our object was moving using a positive X-direction motion (at least in my case), the block will continue to do so, ignoring the fact that the object's local coordinate system is now facing in a new direction in relation with the world's coordinate system. Bear this in mind when using this controller.

BLOCK CONTROLLER INTERPOLATION LIMITATION.

The second 'limitation' is the fact that the block controller uses linear constant interpolation throughout different sequences of blocks. Here's one example. Create a walk cycle (it doesn't matter if you've never done one, just DO IT! You'll thanks me afterwards for this... it doesn't matter if you're not using a full IK system. Just create a pair of legs and do a short walk cycle, nothing fancy, just the end effectors moving). Just enough to be able to define a block and repeat it. For more on creating walk cycles, please refer to my walk cycle tutorial.



Ok. Now, create a block that holds all the animated tracks relevant to this walk cycle (i.e. Foot movement, center of mass translation, hips rotation, etc.).



Now, place some blocks in the MasterBlock track, one after another. Say, four blocks. Play back your animation. How did you do?

In my case, I wasn't very lucky with my first attempts at using the block controller for this kind of task. My character started lifting over the ground, its feet lagging behind his torso, and some other nasty non-expected behaviors. So, what's the deal with this kind of thing? Here's what's happening. The block controller takes a look at what each block contains, and performs a linear additive absolute increment for each consecutive block (???). Well, that's what I call it. Let's have a closer look. Assume your right foot is at (20,-50,20), and the center of mass (the object that moves the whole body) is at (0,-20,100). Let's say that after the original mini-cycle is completed (the source for all the blocks), the positions for the foot and COM are (20,-150,30) and (0,-160,100) respectively. So, what happened in short is that the foot moved 100 units in the negative Y axis (the direction of my walk), and the COM moved 140 units. There's a 40 unit difference. The foot is 40 units behind the COM to the block controller. Although not apparent in the first block of the animation, it is more than obvious after four additional blocks of motion. This is because the foot is now 160 (40 units * 4 blocks) units behind the COM. This also happens with the other foot. And if your COM is slightly above its original position at the end of the block, this difference will be taken into account, making your character walk while lifting through the air... woohoo!! So, this is unavoidable. But is there a way to fix this? Sure there is! In fact, there are two things you might do...

THE MATHEMATICALLY PERFECT SOLUTION: This solution can be the quickest, bullet-proof, hardest solution there is. It means you should construct a mathematically perfect walk cycle before repeating it with the block controller. The feet should have exactly the same translation with respect to the COM. They should start and end at the EXACT same height, and the COM's translation should always be constant, and start and end up at the same height and angle (if you're using hip rotations). In doing so, you're making sure the block controller will interpolate without flaws, and every block of animation will be correct, because it starts and ends exactly the same way. Although its an ideal solution, it's more often that not the wrong way to animate a walking character. So, here's the new idea...

THE ARTISTIC, MANUAL, HARD SOLUTION: What you do (I did) to solve this situation is go to the frames where keyframes should exist inside the block, look for unwanted offsets in each object, hit the animate button, and manually bring them to their correct position/rotation. Now, this means a lot of manual, hard work, since you'll have to correct almost each set of keyframes. But the block controller will retain the blocks repetitive nature while respecting the new keyframes you've set. For example, my walk cycle has keyframes every 10 frames, and goes from frame 10 to frame 60. This means that I'll have to check for errors every 10 frames going from frame 70 to frame 260 (the 4 additional blocks I've set take this amount of time), and manually correct each moving object (the two feet nulls and the COM null in this example). After that, you'll have a nice, repeating cycle. ONE THING! Once you're done setting keyframes (or while you're at it), you MUST set each keyframe's (besides the original, of course) interpolation to linear, both in and out. This will prevent overshoot to interfere with both your desired motion and the blocks stored motion.