Friday, January 25, 2013

Rigging a shock absorber and so much more . . .

"So much more" might really be an overstatement. In fact, it is.
But there actually IS other stuff in there. As I mention in the vid, I was recently rigging a mechanical "tranformer-ish" guy and had some troubles with the model I got and thought it might be worth pointing out some of the way you could avoid the same issues. Things like how to avoid/deal with the skewing from uneven scaling etc. The shock absorber stuff is in there too :)
Here's the vid:

Maya/rigging: Setting up shock absorber and some notes on mechanical modeling from zeth willie on Vimeo.

Oh and btw, I'm an idiot because I wrote a bunch of code to zero out the rots and trans, then freeze the transforms, then reapply the rots and trans when, in fact, one line of code will do it (never really looked into the arguments for the "makeIdentity" command before. The "scale" flag will just freeze the scale attrs.):
cmds.makeIdentity("yourObject", a=True, s=True)
And of course you could just do it from the menu options for "Freeze Transforms". Geez. . .
But here's the gist of the code to make the single bone stretchy IK (at least it does the annoying parts for you):
import zbw_smallIKStretch as sik

Python append to path tool

Here is a little script that allows you to browse for and select paths to add to your sys.path list for python.
I generally don't keep my python scripts (at least the ones I write myself) in my scripts folder, I keep them in one of a couple "Git" folders that allow me to easily load/sync my scripts over GitHub so I can work on them on various computers (I suppose I could arrange things so that my scripts stay separate from all the other script in my scripts folder and point Git there, but I don't).
This works fine for me, but it's a bit a pain to have to keep pointing Maya there to look for my Python scripts. Up til I wrote this script I just wrote a little bit of python code in Maya to append to my sys.path and just copied that to the shelf. No problem. Unless I'm on another computer at home or at a studio. Still not a big deal, but I still have to put the scripts somewhere and point Maya there, and when I'm at a studio I often have stuff in a few places (desktop, folder on the desktop, etc). And I'm so lazy that I think it's a pain to grab the path name to add it to the "sys.path.append(pathName)" in Maya (especially on a Mac). So I wrote this.

Basically, it has two parts (the two tabs). The first part lets you browse for up to three paths and then add em with a click. It dummy checks that a) you've added something and b) what you've added is actually a path that exists.

The second tab is just a quick list of the paths that Maya is currently looking in, it refreshes once you've added new paths or you can manually refresh it if you've added paths elsewhere. Since I didn't want to make this window soooo big that it could catch any potential long path names, if you double click on a path in the "View Paths" tab, it will print that name in the script editor.

There's also the option in the menu bar to save out your entered paths (it will write a "zbw_appendPathSave.txt" file to your user prefs folder). You can then load it later to save some time (it will just overwrite itself if necessary) and it will reload the paths you've browsed for.

