Tools, scripts and workflow solutions.
So what is it that I do? I used to be a full time artist, and I loved it! I kind of fell into tool development out of sheer frustration with managing a modern (as of 2011) texturing pipeline without tool support, which got me into Python, which got me into programming which got me into tool development- and here I am!
My day is usually equal parts talking and coding- and then another part directly helping my colleagues with Technical issues, which may or may not form a significant part of my day. If I’m really lucky I still get to do art for look development or exercising a particular tool or workflow.
Before any code is written, I sit down with all the interested parties and we hammer out the details of exactly what is being asked. Measure twice! I believe in healthy debate in a workplace, and I encourage people to push back on things they don’t agree with, and argue for things that they believe in.
I try to take a Provider/Client relationship with tool development, partnering with specific teams or individuals to see a particular toolset developed to the correct specifications. I don’t write all the tools myself- often I will give
opinions legitimate feedback to other technical artists, either during development or code review.
I encourage people to speak up when they feel something isn’t working correctly, or could be better. It can often be the case that an art team is made of troopers who will just learn to make do, and absorb all sorts of ills before talking about it. Avoiding that situation is a worthwhile goal.
I have used C#, C++ and Python for tool solutions that touch Maya, 3DSMax, Unity, Unreal, Photoshop, Perforce and GitLab. I’ve grown quite fond of the Unreal Engine 4, and I’m now using it at home after working out how to get it compiling with CLion (not a fan of XCode).
These are the kind of tools have I written before, each of which has been used in a production environment:
- Bin-Packing Atlas tools for Environment Assets (Unity, C#).
- Bin-Packing Atlas tools for Character Assets. (Ue4, C++)
- Random Level Generation tools (Ue4, C++)
- Level Editing Utilities (Unity, Ue4, C#, C++)
- Content Profiling Tools (Unity, C#, JS)
- Unity Post Processing Pipelines (Unity, C#)
- Photoshop Exporters/Image Processors (Python, JS)
- Maya Environment, Rig and Animation Exporters (Python)
- Unreal Automated Build Pipeline (Python, GitLab)
- Source Control Integration (Perforce, Python)
Some other really specific things I’ve worked on:
- Dynamic Prop/Terrain blending (Ue4, C++)
- Solution to hard edges where props intersect with terrain.
- Dynamically blends normal and texture data using Mesh Distance Fields.
- Bakes terrain blending data to the blending prop, so any terrain blends are replicated on the prop.
- Dynamic Gradient-mapped material system (Ue4, C++)
- Data is generated in C++ based off of item inputs.
- Materials are given a series of baked-down color strips and lookup tables to build the color data for the given prop.
- System allows dynamic swapping of color data, resulting in customizable props without incurring a high texture cost.
- MiniMap Data generation (Ue4, C++)
- System designed to reduce impact on Level Design team, and to be easily updated when a level layout changes.
- Generates a mesh from the existing navigation data for a level, which goes through several cleaning steps and is then serialized to disk.
- Process is extremely rapid, allowing for quick iteration times.
- Gear/Item set previewing in Maya (Python)
- Set up the animation and character asset tools in such a way that the gear pieces could be swapped out within a Maya animation file to preview different combinations of gear pieces.
- System automatically cleans up preview pieces on export to keep animation files clean.
- Gradient mapping pipeline (Ue4, Python/C++)
- Created a texture, material and texture atlasing pipeline that allows gradient color lookups to be used on meshes at runtime.
- Lookups can be swapped out, allowing for a wide range of customization options with a relatively simple shader instruction and texture footprint.
- Environment Data Handler (Ue4, C++)
- Created a unified structure where Environment Artists can define their environment and lighting data.
- Creates a single point for editing key, skylight and accent light colors and post processing settings .
- System has the option of being dynamic if required, allowing for varied lighting conditions at runtime.
I’m also pretty into naming conventions, they are super useful, and I encourage their use.
Unity Code Samples:
Here are some code samples I’ve written in my spare time which you can grab and look through. You can even use them in your projects if you want. Feel free to take a look.
This is a simple tool that, given a number of arbitrarily shaped textures, packs them into a single texture atlas and slices it into a Unity MultiSprite image, based off of the original textures.
Unity does this quite well already, but this example is written to explore a packing approach more than be any kind of replacement for Unity’s sprite packing, although this approach does do an ok job.
Although this specific example outputs a MultiSprite atlas, the output from this packing method can be used for other tasks, including packing Lightmapping textures and 3d Model layout.
This is a small example project which takes data encoded in a JSON file and applies it to an imported asset using the AssetPostProcessor class and the 3rd Party MINIJson parser.
This same approach can be taken with various types of assets, allowing artists to define import settings from within the native app they are authoring the asset in, 2D and 3D.
It is particularly useful for defining clips on animated assets, or specific import parameters for textures.
Using the AssetPostProcessor class can also be extended to generate prefabs from exported models on the fly. COOL!