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 . . . 
http://www.tommasosanguigni.it/blog/?p=40

Monday, October 01, 2012

When should I add textures to a character?

Good question! (Actually, a reader, BMDela, asked me this. . . so I'm only partially taking credit)
The question was posed thusly:
"""
So, I've been looking for an answer to this question everywhere, and can't seem to find it.

At what point do materials/shaders enter the equation?

Do you put the materials on the master character/props/set, then reference the shaded character into the animation scene?

What's a good workflow for implementing a shading network?
"""

The correct answer is . . . wait for it. . . "It depends!"
Lame, I know, but it's the truth. There are ways to do things that are more 'pipeline' correct and ways that are a bit more user friendly. Some projects work better one way, some the other. So let's look at the two basic ways of doing things. . .

1. Adding shaders to the master files (let's say to the master model files):
Doing this is basically putting your shaders (and their assignment to surfaces) at the front of the pipeline. That is to say, you make your models, uv and texture them completely, then pass them on to rigging, etc. This would seem to be the easiest way to do things and sometimes it is. What are the pros/cons?
PROS: the texture artist only has to apply the shaders once (in theory) no matter how big the show is. Let's say you have a show with 3 characters. The texture artist hits each one and then it doesn't matter whether there are 5 shots or 500, it's the same amount of work for those characters (unless there are changes, which may or may not be a pain in the butt).
CONS: There can definitely be issues with the fact that now all of your shaders are referenced (until you get to the very end of the pipeline). . . but the main problem here is that in heavier scenes you're always pushing around all the textures. When I was animating recently on Skylanders 2, some of the scenes took 3-4 minutes to load, mostly because of the massive amounts of texture files we had to pull over the network. Let's say, as an animation lead touching a lot of shots, I open 20 shots/day. If each shot takes 1 extra minute to load, that's 20 minutes/day. There are 10 leads opening that many shots, so that's 200 min/day to pull textures (that's not counting the 20 other animators who may open 5 shots/day). So over one month, just the animation leads spend ~4000 minutes (or 60+ hours) JUST TO OPEN SHOTS! That's a lot of time/money. And it's not a crazy scenario depending on the shots/network/etc. Might even be conservative . . .

2. The alternative is to push the texturing until closer to the end of the pipeline (after animation):
 To be clear here, I'm not saying "don't create your textures until the end", I'm saying "don't assign your textures to the models until the end". So the texture artists would do the same thing as above, they'd just do it "offline" or in files that don't get pushed through rigging and animation. They would then export those textures into appropriate files that just have the textures in them. Then once things are animated, you can just import those textures and assign them to correct objects. Usually you'd want some textures in the master files, things like eyes and stuff that's involved with the rig, and maybe even apply basic color shaders so people can see what's up, but the heavy stuff stays out until after the animators are done.
PROS: Obviously the point here is that you don't have to push around hundred's of MB's of textures for each shot. Work can go much faster down the pipeline. You also avoid the annoying "doubling" of textures (if I reference 5 of the same plants, I end up with 5 copies of the same shader in my scene). You just import what's necessary. You're also doing the final assignments in context so you're making any fixes while you're actually in the scene.
CONS: Mainly that the work scales linearly. So more shots, more work. You can also get some surprises if you haven't seen the textures in action, and you'll see them with less time to fix them.

So the reality is that it depends . . . how heavy are your shots likely to be? How many of them are there? Are the textures integral to the animation or can the shots be animated without them? How rigorous is your pipeline? All theses questions will dictate which is the right way to go!

I've actually been pondering on scripting a system to keep track of what shader is applied to what mesh, etc so the texture artist could save out a file that would reapply the shaders later on down the pipeline automatically. Haven't gotten around to it yet. . . Does anything like this exist? (non-proprietary, obviously)

Anyways, hope that was helpful, let me know if there are any clever things I've missed!

Wednesday, August 15, 2012

Space Switching and Space Matching

I created a couple of new videos to talk about space switching and space matching. I think they're pretty self-explanatory, just going over the basics of what they are and some ways to set them up. Nothing too crazy, though the space matching one is a fair amount of python scripting (though again, nothing terribly hard if you're already using python).

But if you're into the more complicated bits, here are some links to info about them:
Charles Looker - http://charleslooker.wordpress.com/2012/02/25/multi-directional-constraints/
Hamish McKenzie - http://www.macaronikazoo.com/?page_id=413 (very illustrative, but be warned, some of his matrix math stuff used his own scripts to deal with the matrices, so it can be a bit confusing if you try to do it without installing his scripts first. But the principles are the same, I just use the API to do the matrix-y bits, which can be hella confusing in it's own right)
TD Matt - http://td-matt.blogspot.com/2010/12/broken-hierarchy-rig-and-space.html

Oh yeah, and the vids by Jeremy Ernst are here: https://vimeo.com/jernst. Good stuff!
And I'll say it just so you don't have to. . . My god am I long winded! Not sure how explaining space switching could possibly take that long. But what can you do? :)

Maya/Rigging: The basics of space switching from zeth willie on Vimeo.

Maya/Rigging: Space Matching from zeth willie on Vimeo.