So I’m a student that is graduating this year and looking to try and make myself an asset to a company/ the industry. Lately I’ve been finding that my skill set, while kind of diverse may not be including some very needed things to call myself a Tech Artist.
I’ve learned to code in C++/C# 4.0/ WPF 4.5/ Direct X/ (starting on some)OpenGL already and have a list of:
MEL,
Python,
MaxScript
so far for things I seem to be lacking that most TA’s know/use quite regularly. I’ve been told by my teachers obviously “Why don’t you have more scripts/tools to show you’re a Tech Artist?” which unfortunately I’ve had to say because I haven’t had time between learning the other languages, doing school work etc to learn them and B ) they haven’t taught me them either to make the scripts/tools (kind of funny but I digress)
So among those languages, is there anything else that as a “Generalist” TA (not sure yet what exactly I would want to specialize in, other than making people’s jobs/lives easier) I should know quite well or be at least looking into?
Thanks ahead of time for any help in steering me in the right direction.
I am more interested in what problems you solved, why you solved them and how. Not what languages you know.
It is good to show you got the programming way of thinking, but for me a technical artist is not only programming.
When solving a problem or serving a need, you need a foundation of knowledge that can be used as a safety net to reflection on for finding the solution. The challenge is to translate your solution to other people to understand. Because you might find a solution, but it does not mean this solution is the one where people feel comfortable with or maybe even introduce too many new problems.
So when you would show a script as the execution of a solution you found, dont forget to be able to show the whole process on how you found this solution and so on …
In order of importance, TA languages are: Python, C#, and… everything else. Mxs/Mel are useful for their specific packages (mxs particularly - mel is basically a legacy language now). C++ is more of a ‘real programmer’ language - it’s like an Italian sports car - fast and powerful and prone to maintenance problems; most production tools are written in C# or Python for ease of maintenance and expansion (and lack of memory management bugs). You might want to learn Javascript – ick! – because a lot of tools development in the future is going to be web based (and because MS is deprecating WPF in favor of HTML5 with Javascript) but that’s a future-proofing thing rather than a today thing.
Beyond that the real requirement is a very thorough knowledge of your chosen tool(s) - you need to get past the usual stuff into the way things work under the the hood - being a TA means you need to be the one who spots the file with 5000 unused scriptNodes or the one with hundreds of slight variations on the same multi-sub material, or being the person who spots the missing plug connection between an angleBetween node and an expression, or knowing how to batch render files from the command line. You need to be the person who knows how to set up a spline IK that won’t flip or use a TCB controller correctly. You have to cultivate the stubbornness, curiosity, and patience to work through weird edge cases and bugs (or worse, ‘features’ that work but work in ways artists hate) so you can figure out how to fix them. This takes a lot of time just making stuff in the packages - poking at features you don’t know, trying to grasp the logic of the way the controls and options work, and seeing how you can hijack different functions to do what you want.
Spend as much time as you can actually using the tools, learning what stinks and needs to be worked around and then finding ways to work around it for yourself. It also helps if you push yourself on the art side a bit: you may not be competitive with the zbrush monkeys and dedicated performer-animators, but you should be able to see why out-of-the-box features don’t do what needs to be done artistically if you want to really help artists out. Plus, having a decent looking portfolio is a huge help in your negotiations when you’re talking to artists - they respect people with good visual credentials.
… and learn enough 3d math to be at least dangerous. Eventually you’ll need to know matrices, vector and scalar products, and trigonometry.
If there’s a few things I wish TAs would know then this:
how to document code and workflows properly. The best script is useless if it cannot be maintained, or if we have to read it all over again to understand it.
actual art production knowledge. You need to know what people do in order the effectively help them! If you don’t have that - what sets you apart from a regular programmer (one who does not aspire to be a TA)?
if you have no such knowledge, sit down and create some art. It’s not about having production ready results, but about understanding the workflow and challenges.
modular and re-use oriented thinking. Apply this thinking to anything you produce - is there a chance that this tool, library, substance, houdini graph, etc. can be re-used?
writing simple and readable code, rather than the fastest possible. (and unless you calculate some heavy graphical stuff fastest doesn’t matter to most users anyway)
look up human interaction and UI design, if you plan to create tools for users. Rejection and adoption of tools and workflows can be a real problem.
have a basic idea about databases. You will work with them one day or the other (or make use of the awesome SQLite database!)
pick up some books about good programming standards regarding robust, re-usable and maintainable code (everyone in the team will thank you for it! )
get into the habit of planning your work. TA work can be very independent, and sometimes we feel like rushing ahead, starting to code right away. Learn to resist that. Learn to make a plan, draft up basic requirements. Think about the organization (modules, classes, re-use) of your scripts before writing them.
learn how to learn - get your research tools ready, like favorite websites (TAO.org, stackoverflow, polycount wiki), have some good books at hand. Often you need to be able to evaluate other people’s solutions and designs and judge if they are applicable to your situations. You also need to be able to look up information quickly and be able to narrow down on a subject, that applies to your problem at hand. The exciting thing about being a TA: never gets boring - there’s always new stuff (to be researched and learned).
Nysuatro also said it right here: Problem solving is key. That’s why I feel that knowing pipelines and actual art production workflows is so important. You will use your programming knowledge to offer solution for art production problems of which the artists themselves couldn’t even think of! (because they have no idea what you can achieve with programming!). But it you have no idea about what the artists do… how will you get the idea of how to tackle the issue?
The idea is that you may work in a team (if not, think about the poor guy who might replace you one day when you move up to a more awesome job - he will thank you for it and praise you!). If they can use/re-use/maintain your work easily, then the whole organisation becomes so much more flexible. Instead of us having to hunt down that TA who wrote that one convoluted MEL script nobody understands we can have other team members maintain code. Or we have more than 1 TA develop a tool at the same time!
Almost none of the skills I mention are deep skills, because it’s fairly easy to grab a Python book and get into it if you have the right mindset. It’s the good habits that are hard to stick to, and that set really good TAs apart from mediocre ones.
Some pretty interesting things. Thanks a lot for the replies so far, I really appreciate it.
Some of the things I do feel I am already doing (but of course not in a company context so never know how well I guess) but others are definitely some things I will have to look into to make better habits of
wow, this thread is full of awesome info. To echo what’s already been said, you gota know the tools (maya, max, photoshop) that the artists use. Not necessarily the art side of thing, but from the tech side, how does the dope sheet work with the animation timeline, does the script editor have access to this other component, basically is there a way we can attack a problem from the programming side of things to make it faster. Junior tech art positions are rare, but they do come along. But you need to be able to prove that you can solve problems. Having a website with 5 or 6 projects will help propel you into a job. And listen to the advice above. I’d say, stop with the c++, and learn python like the back of your hand. Make some cool maya solutions, and don’t use the excuse of they haven’t taught you how to do it. As a tech artist all you will be doing is teaching yourself something new every day. There is a lot to cover, and it takes time, but you gota put in the effort. The online resources are incredible. you can probably find a video of how to make a maya script on youtube in 2 minutes. Good luck!
Alot of this is so good. To help with your problem solving skills it doesn’t hurt to come at things from you artist side as well. Spending some time to really understand how the people who will be using your tools work by asking them how they want to work, will simplify your human interaction and UI design to what they need. Listening is a key skill.
And in that spare time you haven’t spent, pick up an art of some nature. Getting your feet wet with animation, modeling, or surfacing to that perfectionist artist level will also give you a leg up and allow you to think about tools and pipelines for your users. Many of the best TAs I know came from art roles where they just got frustrated when they couldn’t do what they wanted with their toolset.
)