References available upon request

Referencing

In the past couple days I have entered the land of references, building my scene files out so that I can begin to animate. I'm spending quite a bit of time on naming conventions and testing various aspects of my files to make sure that all the manipulating of files I will be doing is feasible. I've already dealt with quite a number of problems...

I began by reorganizing my scene files into subfolders, as below:



These folders (Animattic, Environments, Justin, and Master) allow me to continue working on the planet, its modeling, texturing and other environmental elements separately from remodelling and skinning Justin. I can, within a subfolder of each of these categories (as is visible in the Justin folder), continue to hone each element, saving regularly, and then resaving as the _Ref file when an element is completed and the file is clean (doesn't have extra Geo, Layers, Utilities or Shaders). The changes will ripple through the pipeline and when I open the Master_Ref file, everything will be updated.

Originally I was going to have separate files for each Shot so as to keep the files very light, however, this makes a couple things very difficult. I would have to animate linearly so that the end pose from shot 1 matches the beginning pose of shot 2, I'd either have to resave Shot 1 as Shot2 or copy all the numbers, which is a waste of time. Also, the one huge benefit of a camera rig is being able to playblast the entire piece very quickly. If I do all the animation in one file with separate cameras for each shot, I can always create a new camera, orient and point constrain it to all the cameras and key it so it jumps from shot to shot, allowing a quick playblast of all of my individual cameras. I can then delete and recreate this rig whenever I need to.

So, I've decided to do all the animation in one Master file, where the environments (the planet referenced twice as the Big and Small, and global sphere for the universe, as well as floating planet pieces throughout), and Justin (also referenced twice) are all referenced into one central file where all the animation exists.

Problems

The first problem I have come across during my referencing stint is with the IK/FK Switch script that is designed to allow seamless transitions from one to the other. Its a really useful script, and, like much of the Norman rig, a great thing to take advantage of since I have it.
After referencing Justin into my Master file I discovered that the script didn't work, causing a downward spiral of depression and self-loathing. No, but seriously--it meant I had to go back and figure out at which point the script stopped working. Fortunately, after some exploration, I discovered that none of my modifications to the rig were the problem, and since I was using distinct namespaces for each referenced rig, the reference wasn't the problem either. Unfortunately, something I expected to do very easily is now a problem--scaling Justin. Apparently, when the Placer is scaled it completely screws with the IK/FK script. I'd love to figure out how to fix the problem, but I have yet to attempt any rewriting of the script or creative grouping.

The real issue with scaling (in addition to the fact that I have two Normans that need to be scaled differently) is that the smaller the scene is the better--as Lauren pointed out, render times are exponentially faster the smaller the scene is--less calculation time for lighting, and the smaller the numbers, the less processing overall. So, I could potentially leave the small Justin at a scale of 1 so the switch would work, but that means that the planet is bigger and the big Justin is enormous. I probably won't need to use the switch on the big Justin since he basically holds a pose, however, then the scene is very large. My plan had been to make the large Justin at scale 1 everything else would be smaller. As of yet, I have no idea how I'm going to deal with this...

Moving along, I decided to take my camera rig and duplicate out each shot as a separate camera. In my hasty stupidity, this ended up taking many tries. I figured out fairly quickly that the duplicate options allows you to keep keys when duplicating. However, I discovered this using the Duplicate Input Connections box, which means that all duplicated objects share the same keys and deleting keys from one deletes them from all the others. After multiple attempts I realized this was the problem and changed to Duplicate Input Graph which creates a distinct set of keys (a distinct graph) for all duplicates, allowing modification without affecting the original.



So I'm currently at a crossroads where the cameras from my animattic are separated out and I can begin to get them set permanently. I'm a little unsure about the scaling issue but I'd rather sacrifice the IK/FK Switch and have lower renders, so for the moment I'm continuing as planned. I hope to set the cameras by the end of the day tomorrow so I can update my story reel with some beginning textures, my Justin rig thus far and some solidified camera movements and positions.

Editing Norman and Rigging Dilemmas

Editing Norman

In the past couple of days I've been on the Spline Doctors Blog where I've seen a bunch of uses of Norman remodeled to make various characters. Students at the Academy of Art in SF taking the Pixar classes have taken Norman and remodeled him a dozen times, as witnessed by all the characters below:



For one of their classes they have taken Norman and turned him into a space captain (below, top) for a short film the entire class is creating together, a clip of which is below.



and turned him into a space astronaut for the video below:



Rigging Dilemmas
Most of the characters use Norman's geometry and minimal remodeling, mostly of the face. However, a few of the characters are smoothly bound with single mesh geometry for the upper body. It seems that all of them have kept the legs as is, with a few creative flairs to hide the knees and make the lower leg into a boot. The one model that is completely smooth bound is the kid (shown with both blond and brown hair) and, as is obvious from the animator's website, Aaron Koressel built this character (Hordy) himself, whereas all the other characters are Norman.

To some degree I would love my character to have a uniform mesh as an upper body, however, it seems I would have to sacrifice some capabilities of the rig to make this happen. Here are my options:

1. Wrap Deformer
I could use a wrap deformer and wrap a single mesh to geo that is already skinned...however, this takes forever to render and wrap deformers are quite quirky...so moving on...
2. Rebuild/Reskin Geo
I could delete the upper body geo and build my own and reskin...however, the current geo is skinned to the bend bones which are the lowest level of skeleton and therefore respond to all the other parent skeleton systems. To get a smooth bind, I would have to skin the single mesh to a higher level of skeleton, causing me to lose bend bone and stretchy functionality. Plus forearm collapse and shoulder collapse is a worry, especially since the rig doesn't have extra joints built in to counter arm collapse
3. Blend shape
I've been using blend shapes fairly effectively, but the geo remains separate pieces...looking at the space captain above, it is possible to keep the geo as separate pieces and still have it look damn good--so perhaps I should continue along this path.
3a. Substitute Geo
I've discovered a skinning tool that allows you to swap geo that has exactly the same parameters as the one already skinned. Limitations are that it can't have blend shapes on it (so this can't be used with the face), and of course, that, as with blend shapes, there is no appending to the geo. However, because it is possible to smooth skinned geo and delete the non-deformer history, more detail is possible....
This option can be used in conjunction with the blend shapes, start with blend shapes and then delete them and just swap geo, this will minimize history.

After a lot of thought on the subject, I've decided to go with the third option. Since modeling and rigging are not my focus, I would rather minimize the time spent on them. As well, being that my piece is whimsical--the less realistic my character is, the better he will match his environment. So, instead of seeing the Norman rig's "rigid" bind as a stumbling block, I aim to play up and incorporate these elements into my remodeling. First off, I am a big fan of the patchwork look.. a la Sally the rag doll in Tim Burtons Nightmare Before Christmas. (below)



Unfortunately, patchwork generally has stitching across seams, not along them, so the idea of drawing stitching along the edges of geometry (especially since it separates) is not really a solution to my problem. I could play up the edges by using toon shader edges, something I'd been wanting to incorporate through previs. By drawing the textures in colored pencil and creating black outlines of all the geometry, perhaps I'll get a new twist on subtlety in the form of the hand drawn colored pencils, with in your face graphic art in harsh black outlined edges. I'll have to see how this looks with the Nose, Ears and Hair. Adding edges might have to be a selective thing so it doesn't overwhelm the character..
To be continued...

Face Texture

Images of Justin's face Texture:


Just Colored Pencil:


Posterized:


Posterized with Color Adjustment:


From the Side (same as Above):


I'm happiest with the last, but the stubble is too large, it should be dots, not strokes...and the lips are smeary and large, it looks like he is wearing lipstick...needs some work, perhaps a larger texture so I can go into more detail...

Further Skinning and Rigging Issues

Rigging
I've solved the eye issues---the rig includes a number of locators and clusters that control the eyelid deformation and they all have to be centered at the same place as the eye to work properly. So, in addition to detaching the head Geo with history on, moving the parent eye joint and reskinning the head so the eyelids didn't move with the eye, I also had to move locators and cluster pivots. All in all the eyes work fine, though the eye aim doesn't work anymore--I tried to realign the curves with the new position of the eyes, but the aim has a bunch of utilities built in that I couldn't figure out how to fix, and honestly, I should animate the eyes locally anyway.

Modeling
I've spent a lot more time on the face. I finished the hair modeling, added eyebrows and continued to tweak the eye sockets. They are far more almond-shaped now and look much more human. I made the nose a little less childlike by pulling the tip in a little so it doesn't look so much like a cherub. As well I pared back the cheeks some. Using my own advice I scaled the rig to get the head and hat/hair geo to have more depth and used that geo as blend shapes so the controls aren't scaled. I worked on the modeling of the upper body and the arms, as well as adding a hood to the sweatshirt he's wearing, with a pull cord. I've remodeled the pelvis and the thighs some the start to get pant-like legs instead of thin sticks. Below is a 3/4 shot of the model at the moment.



Skinning
I've worked on the skinning of the shoulders and am fairly happy with the result. There is a fairly smooth transition between the three pieces of geometry that merge at the shoulder--the upper arm, the shoulder ball and the torso. I'm a little worried that the intersecting geometry will look bad in renders, but I am hoping to give the texturing a very funky, stitched look. It will match the bohemian, hippie/skater style that I'm going for and hopefully I can get the stitching to fall along the edges of the various pieces of geometry. Below is an image of the back of the model with the shoulders in extreme positions. As well, the modeling of the hood is evident.



The problem I'm having currently is skinning at the elbows (and I am guessing I will have the same troubles with the knees, though I haven't tried to skin them yet). Because there are bendable bones built into the rig the arms are weighted to joints for the purpose of bending them. Instead of having a sphere as the elbow, I would rather weight the upper arm and forearm end vertices the same so that it becomes one continuous arm in the same way I skinned the shoulders. However, I'm having trouble figuring out which joint to weight the vertices to so that they move with the elbow. I've tried a number of the joints but none of them seem to do anything. I will have to keep experimenting...

PreSemester Progress

I've been alternating between modeling and texturing, I've had some progress and some setbacks with each.

Texturing:

The texturing is coming pretty well as a basic start, below is a quick render of the planet as it currently looks.



At the moment the image gets pretty pixelated when the camera moves in for close-ups so I'm going to have to scan the image at higher resolution. There is obvious faceting which doesn't seem to be solved by smoothing. The problem is solved by softening normals, however, because they are separate pieces, if I soften the edge normals the image fades to black along the edge and the individual pieces are obvious--this can be seen below.



I may have to do a visibility switch where I use a sphere for the end when the camera pulls out. The faceting shouldn't be an issue for the small pieces the smaller Justin manipulates, so a visibility switch won't be necessary.

Modeling:

As far as modeling Justin goes, I've been tweaking the face, smoothing out the cheeks and softening the chin. I also imported the ears I created for my original model of Justin and replaced Norman's ears. I created a hat/hair piece and am in the midst of extruding faces to make his hair stick out. He's looking more and more like a human and like Justin, which is encouraging.

I'm having some trouble with the body--unlike the head which is skinned to only one joint, the body is skinned between joints and it seems that adding a blend shape doesn't deform the geometry fully.--Just solved the problem...Because I smoothed the geo after it was skinned, there was unnecessary history active, so I deleted the nondeformer history, recreated the blend shape at front of chain and it works!

The one issue I'm still having is with the eyes. The twist controls on the eyes are on the parent eye joint, which i never moved, so the eye is rotating around an external pivot. This seems to be the issue with the lid twist controls as well. Still trying to figure out what to do about this...

Here's a screenshot of the model at the moment:



Also, it seems that I've discovered the reason the mouth flapped open and closed when rotating the head last semester--scaling the head control does it. I noticed that the head is very flat from front to back, as is obvious in the side view below.



I attempted to scale the head to fix the problem but I guess since scaling the head control scales the other controls, somehow distortion occurs and the geometry gets deformed bizarrely.

An easy solution to my problem is to duplicate the geometry while the head is scaled to the shape I like and use this new stretched geometry as blend shapes.

Mindful of additional inspiration

As I plunge into thesis land, I've begun to notice aspects of other media that are good examples for me to follow, and reminders of some of the ideas I've come up with to solve the complexities of the work ahead.

Sdrawkcab Krow (Work Backwards):

A video that is circulating the internet (below) and available on "YouTube" shows Michel Gondry, the music video master, solving a rubik's cube with his feet. As with most Gondry videos, it is an illusion of trick editing. In this case he took a solved rubik's cube and used his feet to mess it up and then played the video backwards--with some sound editing and cutting, the video is pretty convincing aside from a few odd quirks that are pointed out by the user "BeyondBeliefMedia" in his video "How Michel Gondry Faked His Rubik's Cube Stunt".





The video points out the concept of making sure the puzzle is solved by working backwards. I expect this idea will be invaluable in having Justin solve the puzzle ball--by starting with the final pose of the just completed puzzle and working backwards, I can make sure the puzzle is solved successfully and in a convincing manner.

Near and Far:

While watching "The Little Mermaid" the other day I was reminded of a concept I have been developing to minimize the amount of animation necessary while still being able to convey the video and complete the piece. I have been planning to intercut between close-ups of Justin with the puzzle ball with wide, sweeping shots of the entire planet to alternate the focus from detailed, convincing animation to storytelling and expressive camera movement. Disney did just this--I bet--for the same reasons, and its very evident during "Under the Sea" (below). The close-ups allow for really nuanced movement and lip sync which keeps the audience aligned with Sebastian, while the wide shots allow far simpler animation of Sebastian and shows the performance of the other fish, fulfilling the narrative purpose of the musical number.





Dreamweaver:


To some degree I intend this video to function as a dream sequence...a place where fate seems to have a way of directing everything that happens. I'm currently reading "Neil Gaiman's" "American Gods" and a comment he makes about "dreams" stuck with me as a great way to word the "dreamworldly" quality I hope to create within the video:

"It was a dream. and in dreams you have no choices: either there are no decisions to be made, or they were made for you long before ever the dream began."
(p. 303)

Parallel Pipeline Setup & UV Layout

As hard as it is to get back into the swing of things with the holidays only recently gone, I am attempting to focus on getting the preliminary setup done. And, if I use references for the rig and the planet, I can continue to update modeling and texturing for both as I'm animating, creating a sort of parallel pipeline where I can alternate which aspect I work on without affecting the others. Of course, this means some setup is required--i.e. laying out UVs, applying basic textures to make sure the look is basically what I want and some basic modeling to make sure the blend shapes don't ruin the skinning or the other facial blend shapes. So I've begun to do the UV layout for the planet, which is coming along, but is far more time consuming than I imagined...in addition to having to select all the outer faces of each piece to create one spherical projected UV map for the outer shell of the planet, I also have to have separate planar projections for each internal plane and layout all of these relative to each other within UV maps for each piece. Fortunately, my scripting knowledge has come in handy, so for the outer shell I created a Quick Select Set and wrote a two line code to add additional faces to the set:

{
string $x[] = `ls -sl`;
sets -edit -forceElement FacesSoFar $x;
};

This way I can create a Quick Select Set, and then select outer faces for each piece individually (with the others hidden) and add those faces to the set.
This makes it far easier to make sure no internal faces are in this set.

In total it has taken me two days to layout all the UVs for the planet pieces. Below is an image I created in photoshop, using UV snapshots of each piece and then I colored them relative to their original color (see post "Constructing the World" for photo of actual puzzle ball). Using a printout of this UV Layout I intend to draw in colored pencil the texture map for the planet. Instead of offsetting the image in photoshop and having to edit the edges to allow for tiling, I will fold the drawing and draw across the border to prevent seams.



I have also completed laying out UVs for the inside surfaces of all the pieces, however, it remains to be seen whether they will need some tweaking when I attempt to draw their images. Below are the UV maps for the six pieces.



As far as setting up referencing, I intend to use the animattic scene from my previs since it already has basic camera movement setup...However I will have to delete the rig and the planets because I need to import the new files I've worked on as reference. (I was hoping to just transfer UVs for the planets but the pieces had some extra faces that I hadn't noticed, which required some changes in geometry, so I will have to start over with that...oh well).