Here's a link to the script or it's in the NEW downloads section above. (note: slowly but surely I'll get the other scripts up there too)
Basically, I just drop this in my scripts folder (it's the only python script I keep there, except for stuff that might point Maya elsewhere) and run it from my shelf. Here's the code to do call the script (obviously python):

import zbw_appendPath

Hope it's useful to someone as lazy as me!

Shape node scaling tool

Here's a little thing that I made a while ago as a little hacked-together tool for some job I was working on. Eventually I added little bits until it ended up as this kind of done-ish version. (I know that's a real sales job, isn't it?:)
But it actually is pretty useful to me on a regular basis for everyday stuff, especially for scaling controls. The short description is that this grabs all of the components of each selected object (surfaces, curves and polys) and scales them. That is, your objects gets scaled without affecting the scale attributes or the transform node. 
The setup looks a bit confusing (and maybe it is), but there are a few things you can do. There are two ways to scale things, either drag the slider (which will automatically recenter itself. Kind of weird, but I felt it gave better sensitivity and still allowed me to scale things very large with a few pulls) or type a number and press "scale". When you use the slider, the value that you slid gets entered into the field, so you can repeat it on the same object by clicking the scale button, or use the same value for other objects. 

The stuff on the right is a bit more esoteric. What was happening was that I would scale a bunch of controls and then realize that I forgot to select one control. It was then tricky to repeat the same slider values, etc. So the top field on the right tracks the cumulative value change to the scales. So you can select a bunch of objects, change the values arbitrarily and this will keep track of the changes from where you started. You can then copy down that number and enter it into the text field if you need to grab another object and match it, though this will then change your tracked value. To get around that, you can "reset" the tracked value back to 100% once you select a new object(s). Similarly, if you do a bunch of scaling it can be tough to get back to the original value without hitting undo a bunch of times. So if you've tracked your changes (by starting with a "change" value of 100, via "reset") you can get back to the original state with the "orig" button (it will just figure out what you need to get back to 100% scale and multiply by that). This change will then be reflected in the "scale %" field if you want to apply it to something else (or just know what the number is). 

Whew. Sounds like a lot for a simple tool, but I feel like maybe the naming, etc isn't super clear. Maybe at some point I'll put a "help" menu in there or something. . . 
Hope it's useful! or you can find it on the shiny, new download page (there's now a button to take you there up at the top) . . .
import zbw_shapeScale

Some tidbits . . .

  1. First of all, the blog has a new look! Soooo. . . there's that.
  2. While we're on the topic, I don't really know much about blogs, per se, and I'm not really interested in learning too much about it (or rather I don't have room in my brain for it). Having said that, if there's anything that you might find useful here in terms of blog setup, or that you like elsewhere, let me know, while I'm thinking about it. I've already set up some stuff to show code a bit better and am in the process of setting up a download page to help you find any scripts and such to download more easily/conveniently. But if there's something else out there I'm interested in hearing about it (as long as it's relatively easy for me to implement:) . . .
  3. Secondly, I saw a demo of some pre-alpha stuff that Raf and his team at Anzovin Studios are working on at the NYC-Maya Users Group meeting Wed night. Very cool stuff. Here's a link to their site:
  4. Finally, while we're on the topic, I finally made it to my first Maya User Group meeting. It was fun! Steve Mann did a great job of getting interesting presenters and creating a good atmosphere (there was pizza, beverages, prizes, etc) If you're in NYC, check it out for next time:
  5. For those doing VFX or photography, there's  a new book out by Christian Bloch, The HDRI Handbook 2.0. Heard nothing but rave reviews (by some pretty savvy people). Just ordered mine, even though I don't do a ton of VFX work. Check it out: and pass it along.

Wednesday, January 16, 2013

Fixin that shoulder geo . . .

Here's a relatively quick video where I go over a technique I pulled from a Bay Raitt modeling time-lapse video like 10 years ago (vid is here). Basically, the idea is that to get more natural edge flow in the shoulder area, you just make a slight adjustment to the first extrusion from the torso which gives you a more natural angle to then extrude the rest of the arm. This helps a) make it more likely you'll model your arm at 45 deg angle, which I prefer to a t-pose when possible and b) help dictate the direction the edge flow wants to naturally travel.
As soon as I posted this on Vimeo, a fella named Ike commented (which I totally appreciate, btw) that maybe it sounded like I was bashing the idea that one should ever build a shoulder in the "tube" method, just extruding out of the torso in a straight line, and that, in fact, plenty of people model in this way and that it often works out (he gives some examples of his experience at The Mill and on Planet 51). To be clear, I totally agree with him! There a bunch of reasons why someone would model in a manner other than I'm proposing here. . . I've seen VERY senior and smart people pretty much advocating for a more "tube-like" approach. Some of the reasons they have mentioned (and I'd reprint the threads, but it was on a private message board and I don't feel like asking for permission to reprint all the stuff verbatim) include:
  • more even distribution of the geo makes it much easier to deal with driving the skin via other influences (like muscles layers, fat layers, etc)
  • more even distribution can make it easier to weight the skin sometimes
  • more even distribution also makes it easier to retopo if you have to later on.
  • sometimes the model just WANTS to be that way!
