Friday, December 11, 2009

Dante's Inferno Demo

The demo for Dante's Inferno is out on PS3 today. Download to get a taste of hell! The demo will be out for the 360 on 12/24/09 and the game will ship on 02/09/2010. Hopefully everyone's hard work here will pay off:)

Click here for a video of the demo.

Saturday, October 3, 2009


I finally decided to man up and give this Odosketch thing a try. I feel super rusty with the pen and pad. I think if my past art instructors saw these, they'd take back my degree. Anyway, Odosketch is definitely addicting. Hmm...maybe I could use it to thumbnail animations...

Sunday, August 23, 2009

Junior Guardians

Back when Final Fantasy X ruled our nights. Here are some quick paint-overs of the kids as characters from the Square Enix game, just for fun.

Daughter and her friend as Rikku and Yuna.

Nehpew as Auron.

Little nephew as Wakka.

Saturday, August 22, 2009

Rohan Rig: Quick update

I've updated Rohan's FKIK matching scripts to work with namespaces and referencing (through the picker). FKIK matching will now work with multiple characters in a scene. Thanks goes out to Jeremiah Grant for showing me how to do this.

Just download the rig again for the updated scripts.

NOTE: I've changed the rotation order on the weapon controllers. If you're in the middle of an animation, you could just manually change the rotation order back to the default xyz.

Tuesday, August 4, 2009

More Dante's Inferno Gameplay Footage

Here's some more gameplay footage from Comic-Con.

