Hody!
I am a full time 3D programmer looking into changing its position as technical artist.
Anyone who have taken that road before and has a story to tell about ;
I’d be very interested in hearing.
Yours truly,
B
If you want to get farther away from programming, tech art is a wide field, and different in every company. So much falls under tech art, depending whom you ask: tools coding, engine specialist/programming, FX, rigging, simulation, rendering, pipeline engineering, tools support,…
But we had a few people here coming from programming and there have been some challenges when putting them on to tools coding. We use Python, so getting them into a Pythonic mindset wasn’t easy. We would often get Python programs which read and were structured pretty much like C programs and didn’t feel very Pythonic. They also suggested to do everything in C, which was natural since they knew the language, but that didn’t work for us since we wanted anything not time critical in Python because other TAs cannot read C and we don’t feel like re-compiling tools whenever we want to change something. Faster iteration times, handling multiple projects and tasks at once was also something some people struggled with. Another issue was that many programmers weren’t really useful for writing every day modeling/animation/etc tools because they were unfamiliar with the art workflow - I recommend that if you want to get into tools development you should know the workflow of your “clients” (i.e the artists). Otherwise its like designing a car without having ever driven (in) one. Otherwise you should work together with someone who knows the workflow and tech. Also they had to learn to keep their eyes open and point out faults in workflows and tech on their own. Many expected to be just told their assignment and then just work in the confines of that assignment. But a real TA should be alert and raise issues when he sees them. You see something that doesn’t look quite right? Tell somebody - ask somebody!
Also we’re often asked to improve workflows with our tools and “come up with clever solutions” (as if that were so easy). Obviously knowing what people do allows you to make connections and then use your programming skills to offer the perfect solution. If you’re going to create workflow tools, just learn some Max or Maya and let the inner artist have fun. You’ll soon enough stumble over really annoying stuff that could need some improvement. It’s not learning about making great art, it’s about putting yourself into the artist’s shoes. Also, if you go the tools route, read up on usability issues and UI design.
Then finally, unless you end up as hardcore C++ plugin developer, soak up every information that is related to what you do - some networking, some databases, some windows user management skills, revision control skills, and skills how to write user documentation. Ideally you want to be a swiss army knife with a good specialization (e.g. coding in your case).
Thank you RobertKist!
I appreciate the time you put into summarizing a very complexe situation like this.
From all the perspective to it you name (tools coding, engine specialist/programming, FX, rigging, simulation, rendering, pipeline engineering, tools support)
What tools are involved in the rendering layer? And what do rendering specialists have for assets?
all the Best
B
Ya I find to do tech art it really helps to have some background in envirment art or character art. But of tech art is being able to see problems the artists are having your self or be able to effectly communicate with them about pipeline and tools issues.
Here’s a few of the things I always tell programmers when they get interested in TA work.
-
It’s a service business. Learn what your customers do and how they like to work. Sometimes they need to be nudged into new ways of working, but a lot of the time it’s more important to see things from their perspective and provide them what they need. Theoretical beauty, computing efficiency, and correct engineering often take second seat to just accomodating user requests.
-
You need to learn the language. It’s important to understand how artists communicate and how they envision their jobs. Being able to translate between artist-speak and programmer speak is one of the keys to your value as a TA. This doesn’t mean you have to be a working artists to be a good TA - but things like art history and a good understanding of how artists do critiques are as important as being up to date on the latest plugins or programming fads. It will also be a lot easier to succeed as a TA if you are at capable of doing some production quality art – rightly or wrongly, artists tend not to respect the opinions of people with no visual skills.
-
Nothing ever works. Pipelines and processes are never nailed down; everything is subject to changes of direction at the last minute. That means your code needs to be flexible and modular and easy to adapt – more than it needs to be fast or elegant.
-
Autodesk is your enemy
You’ll spend more time working around the quirks, inconsistencies, and ancient bugs in Max and Maya than any other single thing you do. No matter how good your own code is, stupid crap from ADSK (or other vendors) is your # 1 source of problems. So you need to spend a LOT of time with the art packages in order to know when they don’t work as advertised and how to work around them. Pick up Max or Maya at home and play with it, even the parts your team doesn’t use. Knowing the package inside and out is a key TA skill.
Agreed 100% Theodox
Alongside of just understanding artist needs and wants, it also really important to be learn how to bridge the communication gap between the artists and engineers (coming from games here). Sometimes there’s something an engine, tool, program just needs done in a specific way and having the ability empathize with both groups and getting them to work together well is a skill in its own. Translating artist speak to engineer speak, and vice versa is a big chunk of my job.
Little off topic, but about becoming a tech artist does everyone think a good understanding of the rigging and animation workflow is important?
I came from envirment art so have strong skills in that workflow, in shaders, effects and tool creation in Maya including custom file translators. But know very little about rigging and I see most tech artists with lots of rigging tools in there portfolios.
So is it realistic to work in tech art with my experience mostly in tools and shaders?
Tech art too is becoming specialized. We have people with focus on pipelines, engines, rigging&animation. The pipeline guy doesn’t have much rigging knowledge, but he has to be able to work together and understand the rigging TDs concerns. Don’t spread yourself out too thin but make sure you can talk to other people in your field.
In big companies there are at least 3 main specializations you’ll run into. There’s a lot of overlap on the practical side (DCC experience, similar scripting languages, general aptitude for problem solving and so on) but the day-to-day work is quite different.
Pipeline specialists focus on generic data management and transfer. Sometimes that’s file formats and import/export pathways, sometimes is things like file metadata or databases management or doing procedural management of big data sets. This is often very close in spirit and application to traditional tools programming; the main difference being that the TA version is more focused on integration with DCC tools and artists workflows.
Animation specialists do a lot of rigging, but frequently also do things like managing animation state machines or helping design processes for special animation tasks like multi-character animations. Mocap management and retargeting is another common animation specialty. Rarer but not too exotic are technical animation - ranging from managing simulations (cloth, physics, etc) to doing procedural animation with expressions or in-engine.
Shader / Effects specialists overlap a lot with traditional effects and shader artists – given the nature of those jobs the line between ‘producton artist’ and ‘technical artist’ is very fuzzy.
In general, you’ll find that small companies need people who can cover more than one area simply because they don’t have enough people to go deep. OTOH bigger companies like to have people who are reliable resources in a predictable area – even if that may mean people have a less interesting range of duties. Part of figuring out how to specialize yourself is knowing your preference for breadth vs depth, and also whether you prefer big teams to small ones.
True, but even though every TA has their responsibilities, we tend to help each others out when there is too much work pressure.
So being able to learn fast from others TA specialty and jump in is always good 