(note that often people advocating this work are in bigger shops, or have much more robust methodology for dealing with specific kinds of geo. Not always but often.)
Totally appreciate all of those reasons and wouldn't presume to argue with them. . . A good example is the clothing someone is wearing. . . obviously it doesn't make a ton of sense to model an edgeflow based on musculature when the character is wearing a heavy coat:) Despite the fact that I probably sounded more dogmatic in the vid than I intended to, my main point stands, in that you definitely want to look at reference for the way something is intended to move. For example, if you look at a man's blazer or tailored jacket, try to lay it out flat and put the sleeves in a T-pose. They probably won't do that, because that's not the way your arm naturally wants to move, hence the clothes aren't made that way! So while the edge flow would obviously be different than that of a muscly shoulder, it also wouldn't be a straight extrusion from the torso, either. . .
Also would add:
  • I'm, at least in part, concerned with passing info to my students, many of whom are learning about these things for the first time. The shoulder is a place on their models that frequently goes awry and this concept at least gives em a place to start. . .
  • I also work mostly freelance on commercial in NYC, often in smaller shops, and I often (maybe 20% of the time?) see geo that is actively harmful to my ability to rig a character:) So I feel like one is less likely to go wrong following edgeflow than one is just ignoring it.
  • Looking back, I have had plenty of good experiences with different styles of geo. Just wanted to say that too. . .
Also here's a link for some examples of different styles of modeling the shoulder area. ..
Enough about that! here's the vid:
Maya/Rigging/Modeling: Tip for creating better shoulder edgeflow from zeth willie on Vimeo.

Saturday, January 12, 2013

Why so many master controls?

Been asked this quite a few times when I've shown my classes some rigs. Seems easier to do a quick vid and point people here. (this is another one that's been sitting on my computer for months that I forgot to post)
I usually put my rigs under multiple levels of master controls (both for chars and props) and the main reason is that it seems easier to me to default to doing that, than to have to go back and add more controls when an animator wants to do something crazy like add something to a motion path and still retain some type of control. I mention a few other circumstances where this is useful, but to be honest, it just seems like common sense to me and makes me grumpy.
So get off my lawn.

Maya/Rigging: Using multiple Master Controls from zeth willie on Vimeo.

Friday, January 11, 2013

The basics of O.O.P. in Maya/Python

I was thinking about calling this post "O.O.P. I did it again!", but then I realized that most people in 3D nowadays are too young to remember who Britanny Spears was (you bastards). . .Made this video (along with a couple of others) a few months ago, but never got around to posting it. Just got really busy and/or forgot.
For those that don't know,  OOP refers to Object Oriented Programming.This is just a basic overview of what that is and how you can start thinking about it in Maya using Python. It's something that was a bit confusing to me when I was first learning Python, some of it still is a little bit . . .
I really have no idea whether this video even makes any sense (in terms of it being a useful/illustrative thing to watch).
Here's a description of a particular type of person:
"I work in Maya and know a little about programming, probably MEL and maybe some Python, and also write enough code to care about digging deeper, but definitely not accomplished enough in Python (or any other OO language) to the point when a discussion of classes seems rudimentary."
If that describes you, then you're who I made this for! I certainly hope both of you enjoy it.

(p.s. I was going to make a venn diagram for that, but I feel like Randall Munroe/xkcd should be the only person in the world allowed to make those anymore. And while we're on the topic, this is my new favorite site. If you're even a little bit of a nerd, you must read them all.)

Here's the vid:

Maya/Python: The basics of using Classes and Obj. Oriented Progamming in Maya/Python from zeth willie on Vimeo.

Thursday, January 10, 2013

One more FINAL thing about the autoswim fishy . . .

Since a few people have asked about the sine function and such involved here based on this, just wanted to point out that Tomasso let me know about a post he did re: some of the mathy madness involved in changing the periodicity of the sine function on the fly. Thanks Tomasso!
And as I suspected, it's way more than I'm willing to deal with . . .