Back to work - Modeling Technicalities

After a brief break for the holidays, I'm back to work, aiming to stay on top of my production schedule by completing modeling and texturing before the semester begins. My preliminary issues are how to model and texture Justin when the Geo is already skinned. Lauren discovered a great texturing trick during her thesis where you can layout UVs on a duplicated version of a piece of Geo and transfer to the original as long as they are exactly the same in terms of number of vertices. Within the Modeling Menus, under Polygons --> Transfer there is an option to transfer UVs. So I can use all of the blend shape Geo I will be building to lay out the UVs of the skinned Geo. As for modeling, the biggest issue is making sure not to ruin the facial blend shapes. With the kid I modeled for character 2 moving the eyes ruined the main Lid controls. I had moved the joint itself, which Leif had seemed squeamish about. So this time I unlocked the translate of the eye control and moved the eye control--something I had tried originally with the kid, but didn't seem to work. I'm realizing the reason this doesn't work is for eye rotation because the center of rotation is where the joint is, not the control...so when I move the eye aim or rotate the head the eyes pop out of the head---I guess I will have to move the joints themselves.

The issue with moving the joints is that there are 4 joints for each eye, making it kind of complicated to determine which to move. There is an EyeArea joint that has the innermost eyelids bound to it so that for extreme movement, the eyes can pop out of the head and still be attached to the skin. Because of this skinning, I can't move any parent joint of the EyeArea joint or the Geo will be affected. So the only joint I can move is the jntRig_Rt_Eye (& JntRig_Lf_Eye). This is the joint I ended up moving in the kid last semester which for some reason ruined the basic eyelid controls. After moving the joint now the eyelid controls still work, so I'll have to check periodically and make sure moving this joint isn't the problem.