____________________________________________________________ Welcome to my ever-expanding animation knowledge base! This file gets updated every week that I do animation. Last Update: 10/21/2007 Current Project: "Misfit Magician" - Laura Skowronski Visit http://www.animationmentor.com Feel free to contact LauraSko (at) gmail (dot) com. portfolio: http://www.laurasko.com blog: http://www.inbetweenthekeys.blogspot.com PRACTICE & THEORY, ETC, LEARNED IN THE PROCESS ____________________________________________________________ GENERAL ***General "Mantras" -Make something; then change it! -Stepped mode is awesome for posing, so quit being lazy and relying so much on splines! -Keep on task, and remember to take breaks when they are due! -Save it NOW! Save it NOW! Save it NOW! (Frequent Incremental Saves and Backups!) ***Production Schedule Adjustments All models and rigs should be finished before starting on layout and blocking. (This seems obvious but I thought there would be enough time to finish some adjustments in the beginning weeks - this just adds complications to an already complicated process. You find there is a lot of difficulty in that there isn't a ready pool of assets: you have to keep building as you construct the layout. Feels disjointed sometimes, but other times a break from layout is most welcomed by a mini modeling/rigging project, before getting back into layout again.) Also, don't be afraid to adjust shot length based on the need to sell a particular mood or action - but plan accordingly! ***Referencing Models Into A Scene Referencing has been the greatest tool I've learned in this class. Note: When using a referenced character rig, facial controls (and other keyable controls) need to be keyed in the animated scene file, even if there is no change in expression yet, or only a single pose - otherwise the facial positioning will not be saved when the file gets referenced back in (upon opening the animation file later). Great to begin work on it and test out your models/rigs before you set foot animating - if something breaks, you can go back to that file and change it, and you won't have to worry about how much animation you lost. In the past (team projects at Purdue), we didn't reference files - all our elements were in one file - if something broke, we didn't handle it properly. We didn't correctly export and import back the correction (we tried copy/paste, which worked only sometimes, and generally added frustration). File sizes grew to enormous proportions. Last minute fixes meant severe loss of time and effort animating up until that point. Those aspects have been resolved through what I have learned in this class. ***General Frustrations Especially in the early blocking stages, it is hard to know when it will be "good enough" - it is easy to keep going on one shot, tweaking until you get to splining animation, and meanwhile, other shots are being neglected. The main objective in the blocking phase is to anchor character poses and determine timing. It is not about splining and fluidity and arcs. Make small moves to each shot, and keep polishing little by little. Don't get too consumed with worry about grades. Things might be tough in the beginning, but there is plenty of room to grow. *** SCRIPTS AND TOOLS ***Got Em and Love Em Mel Scripts From Purdue... ***Check these out at some point: |_ Michael Comet's plugin resetSkinJoints (http://www.comet-cartoons.com/MELfiles/resetSkinJoint.zip) |_ zooWeightSave (http://www.macaronikazoo.com/mel/download/000147.html) by Hamish McKenzie *** MODELS ***Selecting the Unselectable: Geometry Edits AM protects their rigs and models. During the creation of the rabbit, I used the default Pawn model and tweaked the setup defaults so that it resembled something closer to a rabbit. However, some changes were needed on model vertices/edges to sell it. Unfortunately, the geometry was not selectable. Kevin Freeman of AM Support answered this question for me. He suggested that "this geometry is most likely referenced. In order to edit it you have to open an attribute editor and choose the display options [he means Drawing Overrides] and change override enable to normal or turn it off." Sure enough, after finding the exact piece of geometry I wanted to edit (after hunting for it in the Outliner), I opened the Attribute Editor and unchecked "enable overrides" which indeed had been a "reference" display type. I'm always amazed at how much there is to learn about Maya and its wonders, specifically the depth of the programming and detail of user capability. *** TEXTURES ***Rendering Bump Maps For some reason when I attempt to render a frame, my bump maps aren't being rendered. (Default lighting.) Stylistically I should forget about bump maps anyway - chars are simple, scene should be simple too! *** RIGS ***Handcuff Rig Using IK to solve chain quickly. Not the best solution - will not allow waves through Z plane - only mimicks gravitational effect when cuffs are closer together. Rotation along X enabled by "Twist" attribute in IK Handle channel editor. Q: Is there a way to set a maximum distance (limit) between the cuffs so that they don't stretch (or detach) the chain from the other cuff? *** CONSTRAINTS ***Hat on Head, Then in Hand In the beginning, the hat is parented under the head locator "top of head." However, when he lifts the hat off of his head, the weight of the parenting is transferred to another (the hand/wrist locator). Whereas before the Head Loc weight = 1 and Wrist Loc = 0, now after the transfer, Head Loc = 0 and Wrist Loc = 1. (Note: Eventually transfered to other wrist.) It must be noted that this was carried out in a very general way for layout (before hand was positioned). However, after hand and wrist were positioned (the wrist-hat relationship remaining the same), now the location and rotation of hat became undesirable. Attempting to delete the parent relationship (to create a new one) resulted in various failures: position and rotation of hat changed, or hat disappeared altogether. Rather, without intentionally affecting the existing parent relationship, simply select the parent and its child and develop a new parent constraint - as long as they are the same parent and same child, it will override the existing parental relationship. ***Hat on Wrist, then on Ground Initially there were Top of Head, Right Wrist, and Left Wrist constraints. To get the hat on the ground at f.615, I thought I could put all constraints' weight at zero and key the hat's position and rotation. However, keying the hat at the new positions and rotations (even using "key select" for T/R only) resulted in the visual loss of all weight control on the hat (weight information was intact, but hat visually remained in new set position and rotation while scrubbing back through timeline). It is possible that this is a problem for the hat and not for other objects (such as eye position?) because the hat was never keyed on its own: from the beginning it has been parented to something (head, then R Wrist, then L Wrist). Solution: Continue to operate on constraints: in Hat file, duplicate hat control and scale up in X and Z (leave Y alone). (Would have been good to rename as hat_life_con or something, but in this case I left it at hat_con1 by default). Create parent constraint over the hat geometry (like original hat con). Set to zero. Open main scene file and record the last known position/rotation of the hat under original constraint (record T/R of hat_con at f.613). Use these numbers to position hat_con1 on f.613. Key position of hat_con1. Go to hat geometry and key the hat_con and hat_con1 constraints (1, 0) on f.613. Then on f.615, reverse constraint keys (0, 1) so full weight is on the new hat_con1. Key off visibility of original hat_con to avoid confusion. New hat_con1 should eventually hold any deformers if they are added since deformations won't be performed except after hat is thrown to ground. If deformation is later desired through the earlier animation, visibility of hat_con1 can be keyed "on" to use deformation slider controls, but note, position of hat_con1 will be stationery until f.613). ***Casket/Hands during push onstage I'm not exactly sure why there is a problem animating a keyable constraint (like parent or point). I wanted to constrain the hands to the casket (using a locator which is directing the motion of the casket). However, doing this causes problems keying the hands prior to or following the push action, even if the blendparent is set to zero at those times. It appears that keys are adjustable, but difficult to adjust. The hand control fights the mouse input translation. Having redone the constraint, apparently it does work - not sure why it didn't work the first couple of times. Here's the key: you make your constraint. You key the blendparent at 1. you key the frame prior to that, blendparent zero. You scroll back in time to the frame you want to adjust. If you try to translate the hand, it will fight you and attempt to blend inputs (the mouse vs the constraint) even though blendparent is zero. However, if you click off of the hand control (deselect it), then reselect it to attempt to translate it, you will succeed!!!! *** IK VS FK ***How and when do you decide to use IK or FK in your shots? This should be decided as early as possible, but especially as you are beginning the layout phase. I did not go through it shot by shot until I was well into blocking, which is really almost too late and causes complications. Think about it: if you were drawing a 2d animation, and you have to hold your current drawing over a previous drawing to get a hand or foot in the exact same place, IK will help. Otherwise, in most situations (especially to maintain fluidity of overall momentum and arcs), FK is best. Known Issues: When he is doing the card flourish, it was originally thought that IK would help position his hands specifically. However, the arm posing is more difficult (arcs, etc), so card flourish should be redone in FK. FK should be used while taking his hat off. Hat should be constrained to thumb joint if possible. It is thought that IK should be used while pulling out the rabbit - is this a good idea? When he is pushing the casket, IK will help stabilize his hands to the bigger movement. When he is shaking the girl's hand, IK will help stabilize their hands together. When he is pulling the saw out, he will be moving in an arc that would benefit by using FK. When he is sawwing with the saw, it should be rigid and specific, which will benefit by using IK. When the policeman is holding his arm, IK will help hold it still. *** ANIMATION (SETTING KEYS AND EVERYTHING INBETWEEN) ***Layout: Keep things simple - get cameras ready. Shape the scene like you are shaping a piece of clay; layer things in like a painting. ***Blocking: When I'm setting keys on body controls during blocking, I'd like them to stay in stepped mode. However, many times after I set a key, the immediate keys around it go into spline or linear mode, and I have to highlight the whole timeline and reselect "stepped" under Tangents. Is this avoidable (can all keys be created in stepped mode by default)? It gets irritating to have to reselect keys and adjust the tangent settings all the time. ***Master Control In the layout stage, I had positioned characters using the master control. However, when I began my blocking, I wanted to transfer the master control's channel values (for translation, rotation, etc) to the pelvis control. Next time I begin a project, I should not use the master control primarily; instead I should apply most transformations to the pelvis and feet to avoid so much rework in the blocking stage. (?) |_ How do you handle the use of a character's master control? (Particularly in the transition from layout to rough blocking...) |_ When I began my short film layout, I used the master control to position and rotate the character within the scene. However, when I started blocking, this caused a lot of re-work (repositioning the character's pelvis control and feet controls). Is this "re-work" inevitable? |_ One idea I thought might work would be to leave the master control alone (at the origin) and set keys only on the pelvis and feet to position the character during layout. |_ However, I've heard suggestions that doing this may cause a higher likelihood for gimbal lock to occur. I've rarely had problems with gimbal lock since I only rotate along one axis at a time, but I'm still not sure if this is the best method to pursue. Any tips for me? |_ When you start with your layout & blocking, it's very important to place your characters in an appropriate starting position (also rotation and scale) using the master controller. |_ However, once you've set the character up to start acting, do not animate (key) the master control for translation or rotation - instead use the pelvis, feet, and other various controls. |_ When you animate position using the master control, you will likely have to go back and rework all of your other controls later. |_ Some may argue that you can transfer keyed animation from the master to the pelvis, etc, but this isn't so true when you already also have keys set on the pelvis (relative to the original keyed master position) that you'd like to keep. |_ It's just complicated - so my advice - avoid it! Don't touch the master control unless you really need to (like if you are keying visibility or animating a sliding / skating person, etc). ***Transferring Channel Inputs from one animation control to another: (more on this later) *** CAMERAS ***Deleting "Non-deletable" Cameras I had grouped all of my default cameras (in the outliner) and the next time I opened the file, a new set of default cameras had been created (probably because Maya did not see them in the main Outliner, and didn't search my folders). The problem? I couldn't delete them - I kept getting a message "Error: Non-deletable node 'front1' cannot be deleted" in my script editor. The solution? Maya's cameras can be queried for their non-deletable status using the "camera" command: camera -q -startupCamera persp; // Result: 1 // Say you have a rogue "front1" camera. If it is a startup camera, clear this attribute with: camera -e -startupCamera false front1; This should take care of it. (Thanks to http://www.highend3d.com/boards/index.php?showtopic=110387 for this one.) *** RENDERING ***Fur UV Problem (Fur Not Adding Correctly): thanks to Ryan Ellis for this information. http://www.ryane.com/ Use Automatic Mapping: Apply fur, then select geometry and use the following command line: performPolyAutoProj 0; This screws up UVs for texturing, but as long as I'm using fur and not textures, it will be fine. Suggestion: use base of fur color for geometry material color. Painting fur settings is also an option. Setting info: Density (hair count). Global Scale (typically leave alone, global way to change all hair settings). Avoid Baldness slider. Inclination (rotation: how much the fur is following the surface normals). Roll (90 deg off inclination). Polar (lengthwise axis). Clumping (randomly clumps hair for a semi-wet look). Segments (less: angular hair; more: smoother, but longer render time). Offset (from body surface). Current test: Polar bear fur; density 80,000; length 0.5; inclination 0.8; roll 0.182; polar 0; bw 0.15. My disk is filling up with zillions of fur files - what can I do? (From Maya Help:) ---Once your render is complete, you can delete anything in your furFiles directory, furShadowMap directory, and furEqualMap directory - these are recreated each time you render, unless you are using an Advanced Fur Rendering technique. Do not delete the contents of furAttrMap which are prefixed by any scene name you still require - these are your Artisan and baked maps, and are needed to define the Fur. If you are happy with your final composite, you can also delete the contents of your furImages directory - otherwise you may want to keep these to use separately in a compositing application. ---Solution: To have these files deleted automatically when no longer needed, turn off "Keep Temp Files" (off by default) and/or "Keep Fur Images" (on by default) in Fur Render Settings. The deletion takes place after each frame is completed.