Tools Gallery

Here we showcase all of our work in tool development from our whole creative work starting from Tomb Raider on.

Task Tracker Pro was a tool we built to help us manage our work. It was a simple database that allowed us to track our work, hours, and progress. It was a great way to keep track of our work and also to help us understand how long it took to do certain tasks.

To learn more, check out:

• The Making of Task Tracker Pro (3-part series) >
• Vist the site >

We wrote this Calendar app to help us keep track of our time. It has a search feature for all notes during day, keeps track of deadlines, and allows us to measure how long project phases are taking so we can better get a sense if we're on track or need to adjust our schedule. It also includes a login system, weekly hour tracking, and even provides a summary of productivity every weekend.

While it's a lifesaver and can't stress enough how we can't live without this tool, it's not available for public use. But we can demo it and show how it works. All of the back end systems developed for this app became the groundwork for Task Tracker Pro, which is why, sadly, we had to let go of further development due to limited support bandwidth that would later be used for task app. Nonetheless, they work well together and often share info with one another to help us stay on track.

Maybe someday we can release it as an app but for now it's a private tool.

To learn more, check out our article: The Making of Monarch PTO >

Monarch Unity Tools

_{Written in: C#, Bash}

These were the tools we used for exporting, importing, and managing our assets for games we created in Unity. The biggest help was our backup tool, it copies art assets into a Dropbox folder while it publishes code into GitHub. By doing so we avoid massive issues with sources files taking up too much storage without losing the ability for incremental backups.

We also wrote a screenshot tool and asset manifest so if there were any discrepancies and by chance something had been missing, we would know from the start. By comparing the before and after using revision control, we could easily identify any error and fix it. In some cases, we lost assets that couldn't be recovered, sometimes it's unavoidable but we did our best to minimize the risk. We also wrote a publish tool that allows us to do backups and revision submissions at the same time. These tools were a lifesaver.

Unfortunately, we can't share these tools as they are proprietary to our work. But if requests come up to make them available, we'll consider it in future updates.

Dropbox Fetch / Push

_{Written in: Bash}

Since we work with both Mac and Linux, we often transfer between the two for our treasure game. It's not easy syncing files between two computers, that's why we wrote dbx_push and dbx_fetch as an easy way to get and send files between the two. That way, we can focus on our game regardless of the platform we're on.

As a bonus, we can build the latest iteration of Can You Dig It on Linux, sync using our script, compress, and upload on the Mac to itch.io. Since we're not always able to dev on our main machine often but need some of its core features, we make the best of both worlds.

The following are a list of tools we wrote for Naughty Dog from the time we started learning how to script in Python during Uncharted 4 all the way to pipeline maintenance in The Last of Us 2.

LUI: Render Setting Preset System

_{Written in: Python, PyQTGui}

It connected the game's runtime post effects attributes to Maya via an interface that allowed for editing inside of Maya to update within the console. As a result, we could then create preset systems that made development go 1000 times faster (not an exaggeration). This includes snow, rain, fog, time of day, and more with just a selection of a preset, saving hours of work in seconds.

For more details, check out: The Last of Us 2 Gallery >

N-Render Tool

_{Written in: Python, PyQTGui}

Given the proprietary nature of this tool, we may limit access to this section as either its own page accessible through our resume or as a password protected page. We'll have to see how it goes. We may also omit it altogether.

This connected studio's proprietary rendering system to the Maya interface and the console. This resulted in the ability to move the camera as well as sunlight in game through the dev menu, yet allow the ability to see it update using a pathtrace preview of the render live within Maya as well as doing the same for lights bouncing off of objects. This resulted in unprecedented speed debugging lighting issues and bounce light polish.

We did not write the renderer nor the camera connection tools, but instead connected these separate pieces of ingenuity from our studio and Sony's engineering team together into a seamless integration. Admittedly it was a bit buggy when it comes to starts, stops, and crashes, but over time we were able to reduce these issues by 60%. While it was well enough to use in production, some artists were reluctant to adopt it unless they had to and there were cases where it proved useful enough to be an absolute necessity.

xLit 2.0 (optional)

_{Written in: Python, PyQTGui, MEL}

Given the proprietary nature of this tool, we may limit access to this section as either its own page accessible through our resume or as a password protected page. We'll have to see how it goes. We may also omit it altogether.

Invaluable during development of Uncharted 4 and The Last of Us 2, the original xLit was written by lighting artist Omar Gatica. It improved workflow and became the defacto upgrade to our pipeline. It took basic functions such as custom objects and lights that worked exclusively for studio's rendering system. But it was written in MEL and not up to date with the latest code changes since Omar's departure.

We reworked the whole tool from scratch using Python and added upgrades such as a light linking system, a color palette swatch, and the ability to select lights by color, type, name, or intensity to make quick updates on large groups at a time. We also added a light lister that allowed for quick selection of lights and objects.

We also embedded a help menu using PyQTGui so anyone hovering over a tool could get a description of what it does, saving time having to look up documentation. It also came with suggestions and best practices.

Geo Import Tool

_{Written in: Python, PyQTGui}

This tool pre-processed mesh imported from cached geometry into Maya, processed it, named, and grouped so any lighting artist could use the game's assets as a reference to specific situations where needed whether to place fires or dynamics lights in a scene. One example of how it helped was in placing police lights on a car. Another was in importing the location of all torches, candles, and fires in a scene. With upgrades to xLit in combination with the import tool, a lighting artist can get every light source and in one click, convert each one into a physical light, generating an accurate representation of the scene and completing the look of the game.

Launcher

_{Written in: Python, PyQTGui}

Inspired by IW, we wrote a launcher that allowed for quick access to all of our tools. It was a simple interface that allowed for quick access to all of our tools in one place.

Lightmapper

_{Written in: Python, PyQTGui}

Automated the process of tagging geo and laying out UV's for lightmaps including auto-detection of the layer exists, adding if it doesn't, and auto arranging UV shells optimal for the type of geo used, whether architecture or organic. Note, it was a simple tool that worked for quick production needs but not a full solution.

Bake Notifications

_{Written in: Python, Bash}

When a bake completed, it would send a notification to the artist's desktop. It would also forward a copy to members of the team so they could see the progress of the bake and know when it was done. Later other programmers updated it to include a snapshot of the lightmap UV shells so the team would know if there were any issues to address. Sometimes by looking at a snapshot from an email of a completed back one could tell if there were major revisions needed to be made on the geometry or texturing.

It also notified when bakes failed, so everyone on the team who was signed up would know when to check the console for errors and address them in a timely manner. It was one of our most highly utilized tools and a great way to keep everyone on the same page.

The issue of spam did come up and while we did our best to reduce it, there was some disagreement about keeping it. Some felt it was important to keep track of all bakes while others felt it only mattered when something succeeded. We did our best to provide options to allow for both.

Palette Box 2.0

_{Written in: C#}

We wrote an update to Palette Box that included a color picker, a color wheel, and a means to convert kelvin temperatures to RGB values. It was a great way to save time and quickly recreate different schemes for lighting. It also converted to normalized and HSV values.

It also came with a luminance readout since this was something that wasn't working the way it was supposed to in Photoshop. It's what allows us to know when a material or light is the value it should be when outputting to the game, regardless of gamma or color space.

Features

• Color Picker
• Color Wheel: Complimentary, Contrast, Analogic, Accented Analogic, etc. on drag-sample
• Kelvin Temperature Converter
• Normalized Value Converter
• HSV Value Converter
• Accurate Luminance Output
• Drag-sample from multiple monitors

Download (Windows)

Palette Box 2.0 (Windows 764kb)

Worldspawn Calculator

_{Written in: C#}

Quake's Worldspawn settings are simple text prompts and in no way allows for an artist to know what color is being used or foresee if certain value combination would cause out of range errors.

We wrote a worldspawn tool that allowed for a color picker, a color palette, and a color swatch. It also allowed for a Kelvin color picker and a Kelvin swatch. It saved files, loaded them, and using math from the rendering engine for the company we worked for, we could predict with high accuracy what the values would output in the game and whether or not that would be within the proper range.

This tool was later used to improve porting for the Wii, allowing for colors and values to come close enough that at lower resolutions, one would barely tell the difference. It was pivotal in the completion of a particular level we felt passionate to help complete.

Palette Box 1.0

_{Written in: C#}

We wrote this color palette tool in 2008 thanks to something Rich Farrelly had showed us during Call of Duty: World at War. He used an app that color sampled the screen and gave values to plug into the Worldspawn. We then took that idea and expanded it to include a color picker, a color wheel, and a color palette, along with preset palettes based on a key hue.

Throughout this site, we've demonstrated many times where this 9-color palette swatch shows up. While originally it was made by hand, we later wrote in C# a version that allows for drag-sampling and color picking along with a copy + paste feature. It has become a staple in many of our early work for lighting.