[QUOTE=Bharris;1901]I would like to begin working on projects more relevant to the game industry rather than the film industry.
[/QUOTE]
I would say to probably not take that sort of approach. There really isn’t a ton of divergence between a film and a game TD anymore. Take rigging for example, sure alot of game studios don’t export rigs to game, but they do need a way to get animation to the joints anyway. Don’t think in terms of the data, think in terms of artists. As a TA/TD, you are a service provider, and trust me, the last argument you want to have with a rabid animator is the one about why you as a TD think that they don’t need a certain rig feature because it isn’t supported in game or it ultimately doesn’t affect the exported data.:D:
Along those lines, I would say learn the theory more than the application if at all possible, or maybe it’s better to say learn the underlying application methods before learning specifics. Shaders are a great example, at the end of the day, diffuse lighting is still the dot product of a surface normal and a light vector, regardless of whether you’re typing dot(N,L) or diffuse(faceForward(normalize(N))). It’s going to be alot less taxing later on to try and implement crazy effects if you know the underlying math techniques rather than saying, “Well, i sorta know the code for this, let’s just try different operations on different variables until i get something that looks like what i want”. Scripting languages are another great example. Learning vanilla python first then learning maya python is easy, trying to learn python in the context of maya first then backporting that knowledge to vanilla python could bite you in the ass:x:
Anyway, enough ego-strokey ranting (i just like to pretend i know what i’m talking about from time to time:D:)! To address your specific questions:
Do I need to show that I can rig with few joints/blendshapes/SDKs?
Yes and no. You do want efficiency, but i think the key thing to think about is functionality, as stated above. Efficiency comes into play under the hood, ie you want your rigs to not bog down a scene, at the same time you want them to be simple for the animators, and clean enough for you as a TD to troubleshoot or iterate on the functionality. Some of my worst all nighters were having to go back through a crazy transform stack to get to one wrong thing and knowing i was going to have to rebuild the whole thing:x:
Do I need to show both python and mel scripting?
I’d say learn both. Mel is pretty simple so it shouldn’t take too long. If you have the time, learn basic OOP theory too, that definitely helps in the long run. Doesn’t hurt to have a grasp of stuff like .NET either, although that’s definitely not a requisite.
What types of tools are more practical in a game pipeline?
Anything that helps the artist produce better work faster with a minimal amount of wasted iterations.:D:
Do I need to show that my rigs are Motion Capture friendly?
I’d take it a step further and show that your rigs are just friendly to static animation data in general.
Is a Blendshape facial setup preferred over joints with a pose system?
You should learn how to do both, but the real hint there is figure out a way to make a system that’s friendly to either setup. . .takes a little bit of thinking, but it’s a fun experiment.
I know some of these are pretty vague, if you want some clarification or follow up on anything, feel free to post or PM me.