Technical art direction

Wisdom from Deathrey

Art direction is about art. Your primary responsibility is making things look good. It is a privilege to be an art director, and it is wrong to place artistic excellence secondary to technical requirements. Deathrey put it in words really well:

[…] And as for art, there is a growing trend of favoring tech over results. For vfx artists, it is important to understand the effect, feel it, and communicate it to end user. How? It does not matter, as long as you stay with constraints of the tools you have and performance consideration. Being any kind of savvy with shaders, for example, is a plus, but never a substitute for that primary responsibility. I see this trend in action on routine basis these days. An artist favored solving art problem with tech, such as making a complex material to blend enormous number of textures. Thing is, that it is actually worse, than not having great art because now they have not great and slow art. Instead, they should have focused on achieving result, but the way to it was prioritized over goal itself. Those who let go of these constraints, start improving swiftly. Easy availability of learning material and accessible tools, such as graph based editors have really contributed to it. It creates false sense of compulsion to use them as much as possible, even when there is no objective grounds to do so.

More wisdom from Deathrey

(about doing water in a game) …the simplest example is foam level is stored in vertex color. Either you paint those in manually, or procedurally, it does not matter.

A lot of modern inexperienced tech artists fall into a trap of developing an amazing runtime solutions for this kind of thing (DFAO shader implementation), but they only have one thing in common; they’re slow. Them reducing production time is not implied. Improving visuals is not implied. Reducing package size is not implied. But being slow is almost guaranteed.

General approach to tech art problems

The quad of tech art problems

occurrences (high) (low)
task complexity (high) #1 #2
(low) #3 #4

We can generally place any technical art problem in the above schema and go from there accordingly.

Environment art or foliage or lighting is a #1. It happens a lot in games and is also fairly complex. So it required people to work on pipelines, tools, documentation.

A boss monster is a #2. It is very complex but only happens once. So what you need is a small team of specialists who make it work. No need for teams and documentation and pipelines.

Exporting and importing assets is a #3. It’s something you want to automate as soon as possible, so no more manual time is spent on it.

Anything that’s a number #4 you just ignore. People will figure it out by themselves. These are mostly in-the-minute requests for trivial stuff.

Iteration on tech art problems

Step 1: Solve the problem by any means necessary.

Step 2: Do it again, now you can be better and more efficient.

Step 3: See if you can speed up the process by tooling, scripts, etc.