If I were learning technical art, where would I start?

Whenever someone asked me how to get into technical art, I used to send them a pile of bookmarks in no particular order. Tech art is too wide for that, and most lists online are either one person’s favourites or haven’t been updated in years.

So this is the list I send now, and the order I’d go through it in.

The list

It’s a community-curated database of 68 resources for graphics, rendering and game development. Every entry is filed three ways: by domain (maths, shaders, code, optimisation, tools, libraries), by format (book, course, blog, talk, video channel, tool, conference) and by level (beginner, intermediate, advanced). So you can ask it a proper question, like “a beginner level video series on maths”, instead of scrolling.

It was put together by my friend and fellow technical artist Jan Mróz, alongside Radosław Paszkowski, Łukasz Bogaczyński and Peter Sikachev. I’ve contributed to it too, and community members can submit links, so it keeps getting updated.

The order I’d go in

Even filtered, it’s a lot to take in.

1. Visual maths. Freya Holmer and 3Blue1Brown both teach vectors, matrices and interpolation with a picture attached, and Desmos lets you plot a curve and drag its values around. Almost every shader trick later on is some mix of lerp, dot product and smoothstep.

2. Find out how a frame is drawn. A lot of early shader confusion is really confusion about the pipeline: what runs per vertex, what runs per pixel, what a draw call costs. Render Hell 2.0 by Simon Trümpler is the friendly illustrated version, and the one to read first. Fabian Giesen’s A Trip Through the Graphics Pipeline covers the same thing in full depth, and is worth coming back to once the basics make sense.

3. Write shaders with no engine in the way. The Book of Shaders and Shadertoy strip it down to one fragment shader and a clock, with no material graph or asset import to deal with. After that, Inigo Quilez’s articles go much further, and Catlike Coding or Cyanilux take it back into an engine, where lighting and render passes come into play.

4. Learn to measure before you optimise. RenderDoc is free, works almost everywhere, and lets you step through a captured frame event by event. PIX and Nsight sit next to it for platform specific work. Once you can read a capture, the optimisation writing on the list, like Interplay of Light, is much easier to follow.

What the list doesn’t cover

The database is mostly a graphics and engine programming list. It’s very good at that, but tech art covers a lot more.

You won’t find much on #houdini and building HDAs, or on #python for pipeline and DCC tools. Same for rigging, Niagara, source control for an art team, and writing documentation an artist will read. In my own work those have taken up at least as much time as shaders have. For that side I’ve learned more from tool documentation and other people’s breakdowns than from any one site. Malika Omarova’s Tech Art Notes, a walk through Unreal’s profiling commands, is one of the few entries on the list written from the tech art side of the job.

I’ve also learned more from finishing projects than from reading. Getting the whole LDraw part library through a Houdini network for Tool Brick taught me more about procedural workflows than any tutorial, and working to a real frame budget on Borderline Racing did the same for optimisation.

Start here

My pick for day one is Render Hell, then Shadertoy to make a circle that pulses. Come back to the list when you have a specific question.