Moar Chubs

I've been plugging away at the Chub model over the past two weeks or so, and here's what I've got to show for it:

It's been an real learning experience, trying to get this whole thing set up. I've learned a few specific lessons very clearly.

1) Build a library of modeling bits to pull from.

It took me several days to export, clean, and polish each of the LEGO pieces from the CAD programs I found online (MLCAD, LeoCAD), but once the legwork was done, it was extremely easy to fiddle around with building new things. I can only assume that creating a similar library of frequently used shapes/items would be hugely useful to any modeler.

2) Mechanical joints are a pain in the patootie to rig for IK.

The human hip and shoulder each have three axes of rotation all centered on a certain joint area (clavicle/scapula/humerus for the shoulder, pelvis/femur for the hip). LEGOs, being mechanical objects, are not so nice. The equivalent joints on the Chub have the same three axes of rotation, but they are separated into three separate joints, each of which can only rotate along a single axis. Maya doesn't like this. In fact, if you try to set up those joints, limit their rotation, then try to put an IK chain on it, it's more than likely that Maya will just throw up its hands and go "Screw you buddy. I'mma rotate them joints however the hell I feel like!" And then your rig will go crazy.

This can be sidestepped by creating a separate 3-joint IK chain with which to drive the skinned joints. Even so, I've found it to be relatively unpredictable.

3) LEGOs are not meant to animate nicely.

I love the designs of the Frames I'm seeing from Mobile Frame Zero. They look phenomenal. I have very quickly realized, though, that LEGOs just can't be made to animate the way I would like them to. My two tentative solutions to this are to either create my own custom LEGO joint pieces for things like hips/shoulders, or to take these designs as inspiration and create 'real' versions of them. Obviously the second option will take significantly more time and exploration, but it could also yield some really cool work.

------

I think I'll be putting this project aside for the time being, though, so I can work on a new project that has just recently become available to me: home mo-cap. I went to the East Coast Game Conference last week, and won a Kinect from CineSys Inc.'s booth. I've been wanting to play around with mo-cap over the last few months anyways, but I don't have the money to shell out for the hardware. Now that I have it, though, I'll be working on figuring out how to get it up and running with MotionBuilder. Fun times ahead.

Gun Rigging

Quick update on what I'm working on! I'm now working as a pixel animator at Mighty Rabbit Studios here in the Triangle area, so I will be delving into more pixel work on here in the near future.

The Angels Fall First project is progressing well, too. The finished mech rig has been put aside for now so that I can do a full overhaul on the first-person arms and weapons.

The arm rigging is pretty nuts right now. The original meshes were created using a poly-decimator, which basically takes a hi-poly mesh and tries to create a low-poly version while maintaining the overall surface shape. The problem is decimators don't create clean topology, and messy topology looks crappy when it deforms. Thus, I've had to re-topo the hands and try to fit them all to approximately the same proportions, with a marginal degree of success. I hope to explain more in a future post.

My latest work, tho, has been on the gun rigs. I've got a ton of awesome weaponry on my hard drive, and I've been having a ball working on getting it all set up to animate. I took one of the assault rifles all the way thru to a finished rig so that I can start testing thing out in-engine soon. Here's a short demo vid:





This rig took a lot more work than I'd expected. It has a lot more moving parts than most guns (sometimes all you need is 2 bones: grip and magazine), which was work enough, but the real challenge was making the switchable pivot points. I tried a number of different methods, but the eventual solution ended up being pretty simple.

At the core, it's a variation off the simple IK/FK triple-skeleton switching system. I have two skeletons for the stock and grip which drive the main control skeleton. One skeleton is rooted at the stock, the other at the grip. The main body control houses the attribute which switches between the two. Ideally, I'd like to set up a script that will allow for matching between the two versions. Way down the road, I'm hoping to write a GUI that would allow the animator to switch out weapons on the fly and do other nifty tricks, but that's gonna take a lot more planning and work.

Alrighty. That's me for now. If things go well, I should have moar soon! :D

PyMel

I print tshirts for a living, and that means that a good chunk of my work-day is spent waiting for the machine to spit out the next shirt. It gets pretty boring if I spend that time just sitting and waiting, so I get on my laptop and do useful things instead. This week, for example, I started to look into using PyMel for some of my scripting needs.

