When people hear the words “Technical Artist”, they might picture someone authoring impressive visual effects, writing complex shaders, building animation systems, or developing tools and procedural workflows. The role can mean very different things from one studio to another, and the breadth of disciplines that fall
under Technical Art is part of what makes it such an interesting area of game development.
At Cast Iron Games, our Technical Artists are focused on one central challenge: realising the artistic vision without compromising performance. That can mean working across shaders, tools, assets, procedural workflows, optimisation, profiling and much more, using whatever combination of skills and techniques is required to solve the problem in front of them.
That is the difference, if there is one thing that defines Technical Art at Cast Iron. It isn’t a layer applied after the “real” work is complete. It is embedded into the development process from the beginning, allowing potential problems to be identified while they are still relatively inexpensive to solve. It also means that ambitious artistic ideas can be investigated early, using Technical Art R&D to determine whether a seemingly out-of-scope idea can actually be made practical through changes to tools, workflows or assets.
Case Study: Preserving Vision, Delivering Performance
One recent project provided a particularly good example of this approach.
What initially looked like a relatively straightforward optimisation task quickly became something more complex.
One level contained a vast open world filled with buildings, with each structure assembled from hundreds of instanced wall modules, doors, windows, railings and balconies, all generated procedurally through Houdini. It was a modern and highly scalable content creation pipeline.
The challenge was scale.
With more than 100 buildings visible across the environment, the world was simply too expensive to render within the available budget. Nanite wasn’t available to solve the problem in this particular case, so a more traditional optimisation strategy was required. The initial solution appeared straightforward: generate LOD
chains for every building module and allow the engine to handle the rest.
We tried exactly that using the excellent Simplygon, but although performance improved, the results were less than ideal.
Some parts of the modules were reduced far more aggressively than others, leading to noticeable visual degradation. The world was technically within frame, but the buildings no longer looked the way they were intended to.
The challenge, therefore, wasn’t simply reducing polygons. It was understanding what could be reduced, what couldn’t, and why.
Insight
The investigation revealed that the building modules actually contained two very different categories of geometry, each requiring a completely different optimisation strategy.
Variant-Density Meshes
The first was what we termed variant-density meshes. Wall, door and window modules combined relatively low-poly structural geometry with extremely high density facade details. Reducing the entire asset uniformly meant that the dense facade geometry could be simplified effectively, but the simpler architectural elements were being damaged in the process.
Low-Density, High-Instancing Meshes
The second category was low-density, high-instancing meshes. Elements such as railings were already highly optimised on an individual basis, so the problem wasn’t complexity per asset. Instead, hundreds of instances per building meant that relatively simple meshes accumulated into hundreds of thousands of triangles across the scene.
The key realisation was that a single automated LOD strategy would never produce good results across both asset types.
The Solution
For the variant-density meshes, we split the original modules into multiple sub modules sharing identical pivots, allowing each element to LOD independently.
High-density facade details could then be baked down into normal-mapped alpha cards while the underlying architectural geometry retained the level of detail it needed.
For the low-density, high-instancing meshes, geometry such as railings was baked into alpha cards, with a shared atlas created across all of the building assets to maximise texel density.
However, the scale of the project meant that a manual workflow wasn’t realistic. More than 100 buildings had been generated from just 70 reusable source modules, so manually processing the resulting assets would have been both time consuming and difficult to maintain.
Instead, the Technical Art team extended the existing Houdini pipeline to procedurally split, optimise and process all 70 source modules. The resulting system generated 215 optimised sub-modules, automatically creating custom LODs where required while also converting heavily instanced geometry into alpha card representations.
The building-generation pipeline was then updated to use the new optimised sub modules before Simplygon generated LOD chains for each individual asset. Rather than solving the problem one building at a time, the solution became part of the content creation pipeline itself.
The Result
The entire environment became comfortably in-frame while preserving the original artistic vision of the level.
By combining procedural tooling, Technical Art expertise and targeted optimisation strategies, we significantly reduced rendering cost without compromising visual quality. The final result maintained the look and feel that the content team intended while achieving the performance targets required by the project.
Where Tech Art Sits
Tech Art in this studio sits in the gaps between all of the teams. Traditionally, it is very easy to think of Tech Art as “Tech + Art”, bridging the gap between the two. In practice, though, there are more than just those two disciplines involved, and Technical Art has an important relationship with all of them.
Thereʼs QA, who we work closely with to ensure that risky or dramatic changes are properly tested and don’t introduce unnecessary regressions. They also often surface recurring patterns that might be invisible to us initially, but could point towards a problem that is likely to become more significant in the future. Thereʼs Production, where our investigations can hopefully help keep ambitious, “moon-shot” ideas both in scope and pragmatic. We try.
And then thereʼs Automation, whose valuable profiling data helps drive our decision-making process. We also spend a lot of time asking them for increasingly specific data that might help us understand what the artists are experiencing and where we should focus our efforts.
The Toolkit
- Engine profilers be that CPU or GPU so we can make efficient data-driven decisions regarding our optimizations.
- Simplygon for easy asset optimization and budget control.
- Houdini for building up custom/procedural asset optimization pipeline that simplygon cannot handle
- Python/C++ for writing tools in Editor/DCC to help artists with tedious work or to supplement an optimisation workflow theyʼve discovered. Or to manage assets en-masse and make sweeping changes in days instead of weeks.
- Healthy dose of never-giving-up!
Why Partners Should Care
None of this is visible to a player, and that’s the point. A partner handing us a project isn’t paying for Technical Art as a line item. They’re benefiting from the streamlined pipelines, technical problem-solving and reduced risk that come from having that expertise involved throughout development.
Catching a problem like the one above during development gives the team time to investigate it, test different approaches and build a sustainable solution. Catching it during a compliance pass costs a lot more than an afternoon. The earlier a problem is understood, the more options there are for solving it without compromising the artistic vision, performance budget or schedule.
Why We Like This Part of the Job
Every problem is a different challenge, whether it is optimisation, tools, asset implementation, shaders or something we’ve never encountered before. There isn’t always going to be a workflow, pipeline or established paradigm that neatly addresses the problem, which means Technical Art often requires a willingness to investigate, experiment and learn.
It also forces you to grow as a professional. You might need to talk to an artist or programmer, work with QA, ingest a completely different set of ideas, test theories and occasionally discover that the approach you thought would work absolutely doesn’t. You keep investigating, keep trying things and, hopefully, eventually succeed. It is also pretty satisfying to push a change into a project and see the frame-rate improvement reflected in the automation data.
Ultimately, though, a big part of Technical Art is about enabling the people around you. As our Senior Technical Artist, Jason Yong, puts it: “Being a TA is much like being a support in a hero-shooter. You arenʼt going to be dealing the most damage, but you are definitely going to get a lot of assists. In other words, as a TA you will enable the team.”
But perhaps the best part is the people. You get to learn from the artists you work with, and vice versa. You can help them become more technical, while they help you become more artistic. There is a real satisfaction in creating a tool that you know will make someone’s working life considerably easier, or writing a shader that allows an artist to realise their vision without blowing the performance budget.
That’s the bit of Technical Art we really love: taking a difficult problem, bringing different disciplines together, and finding a way to make it work.