This is King Minos, one of the earlier bosses in the game. I worked on him alongside 2 other animators. I animated the first "button-press mini-game" sequence where Dante stabs him in the eye. I also did a few other anims, including the swipe attacks and the palm slam (not fist pound). (Hopefully I'll have time to polish more:))

Kyle Winkelman
was responsible for Minos's awesome bad-breath attack, and Colin O'Conner master-minded the gruesome face-split finisher, as well as the fist pound attacks.

In this clip, I animated the mini-game sequence of the big dude (Phlegyas) coming out of the water. The sequence starts with the hand and ends with the roar. For these mini-game sequences I get to control the camera as well. I also animated Phlegyas as he's attacking in the background (except for the final fire-breath attack).

All of Dante's slick second-to-second combat animation was handle by Tristan Sacramento. Every other animator gets to animate Dante if he/she is doing a paired attack with that animator's ememy character(s).

This is the same sequence as the one in the previous video. The audio from the game is more clear here, but the video capture might be too dark to see what's going on.

Things are busy of course, but so far I'm having a lot of fun on this project. Stay tuned for more vids and death-dealin' as they are released to the public!

Sunday, July 5, 2009

Dante's Inferno: First Gameplay Footage

Here's a first look at some in-game footage from Dante's Inferno, the game that our team's currently working on. Check out this full 20 minute interview as it shows a lot more gameplay footage than the shorter trailer.


Monday, June 8, 2009


If you have a PS3, buy this game!
  • Awesome character control. Incredible freedom of movement, esp. once you upgrade to the wire grind and power glide.
  • Great platforming moments.
  • I was never a fan of electricity powers...until this game! Satisfying powers and upgrades.
  • Pretty decent narrative (enough to keep me going).
  • Bottom line is the incredible feeling of being able to fluidly navigate through the city (something I was hoping Assassin's Creed would deliver...maybe in the second installment). In this game, I felt like I could grab onto anything that looked "grab-able".
  • 9+ rating in my book (haven't played one of those in a while).

Other honorable mentions that I've played recently:

Ninja Blade:
  • Didn't get the best reviews, but I dug it.
  • Play it for the ridiculously over the top quick-time events. I dug the boss battles too. Not a perfect game, but definitely entertaining (for me). Not for everyone (esp if you don't like quick-time events), but if you can enjoy some cheese sprinkled over some crazy action, give this game a go.
  • Definitely visceral. Repetive in some areas, but entertaining as a action slasher. Gotta love Wolvie's cyclone move and "psycho-crusher" drill (in the game).

Sunday, June 7, 2009

Camera Rig

Hello everyone, I'm coming off of vacation and heading back to work tomorrow...I figured I'd post something before things get busy again.

I found this shaker script a while back and decided to make a camera rig out of it. I find it useful for throwing in some quick camera shakes. Of course, if you have time, you should hand key a bit of the rotate channels as well.

  • Tilt the camera with the "up_CON" controller, the "tilt" attribute on "CAM_CON", or the Z rotate channel on the main controller.
  • "Zoom" attribute actually trucks the camera in closer (doesn't affect focal length). It was added out of necessity. There were times when we wanted to experiment with different versions of a shot--bring the camera in close or keep if out further.
  • "Frequency" regulates how fast the jitter is.
  • "Ampitude" regulates how big each shake is.
  • "Phase"--honestly, I've never use this.
  • "Flash"--one of my cheap tricks to get a screen flash.
  • Contrain the parent of "up_CON" or "aim_CON" if you want it to follow a target (I tend to not constrain, though...still experimenting).
  • "CAM_noise" is keyable. For lack of a better name, it's to layer in extra camera "noise".
  • Visiblity switch is found on "Master_VisibilityShape" node (select "CAM_CON" then look in channel box").


I found that it may be difficult to "undo" in Maya once you press play with the camera rig in your scene. This is due to how to the shake feature is set-up.

Here's my work around:
I toggle the "Shake" expression on and off, depending if I'm working on the camera or not.

Use this mel to turn it off:
  • expression -e -s "" -o noise_MD -ae 1 -uc all Shaker; print "Shake off!";
Use this mel to turn it on:
  • expression -e -s "noise_MD.input1X = (noiseX.outColorR -.5) *.2;\r\nnoise_MD.input1Y = (noiseY.outColorR -.5) *.2;\r\nnoise_MD.input1Z = (noiseZ.outColorR -.5) *.2;\r\n\r\nfloat $valeur = `getAttr (\"CAM_CON.frequency\")` *2;\r\nfloat $phase = `getAttr (\"CAM_CON.phase\")`;\r\n$valeur += $phase;\r\nsetKeyframe -v $phase -at \"time\" -t 0sec CAM_shaker;\r\nsetKeyframe -v $valeur -at \"time\" -t 4sec CAM_shaker;\r\n\r\nnoiseX.time = CAM_shaker.time + 5;\r\nnoiseY.time = CAM_shaker.time + 10;\r\nnoiseZ.time = CAM_shaker.time + 20;" -o noise_MD -ae 1 -uc all Shaker; print "Shake on!";

Make shelf buttons for these commands or do what I do and make them buttons on your Picker.

Have fun, but don't holler if you cant undo in Maya cause you forgot to turn the "Shake" expression off! I had to learn the hard way:)

Monday, May 4, 2009

Visceral Games

It's official--I'm no longer at E.A. Redwood Shores. I'm at Visceral Games--which is actually our new brand (just a name change). And as our new tag-line goes, "It's in our blood!"

Wednesday, April 8, 2009

Dragon Ping Pong

This was passed around at work today. Real or fake, it still looked too cool to not share.

More of the Dragon...

And Dragon...

YouTube of course.

Sunday, March 1, 2009

Rig Preferences

(click pic to download sample rig)

Every animator has his/ her own set of preferences when it comes to animation rigs. While it is true every animator can adapt to a given rig and produce good animation with it, I believe that a well laid out rig allows for a more streamlined workflow, thus creating the potential for more polish time.

Creating a rig that has enough control for the animator while not being overly complicated is definitely a balancing act. Here are three main categories I like to use as a checklist.


So to start, at the top of my list has to be…

  • Try to separate controllers as much as possible. In other words, minimize the overlapping of controllers so you’re not constantly selecting the wrong controller. When there’s too much overlap, you’re wasting time by constantly bobbin’ and weavin’ and tumblin’ around just to select a specific controller.
  • Controller shapes don’t need to be exactly centered to the joints they are driving. I’d move them (the cv’s) if it helps with separation.
  • Take the time to resize the controller to fit the body part of the character, esp. when using automated rigging scripts. (ie. Don’t create hand controllers that are the size of the torso or controllers that are imbedded in the geo.)
  • Color code controllers. I probably won’t remember that red means right side and blue means left, but colored controllers will further help with separation.
  • The standard yellow/red/blue scheme seems to work well for a wide range of textures.
  • I like fingers controllers a bit brighter (yellow) since they’re smaller and harder to see. Other “secondary” controllers could be light blue. Whatever you choose, keeping a little bit of consistency helps when you’re jumping from character to character in a pipeline.
  • I’d also stay away from bright green and white controllers. These just confuse me as to what’s currently selected.
  • Create controller shapes that are selectable from wide angles. In other words, try not to have controllers that can only be selected from the front or the back. Spine, neck, and shoulder controllers seems to be repeat-offenders.
  • A character GUI/ picker is good for selection “backup” (when a controller is hard to select in a specific pose). Also good for selection sets.
  • Picker could also be used for frequently used tools and matching scripts.
  • Picker to help with scenes containing multiple characters.

  • Boxes for the spine. I like fin-shaped boxes because I can quickly judge the rotation of one spine controller in relationship to the others. This makes it easier to keep the torso rotations clean. If circles are used for the spine, then a direction indicator for each controller would help. Speaking of spines, I’m plenty fine with only 2 spine controllers (in addition to the Root and the hip). 3 spines controllers are ok, but any more than that feels to cumbersome to animate. If deformation is a concern, have fewer controllers drive more joints.
  • For the neck, I’m fine with one controller.
  • A "halo" controller above the head feels nice and clean and is definitely separated from the neck controller.
  • I prefer the head controller to never follow the rotation of the neck. Local/global switching of the head could be connected to the spine instead.
  • Likewise, I like the arms controllers to never follow the rotation of the shoulders (clavicles). Have it follow the world or the spine.
  • The main pivot of foot controllers should be at the ankle imo. Pivoting on the heel could be handled as an attribute in the channel box. When the main pivot is at the heel, I feel like I’m constantly readjusting the translation of the feet everytime I rotate it (too much counter-animation).
  • IK’s oriented to the world-->meaning that if I translate an IK controller using “world” mode, only one channel should be affected. If this is not so, it’s a lot harder to make translation adjustments in the graphEditor.
  • I prefer elbows to not follow the clavicles (again too much counter-animation). It can follow the world or the spine instead.
  • For knees I always preferred to have them follow the feet when the feet are translated but now when they are rotated. I haven't really used the knee twist attribute in the past, but I’ve recently been seeing a lot of noFlip knee solutions. I’m actually pretty intrigued by it as I think it might be the way to go for knees from now on. I'll be experimenting with this.

  • Long attribute lists in the channel box should be grouped and separated with “empty” channels.
  • Rotation behavior of mirrored controllers should be checked. (ie. Rotating both clavicles in one channel should rotate them both up)
  • Rotation orders should be checked and be allowed for change, so that FKIK switching would still works.
  • Controlling fingers is always going to be somewhat tricky. A controller for every finger segment can get bit cumbersome to select. On the other hand, a long list of attributes in the channels box can also get a bit confusing. The method I find to be the best balance between control and speed is to have one controller at the base of each finger. Each finger controller would then have 2 attributes to curl the remaining segments. Sure you can’t bend every finger segment every which way for “smear” frames, but for games (where you have to turn anims around quicker), I think it’s plenty of control. Joel Ku introduced this to me a few years back and I’ve been loving this method ever since.

Next category...

  • Since different situations may call for different approaches, I think the key here is a quick and intuitive way for FKIK and space switching on the fly.
  • I prefer all local and global switches as keyable attributes on the controller itself. That way, I’m not wasting time trying to track the switch from a list of 50 attributes on a separate controller.
  • I also prefer only one controller per body part. I’d rather have one IK controller be switchable between local/ global space as opposed to multiple IK controllers for each space. Again it’s so I don’t have to track down that other controller when switching, not to mention the added clutter and worry about more visibility toggles.

Lastly, but just as important is…

  • A rig could have a gazillion controls to cover every possible situation, but if it’s too complicated and heavy and runs at a very low framerate, then polish time could still be compromised because accurately judging your animation in real-time is too difficult.
  • The balancing act here, I guess, is to know your production goals. (What’s the target, what’s the budget and timeline?) Controllers for uber-subtly may not be used if the budget doesn’t doesn’t allow time for them.
  • Proxy meshes, in addition to how connections are hooked up in a rig, can make dramatic impacts on how it runs in Maya when I hit that “play” button. Of course some characters will be more complex than others, but if I’m constantly making playblasts for every little change because my scene is running at 5 fps, even during the blocking stage, then two things will probably happen. I’ll have to spend more time on this anim to get the level of polish I’d like, or this anim will get done on time, but with less polish that I’d like.
  • Playblasts are definitely important for final polish. But if I have to playblast from the get-go, then there will ultimately be less polish time.

As for the face, I’ll just quickly mention that I am a fan of the Osipa-type interface—one that lets you quickly get the shapes you want but at the same time allows for layering in detail with “on-the-face” controllers if needed.

So to hopefully better illustrate some of the things I’ve been rambling about, I made a simple rig for everyone to play around with. If you're interested, download it here. I know no one really reads the “readme” files but try to at least glance through this one, there are features in the rig that may not be obvious.

And remember, in no way is the rig meant to be the super-rig (it’s not even fully complete). I’m sure any TD out there could look at the rig and find many ways to build it better. But there you have it. Again, these are just my own preferences. Feel free to add to this list or bring up counter arguments. I’m always looking for more efficient ways of doing things:)

Wednesday, January 28, 2009

Quick update


Hi everyone. I've been wanting to make a post about a few personal preferences when it comes to rigs, but I thought it might be easier to highlight points with an actual rig, instead of just notes. So inbetween work, the fam, and Street Fighter Remix, I think I've managed to (almost) complete a first pass at a new rig for y'all. I'll probably be able to share in a few weeks, in case anyone's interested.

Until then, I'll leave you with the following vids. A friend brought up 300 the other day and it reminded me of these:

WARNING: some mature content and possible spoilers