Becoming TA as a 3D Artist now studying Software Engineering

[Maxine]

Just a few questions regarding career advice!
Quick introduction, I’ve been doing 3D for around 6-ish years now. Mostly through self learning, but also an internship and a few freelance jobs. Just recently have I started studying software engineering.
Technical Art is such a broad field that trying to identify what to learn has been incredibly difficult. But from the descriptions I have read, it seems to fit my way of thinking and the position I naturally put myself in projects. My study is mostly independent-studying.

The tool development and pipeline side seem the most interesting to me. I want to help make artists lives easier by using my knowledge of code and understanding the inconveniences the artists face. What would the general advice be for someone like me to grow into a useful tech artist?

• What is a good starting point for getting into tech art and getting the learning ball rolling?
• Are there good sources on what professional tech artists are doing?
• Is there a place to find portfolios of tech artists so I can compare myself and get an idea of the skills they use?
• What fundamental skills would be best to work on, early on?
• How flexible is a technical artist between games and film?
• What are some good projects to do for learning? What kind of projects are nice to show off in a portfolio?
• Am I even asking the right questions?

Whenever I look up technical art, or related terms, I find a lot of professionals who make Substance Materials and do a bit of Houdini on the side. I can’t find much about pipeline and tool development. Finding resources has been difficult, so I am trying to look for all the pointers I can get!

I understand this is quite a lot to ask. Having done 3D for so long, (6 years may not be long to some, but being only 20, it’s quite a chunk of my life.) it feels weird to start at the bottom again without a clear concrete vision.

[BenWall]

Hey there,
CG generalist and supervisor doing a lot of TD work here:

What is a good starting point for getting into tech art and getting the learning ball rolling? What fundamental skills would be best to work on, early on?

The most important skill is coding. You need to know how to write modules, class etc, most of the time in Python.
As you already have an experience with CG, you can start by:

• trying out your favorite DCC api: maya.cmds, nuke python… The idea there is to understand how you can do everything without the ui, basically.
• describing cg productions pipelines (how do you create an asset? Do you split the work in different tasks? Etc)

Are there good sources on what professional tech artists are doing?

Pretty hard to say, as every company (and every projects) has different needs.
In my eyes there are two main types of TA jobs: technical directors, who do high end CG stuff that artists can’t do because coding is needed, and Data manager, which are more on the pipeline side.

What are some good projects to do for learning? What kind of projects are nice to show off in a portfolio?

Create some tools for artists, preferably with UI.
As you already know CG, think of a problem you had doing some cg work (something which needed a lot of mindless repetitive tasks maybe?) and try to think of a solution.

[Maxine]

Thanks for your reply!

The most important skill is coding. You need to know how to write modules, class etc, most of the time in Python.

Yeah I did hear a lot on python. Currently I’m working mostly with C++, C#, Java etc. But Python is definitively something I should become very good with.
I’ll have a play around with maya commands! That sounds like a really good idea.

Create some tools for artists, preferably with UI.
As you already know CG, think of a problem you had doing some cg work (something which needed a lot of mindless repetitive tasks maybe?) and try to think of a solution.

I can think of a couple annoying steps. I’ll try this out! I have done some UI work for native and web applications through my study so I’ve got no excuses.

I think I’ve got enough pointers to start making progress! Thank you.

[bob.w]

@Maxine

The most important skill is coding. You need to know how to write modules, class etc, most of the time in Python.

I’d push back on this juts a bit.
I’d say a technical artists’ most import skill is communication. You need to be able to talk to your art team, in their language, and really have an understanding of how they work.

