Tech Art Works

One of the most common considerations I have to take into account in my day job is that of User Environments. Like most technical artists, I do not fully control the machine set-up for most of the people using the tools I help build.  This is pretty common; as tech artists, we can ask our IT departments to distribute specific software packages, maybe even versions, but beyond that there's little we can do to ensure a given user is set up entirely in line with our wishes, short of us physically walking over to their desktop and checking it for ourselves; an option not always available to us. Table of Contents The Three Degrees of Control There are many ways to describe the degree of control you can exert over a given user's development environment as a software engineer. However, for the sake of simplicity, I like to categorize them using the following three labels: "Overlord", "Squad Chief" and "Distant Observer". Overlord In the "

When setting up a new DCC, or building basic infrastructure for your studio's artists to use, one of the most critical components to get right from the start is how they launch, use and interact with their content creation tools, otherwise referred to as DCCs (short for Digital Content Creation software). If you export your content from, say, Maya, you want to ensure that all Maya files in your project are set up correctly, using the same unit scale, system units, up axis, frame rate, etc...  You also don't want any of these things to be left up to the artist; there are simply too many things that can go wrong, and the cost of issues like this not being caught until a great deal of content has been produced incorrectly can potentially be crippling for a project. So how do you ensure a DCC is setup for the artist, correctly, every time they launch it? The simple answer: give them a launcher that does it for them. "But" I hear you say, "launch

Continuing on from my first post on the subject , here we will dive into properly expanding upon the theme of hooking custom python-based menus into the various menus and toolbars that Unreal has to offer. For the sake of example, I will limit myself to containing this to just the Level Editor Toolbar, but I will write another post on how to set your menus up (almost) anywhere in the Unreal Editor Interface. Now that we've got a menu, we can start expanding it! In this example we're going to be building a custom menu using the ToolMenuEntryScript class, which allows developers to implement overrides for various functions it contains, including the execute() function, which allows one to implement multi-line (much more complex) functionality and tie it to a menu entry.  This is a surprisingly undocumented feature of Unreal Engine, and it is very difficult to research without diving into C++ yourself, so I will be breaking things down here. First, let's clean up

One of the most common problems tech artists are in need of solving is that of delivery; how do we get our tools into users' hands? There are various answers to this question, and each use case demands a different implementation: for asset-centric tools, a context menu in a content browser tends to work best. For more generic tools, some kind of launcher is generally preferred. In my day job, I work with Unreal Engine, and this is a question I run into a lot, and one I've had to solve a few times. I recently started getting more stuck into this problem however, and I thought I would share what I learned. I should add that I received some assistance in this from friends at Epic Games and the Technical Art Community, who were kind enough to ask around internally at Epic for the solution to the final bit I was stuck on. So let's dive straight into the code, as that's what you're probably here for. Note that all code in this post has been tested on Unreal Engine 5, but

One of the most common parts of any pipeline is a texture packing process of some sort. This is usually the result of the complexities of a shader, requiring artists to adhere to a rigid packing spec to maximize performance and pack masks as efficiently as possible. In any production of any scale, 3D art production will involve some amount of texture packing. There are many ways to perform texture packing, and not all of them require some kind of pipeline solution. However, once the packing spec reaches a certain level of complexity, a measure of control over the packing process becomes desirable. In this article, we will build a simple texture packer (which works with .TGA files and most other common file formats), that could lay the foundation of building a more complex one on your own, without requiring any expensive software licenses to do so. Building the base class Implementing a simple Mask Packer Now that we have a simple base class, we can get to work on the "meat

When you're chipping away at your next script, exporter, framework, or just really anything that requires you to do some work, it's tempting to get sucked in and just write code for its own sake. You can even go as far as finding excuses to build systems simply because you're interested in finding out how they work, almost regardless of whether you can justify their cost. This is often an easy trap to fall into, because often, these systems do carry value in the mid-to-long term. When it comes to Tech Art, long-term solutions are generally not the thing we work on most. The average lifetime of a given solution Tech Art builds tends to be a subset of the total production time. As project needs change, Tech Art adapts and builds solutions for problems the project encounters, almost always on an as-needed basis. It can be tempting, then, to chase the next solution as it comes up: artists are having trouble constructing levels quickly? Work on placement tools. Lots of buildings

Building a multi-DCC exporter from scratch On any given production, one of the first things the Tech Art Teams tend to build is an exporter. This is easily explained: of all the problems facing any given project, reliably and consistently transferring content between your DCC and your engine (whatever they may be), is one of the most valuable ones to solve early. Even as of the time of writing, in an industry where game engines become ever more all-encompassing, external DCCs continue to play a vital role in productions, after all. Doing so ensures that even during early preproduction, your models and textures are exported through a known method that can be controlled - providing the opportunity for early validation and simple checks before content gets into the engine. In other words, this puts an immediate filter on your content pipeline from day 1, ensuring that all content produced thereafter passes through it. In this short tutorial, we will be looking at bui