Hello, I have been lurking these forums for a long time but hardly ever post. I have recently been doing a lot of soul searching and always find myself coming to the realization that when it comes to tech art I want to get into tools/shaders. I have some experience with rigging and scripting inside Maya. But every time I sit down to work on a rig to put a rigging reel together I get “side tracked” with trying to create tools to make my rigging process easier. I rarely actually finish the original task I set out to do, rigging wise. Now, I know some python and MEL. I don’t remember anything from the C++ courses I took 8 years ago. So, I guess it boils down to me wanting to focus seriously into tools programming and not sure where to actually…start? Would focusing in on python be something that would give me the ability to apply for tech art positions?

Also, when wanting to focus in on tools and shaders, what do you show off as a portfolio? Would I edit together a reel of some tools in action?

Idk if I would put tools and shaders into the same category. Both require different skillsets when it comes to the job. Tools is more about friendly user interfaces and understanding the people who will use the tools, where as shaders is more about complex math, performance, and art. Granted these jobs can change depending on the side of the studio and the specifics of the role, etc…

if your looking to get into tools, I’d just start watching everyones demo reel on TAO. Depends if you want to get into animation tools, (mirroring poses, saving poses, etc) or stand alone tools (xml/asset management), or shader editing systems, or whatever.

I’d say make a cool tool ,and make the shortest video you can that gets the point across.

for example: I’m in the process of making a video of all my photoshop tools, but I’m going to just have each tool demoed for 10-20 seconds, and cut to the next one. so i’ll have a 3 minute video with 15 of my tools all in one video. Not sure if this is the way to go, but I don’t think it really matters. I’m just trying to get the point across that I’ve done some things in photoshop.

Hope that answers some questions. I’m pretty new to this too, so maybe someone with more experience can give you a better answer.

My guess is if you start writing shaders, you’ll quickly write tools for shader authoring like you do for rigging. Like Shawn said, they are pretty different. It is coincidence that many TA’s are fluent with both (the shader authoring is an artefact from our histories as artists).

Just jump in and start making tools. Create a blog to post the code and screenshots/videos of the tools. You could make a reel but I’d much rather see some screenshots, explanations/motivations/concepts/etc, and ideally the code as well.

Then you just need to promote yourself so when a job opens up you can email a TA at that studio directly (or they’d contact you).

A reel is a really difficult format to use for selling your ability as a tools writer. What are you going to do, push a button then spend thirty seconds explaining what it changed? Exciting! Not. Some studios require them for job applications, so you may end up cutting one, but don’t bother if you don’t have to.

A website is a better format. Document your tool like you’re trying to sell it. Screenshots, feature list, short videos of the tool in action (if and only if it illuminates the point the way a still image does not), an FAQ. Treat the people looking over your website as if they were consumers of the tool. Explain what problem it solves and why they should use it. And don’t forget that a big part of being a technical artist is communication. Treat the quality of the write-ups about the tool with the same seriousness as the quality of the tool itself, because they’re every bit as much a part of your portfolio.

For shaders, a reel is perfectly appropriate. The surface qualities are made more apparent in motion.

Rob’s subtly trying to turn all TAs into tools programmers. I don’t agree that TAs write shaders because of some legacy status. I define a technical artist as someone who solves visual problems through the application of technology. Sometimes that tech doesn’t exist and we need to invent it. Most often the problems have a lot to do with workflow and enabling artists. But sometimes the problem gets framed, “We want it to look like <this> in game, and we don’t know how to make that happen.” Those problems don’t always break down into neat categories – problem A is solved by a workflow tool, problem B is solved by a shader. Sometimes you need to dip into several categories. And TAs are great at synthesizing solutions out of multiple techniques.

Now, I definitely don’t want to encourage you to split your focus too much. I agree that if you’re already interested and invested in tools, you should keep on that path and develop more expertise. And don’t think that you have to program shaders to be a TA. There are so many areas of expertise in our field that I highly doubt any of us here has mastered the entire TA spectrum. There are plenty of happy, employed TAs who have never learned any graphics programming. But just… don’t think that shader writing is a skill on its way out. It’s not. If you’re really interested in it it’s a totally viable skill to pursue.

Wow, thanks for all the awesome responses. I have always wanted to learn shaders, just never made time for it. I think it stemmed from when I first was learning UDK and saw the awesome stuff you could build in there with there shader GUI. I am going to focus on tools though because I bet Rob’s guess would pry be spot on without even going down that road to see.

I have a few small tools I have written for rigging purposes that I need to finalize and will hopefully get those put up over the next coming days.

My brother Ian is a musician. He plays drums, piano, and bass guitar. Years ago, he was in a band in Liverpool that included an extremely talented keyboard player named Charles. After one of their gigs, I told Charles how well I thought he’d played that night. Then I said that I’d love to be able to play keyboards that well. “No, you wouldn’t,” he responded. Taken aback, I insisted that I really would. “No,” he said. “You mean you like the idea of playing keyboards. If you’d love to play them, you’d be doing it.”

Sounds to me like you like the idea of shaders… but when it comes to tools you’re doing it. So that’s pretty clear!

And we totally ignored your question about C++/Python. Python’s great. It’s hugely popular, easy to learn, and you can use it in most DCC apps these days. If you’re interested in C++ you could make inroads there, but I’d be opportunistic rather than proactive, at least for now. It’s more about the problems you want to solve than the tool you use to solve them, anyway – if you can get the same result with Python or C++ but you’re already more comfortable with Python, you’ll be more successful in less time.

Second, I didn’t mean to say TAs only write shaders because of some legacy status. They don’t. They are great at writing shaders and I agree with your assessment for the most part. What I meant is that so many TA’s can write them because of legacy. Even those of us that are 100% into tools dev now, many of us can write shaders because it was one of the things we did early on. Didn’t mean to demean all TAs that write shaders.

Second, my data doesn’t match yours. I know very few artists who can write HLSL and most TAs I know that can learned it as TAs. But I don’t think either of us have big enough samples to settle the question. I suppose we could take a survey if either of us really care, but I’m content to simply have had a different experience.

I’m tempted to make some light jokes here but I’m actually concerned about the possibility of TAs becoming mostly tool developers. There used to be this huge divide between programmers and artists and TAs were scarce. Now that there’s more of us we’re serving our industry really well by bridging the gap. Drawing a line through the middle of the gap and saying, actually, TAs should be on only one side of this line, feels like a big step back to the bad old days.

Now, tools devs are also really valuable and scarce, so the more of those the better. I definitely don’t want to say that no TA should do that. And obviously almost every TA on here has a different set of skills. But I’m going to be pretty frustrated if, over time, all those skills shift to exclusively the T side. Encouraging every TA to drop the art part ignores an industry-wide need. Plus, I’d really like to hire some colleagues at some point who can do the A, too. We don’t have a lot and we’d like to have more.

So, just because I am slightly confused here. Are you saying that your concern is that TA’s are going to become glorified programmers? By that I mean simply a programmer with a special title. If that is what you mean, I can see what you are saying and don’t completely agree, but I am also no where near your experience level.

My draw and desire to be in tech art is from high school when I was taking programming classes and enjoying it but not finding it to be my true passion. So I started studying into the art side of game development. I didn’t excel at modeling or texturing. But once I was taught rigging and scripting I fell in love. Now, I could devote tons of time and get better at texturing and modeling. Honestly, some day I would love to. But, I don’t get the satisfaction from a finished model that I get from a working tool.

I truly hope this doesn’t come off as me trying to argue with you or anything remotely negative.