To get everyone up to speed, Maya uses its own embedded scripting language called MEL - Maya Embedded Language. It's a good start for learning how Maya works behind the scenes, but it is rather rigid in its structure, and has a tendency to be very very verbose.

Newer versions of Maya have begun to include a Python runtime as well as a library which ports all (most? I'm not 100% sure) of Maya's MEL commands for use in Python. This essentially allows you to write MEL code while taking advantages of some of Python's nicer features: dynamically typed variables, more refined string manipulation, and not having to check every freaking line of code for the one semi-colon you missed that's causing your whole script to break. However, it still requires you to think largely in more of a MEL-type flow, which ends up feeling like a half-baked hybrid that nobody really would want to look at.

That's where PyMel is intended to come it. From what I gather, PyMel is designed as a more Python-y integration of Maya commands into Python. Honestly, I don't have enough experience to say for sure, but at first glance it does seem to be an improvement. I will add one caveat: it appears that others more experienced than I have a less-than-enthusiastic opinion of PyMel, primarily because they have found it to become excessively slow for large iterative tasks. However, since I'm writing small helper scripts rather than full-on tools, the speed differences have so far been indistinguishable. (As a final aside, a brief websearch indicates that PyMel is faster overall for scripting control, but it is faster to then switch to the Maya.Cmds functions for iterating large loops.)

Anyways, why is all this important? Because I'm a perfectionist and a minimalist (usually within reason). I like to do as much as I can with as little as I can get away with. For example, why write 5 lines of MEL code when I can do the same thing with 1 line of PyMel?

//Parent constrain lower-level control object's zero-group to higher-level control object
//MEL Code
string $OA_ctrl_parent_selection[] = `ls -sl`;
string $parent_ctrl = $OA_ctrl_parent_selection[0];
string $child_ctrl = $OA_ctrl_parent_selection[1];
string $child_group = "GRP_" + $child_ctrl + "_zero";
parentConstraint -mo $parent_ctrl $child_group

//Parent constrain lower-level control object's zero-group to higher-level control object
//Python/PyMel Code
parentConstraint( ls(sl = 1)[0] , "GRP_" + ls(sl = 1)[1] + "_zero" , mo = 1 )

I'll be the first to admit that the PyMel snippet is much more difficult to decipher, but ultimately it's going onto my shelf as a button anyways. I'm also working on translating to PyMel the script I talked about in my previous post, but it's still a work in progress. In the end, though, I just really love writing these bits of automation to make my life easier. My rigging is already getting faster just by reducing the number of operations I have to execute to get the same results.

Mech Rigs + Tool Writing

I've recently joined the Angels Fall First team as an animator, which is turning out to be a lot of fun already. I enjoy animating, but I love rigging and scripting, which is good since my first set of jobs are to rig (and eventually animate) the first big mech, the Velius Mk2, as well as some of the first-person arms and weapons. It's been a while since I've done any hardcore 3D work, so I've been shaking loose the cobwebs and getting back into my groove.

For the mech, I was given the in-game mesh weighted to an older version skeleton, but it was missing any sort of controls, and the existing animation had been baked down onto the bones. After looking the whole thing over, I scrapped the animation, detached the mesh, and went to work improving the skeleton. The original structure was mostly acceptable, but I added in some extra degrees of motion for the hips, torso, and neck, as well as bones for the toes. I also added in some bones which will be be used in-engine to facilitate the destructible armor plating.

Once that was finished, I weighted the mesh back onto the skeleton so it could move around. Weighting mechanical objects like a mech is a fairly easy process, since most of it simulates rigid binding, but it can still be tedious.

I then duplicated the skinned skeleton to provide a base for the control skeleton. My thinking was that by separating the control structures from the skinned skeleton, I could re-skin the mesh or fiddle with the rig controls without affecting the other too much. The two skeletons are exactly the same, except that the control skeleton has two sets of arms and legs to allow for IK and FK control sets.

Of course, a control skeleton isn't very useful without control objects for the animator to manipulate. Most rigs I've used in the past stick to NURBs curves for the controls, but I decided to mix and match. I'm experimenting with doing super-low-poly versions of the limbs instead of control curves because they are easier to spot and easier to click on. The arrow control curves were objects that I created quickly in Illustrator, saved as Illustrator 10 files for compatibility, then imported into Maya

With the control objects built, I now need to hook them up. The IK controls will be a little tricky, but FK controls are about as straightforward as you can get. However, connecting everything by hand takes a long time, so I wrote a little script to speed things up. All I have to do is select my control object, the joint I want to connect it to, and run the script. What it gives me is a control surface completely oriented to the joint with all its translation, rotation, and scale channels zeroed out. This gives the animator a nice, clean base to start with.

In all, getting to this point has taken me about a day and a half, and I loved every minute of it. I spent almost my entire weekend working this up because that's what I like to do. I'll post more shots as I finish it up. Also, go check out the Angels Fall First site! It's got a lot more cool stuff to look at!

:D!

Guuuuuuuuh. Had to rebuild Chester's head and his whole rig. Here's a shot from painting weights.



That is all.

EDIT:



Chester's so happy to have a (minimal) working facial rig. Definitely not ready for any sort of real lip-sync, but it'll have to do. In my ideal world, I'd have time to make a snazzy face UI that has crazy stuff like, you know, labels for what controls do what, or blendshapes, or something. No time for that (both b/c of time setting up in Maya and working on downstream UDK implementation). Gotta crunch as much in as fast as possible to get a passing film.

Reeeeeally want to start working on a side-project that we've got cooking on the back burners. May throw out some hints later on... :D

Exploratoring

Continuing in the vein of my previous few posts.... PROBLEM SOLVING!

Probably the most exciting part of solving problems for me (other than the thrill of finally fixing a tricky issue) is research. I'm a self-admitted information junkie, and I love learning new stuff. Anyone who knows me can attest that I spend a lot of time browsing for new techniques, cool tricks, or just stuff I want to know (I've gotten into a bad habit of reading Wikipedia articles on food when I'm hungry). One of the side effects of this is I've gotten reasonably good at targeting searches and finding elusive information. The sad reality is, though, that just because I'm looking for information doesn't mean that it's there to be found. This has been especially true in the case of Maya Character Sets and Trax information.

Still alive...

The cake is a lie...

Just doing a quick post to keep this thing going. I don't have anything to show for the past two weeks... yet. I've been doing a lot of rigging work which is all very technical and not very visual. Long story short, I got my Nazi Grunt character fully rigged and weighted, which made me very happy. Then I exported him to the UDK for testing, and that did not.

Maya uses the Y-axis as its world-up, while UDK uses Z-up. I've been doing all my modeling and character prep in Z-up space, but the autorigger I've been using doesn't play nicely with Z-up, so I did all the rig setup in Y-up. Needless to say, that causes problems. Additionally, the autorigger adds a lot of extra bones to handle IK/FK arms, legs, and spines, and those get exported to UDK as a mass of crazy. Had to figure out how to pare it down to just what I need.

Technical Stuff
For those interested, here's how I solved these multiple problems:
1) I saved the whole rig to a new file, where I stripped the skeleton of everything except the smooth-bound joints. I then parented the floating joints (spline-IK spine) to the root spine joint.
2) I then exported a skin weights map to preserve all the weighting I'd done this weekend, then removed the mesh's smoothing skinning.
3) With the mesh and skeleton separate, I was able to rotate the mesh to orient correctly, and could freeze the rotation of the skeleton's root joint. This solved the issue where my animations played along the wrong axes in UDK. Previously, even with the controllers pointing correctly, the actual skinned bones were receiving translates/rotates along the wrong axes.
4) I smoothbound the rotated mesh to the skeleton and re-imported the skin weight maps. Because I have some mirrored UVs to save on texture memory, I had to re-paint some of the weights and mirror.
5) This file was saved, then imported into the file with the full rig. I deleted the mesh attached to the full rig, then parent/orient constrained each of the bound joints on the imported file to the rigged joints of the existing file.

This gives me a certain level of compartmentalization between the rig I'm animating versus the rig that's actually moving the mesh. I can now change around the controller mesh in various ways without affecting the bound skeleton and mesh. If, for example, the leg rig turns out to be something other than what i wanted, I can remove the control structure, create my own, and I don't have to worry about re-exporting a new version of the skinned mesh to the UDK or having to update any exported animation to account for new/deleted bones, or changed proportions.

The downside to all this is I've realized that I have to do this to Chester, too. Not as bad as having to figure it all from scratch again, tho.