After that though, yes coding is incredibly useful, and python is still the primary language of tech-art. (Though C++ and C# etc… will serve you well)

As for getting started, if you’re already part of a team somewhere, go and ask them what they consider tedious, watch them work, look for things that could be made simpler, or faster with a little bit of automation. If however you are not part of a team somewhere, then I would recommend working through the standard workflow of getting art from one package into another, and see what annoys you about the process, and consider ways that the pipeline could be improved for your own benefit.

[ak_eric]

Hey Maxine, all great questions.

I’d start by narrowing down your scope by film, or games. Both have techart, but each of those branch out into their own subdisciplines. I work in games, so I’ll speak to that.

At this point in gamedev, techart is a huge field that can encompass just about anything. For example, I work with (or have worked with) multiple techartists, that each have their own specalities:

• Focus on rigging, skinning, ‘deforming asset pipelines’ (props, characters, vehicles, weapons, etc), animation tools (usually in a specific DCC app, like Max, Maya, Mobu): I call this ‘Character Tech Art’.
• Focus on in-engine lighting support and tools: Lighting techart.
• Focus on runtime material development, like 'master material creation in Unreal, usually with crossover into Substance : Material techart. Not to be confused with the material artists who utilize these materials, in the same way animators utilize rigs.
• Dealing with ‘environment’ (aka ‘static’) asset creation (in DCC apps), and runtime integration / performance optimization : Environment techart. Often with a heavy crossover into materials.
• Helping the FX team with back in tools/tech/etc : FX techart. Sometimes crossover into Houdini.
• Helping producers make spreadsheets : Production techart (ok, I’m joking on this one).

It’s worth noting nothing above is law: Just how I’ve encountered it. Various studios may have different responsibility maps in the techart space. Nothing right/wrong, just the flavor they use.

From my experience, a techartist is someone that both enjoys the technicalities of a given art-discipline, then deep dives into how to help that team do better through new tools and tech. It could all be on the DCC app side, all on the engine side, or it could be a combination of the two.

So you have to ask yourself: What ‘type’ of techart do you want to focus on? Since at any larger studio there are definitely areas of focus.

Some of this is very scripting/programming focused. On games, in my experience, this is predominantly Python, since all major DCC apps (Maya, Max, Houdini, Mobu) support it, plus engine like Unreal.
However, maybe as a material techartist you don’t need to script, since you can do all your work via Blueprint in Unreal? Regardlss, I always encourage every techartist to learn scripting (specifically Python), it will only make you better at your job = better job security & better pay.

As others have said, ultimately, it’s the joy of problem solving that will drive you. Paired with clear communication skills to truly understand the problem the consumer is expressing: Sometimes what they think the problem is really isn’t the problem: Make sure your actually fixing what needs fixed

I encourage you on your techart journey! I’ve been doing it ‘a while now’, and love it, best job in the world.

[Maxine]

Hi ak_eric! Thanks for your reply.

I’ll likely head into games, as that is the industry I understand a lot better.

So you have to ask yourself: What ‘type’ of techart do you want to focus on? Since at any larger studio there are definitely areas of focus.

This is such a difficult question to ask myself. I have been deep diving into development, writing mostly C++ and C# applications and trying to understand modern OpenGL. I’ve met techartists who do mostly coding, and techartists who do mostly art.

An example I saw a long while ago on a discord community, was someone who made a procedural city generator inside of Maya. Where you could add and remove parts, easily tell the system how to implement details, and let the script do all the placement work. Or, tools where artists can drag a slider and magically buildings generate according to the length needed for the level. This is the kind of wizardry I want to master. I suppose this would be in the /environment techart/ category?

I encourage you on your techart journey! I’ve been doing it ‘a while now’, and love it, best job in the world.

It does seem a lot of fun! I’ll make sure to work hard so your kind words of encouragement will not be wasted. c:

[ak_eric]

@Maxine

Or, tools where artists can drag a slider and magically buildings generate according to the length needed for the level. This is the kind of wizardry I want to master. I suppose this would be in the /environment techart/ category?

In my head yes, or at least it’s something that matches : As an example, while I have historically focused on the character side of techart in my career, I help author environment tools whenever needed. Having an area of focus is by no means limiting. Really, it comes down to having a firm understanding of how programming works, 3d graphics work, game dev works, and (in this example) Maya works.

And it sounds like you have a great foundation with all your OpenGL / C++ & C# stuff : You can definitely leverage the C++/OpenGL in Maya (and other apps) by writing plugins : Years back Maya exposed their C++ API to Python (and a few years later created the Evaluation Graph, a multi-threaded update to the venerable Dependency Graph), but there’s still places where c++ excels there, and mostly that’s in nodal-based performance and ‘locator’ (as the Maya term goes) node drawing (since that code is OpenGL based): If you’re authoring a new ‘command’, then there’s no reason (for the most part) you shouldn’t do it in Python. But since Python has it’s GIL, it only runs single threaded, while C++ can run multithreaded: Because of that, if you want to write new node types in Maya that will be evaluated per-frame during anim playback, authoring them via Python would be a perf hit as all your threads collapse while that one python call is executed, vs C++ that will distribute things appropriately.

It sounds like you already have a good project for yourself (procedural city generator) : Go make that in Maya with a snazzy UI : nice techart portfolio piece.