Overview
Engines I have used professionally: Unreal, Unity, Lithtech, Snowblind Engine, Gamebryo, Renderware,
Created DCC Tools and Scripts for: Houdini, 3ds Max, Maya, Photoshop, Substance Suite, Speedtree, Zbrush
UI Tool Examples
Here are a few assorted tools I've created over the years. These are unique applications that don't fall into a broad category.
Mouse over images for info.
Houdini Farm Open World Tile Processing System
A scalable, deterministic system for processing Houdini HDAs across open world tiles—built to run headlessly through Monolith’s editor and distributed via Houdini farm or local PC execution with robust job management and reporting. This alone reduced the 12,288 lighting jobs from weeks of tedious manual work to just a few button presses.
Problem The initial integration of Houdini with Monolith’s level editor for world tile processing was error-prone, required significant manual input, and frequently disrupted workflows. As a result, many users ran only partial processes when updating tiles, leaving other Houdini tasks outdated and inconsistent. One environment artist even cited our Houdini toolset as a contributing factor in their decision to leave the studio. Solution After returning from supporting Hogwarts Legacy, I developed several Houdini tiled world HDAs. It soon became clear that we lacked a scalable, deterministic system for globally processing world tiles. With support from engineering and following some advocacy, I gained the ability to run the level editor headlessly, load specific worlds and tile sets, activate the Houdini Engine, and process HDAs automatically. This end-to-end workflow became the foundation of what we called a Job. From there, I built a pipeline to generate Jobs for each world tile, which could be distributed across our Houdini farm. To manage this system, I created the HQueue Job Manager, a custom application that allowed users to filter and submit targeted batches of Jobs—for example, skipping ocean tiles or processing a specific region. It also supported local execution, enabling users to test settings before deploying changes studio-wide. The diagram above provides a high-level breakdown of the system architecture and flow. Diagram Overview HQueue Job Manager: A custom Python/Qt application. Loads JSON Job files, allows filtering, and includes tools to sync farm PCs, monitor/reprocess Jobs, and generate reports. JSON Job File: Defines all Jobs for a world and Job type. Each entry includes settings and paths for headless execution. PowerShell Scripts: Each Job is converted into a PowerShell script (originally CMD, later upgraded due to increased complexity). Can run on the farm or locally. Houdini HQueue: Handles headless Job distribution across farm PCs. Local PC Execution: When running locally, the system loops through filtered Jobs. Python Job Wrapper: Once a PC is assigned a Job, a Python script sets up local paths and constructs the command-line wrapper. CMD Start Job: Launches the Job via headless Monolith Engine and updates Job status. Monolith Engine: Loads the required world, tiles, and content for Houdini to process. Houdini Engine: Executes the HDA logic using input from Monolith. I focused primarily on lighting, design movement, and terrain editing. By the time the studio closed, two other TAs were migrating their HDAs to the system. Output Asset: Resulting outputs such as CSVs, bitmaps, or geometry. Perforce Integration: Optionally checks in results to the P4 depot and also saves to a public network location. This is useful since remote farm access could interrupt Jobs. CMD End Job: Gracefully shuts down the Job. Completing this script signals the PC is ready for the next task. Logging: Each Job generates a log file to aid debugging, especially within the HDA. Reports: The system could produce various reports, including execution time, failed Jobs, outdated results, and more.
Automatic Markup Generation - Navigation Linking
This example demonstrates a Houdini system that processes world tile content from the Monolith Editor and automatically generates all the necessary markup to connect nav mesh edges.
For the canceled project before Wonder Woman, this tool supported 18 different edge movement types, six rail movement types, the automatic placement of climbing points for handholds, and the creation of ramps to bridge small gaps in the nav mesh. For the Wonder Woman game, the design aimed to simplify movement, removing systems like edge hanging and stealth, for example. Above, you will see a simple markup triangle for Edges(green) and Rails (red).
For anyone familiar with Unreal, this is analogous to Automatic Navigation Link Generation.
Problem:
In both Shadow of Mordor and Shadow of War, these markup triangles were manually placed. Often by designers and artists who found the process tedious and time-consuming. At one point, we had as many as twenty people finalizing markup for a single area. Once finalized, areas were locked down, and any further edits required extensive gating and testing.
Solution:
With Houdini-generated markup, we were able to create navigation links quickly and consistently. This enabled movement designers to iterate on traversal design across the open world and allowed environment artists to work longer before areas had to be locked. It significantly improved iteration speed and reduced manual effort.
Video Notes: I had background noise canceling on, and it made my voice sound wavy, apologies. The shown markup took 10 seconds to generate using the Houdini HDA.
Unreal Engine Experience
I’ve shipped seven Unreal Engine titles, from a best-selling Game of the Year to smaller budget releases, along with three unreleased projects. I’ve also developed interactive trainers for clients outside of gaming, building a versatile skill set that spans entertainment and real-world applications.
Mouse over images for info.
Maxscript Examples
This gallery features a few of my more widely used MaxScripts. Over the years, I’ve written over a hundred of these tools. Public Maxscripts Downloadable Here.
Mouse over images for info.
Lighting, Houdini Spec Probe Placement for Enlighten
This Houdini process would load all assets within a world tile (purple geometry) along with any overlapping neighboring content. For each LOD cell (cyan box), it generated volumes representing open space within the cell (tan geometry). Using those volumes, the system identified two optimal probe positions (small green spheres).
Each cell’s probes could be biased in about eight different ways. In this case, the probes were chosen based on volume size (large green spheres), distance from the cell center (red sphere), and spacing between probes. Additional biasing options included proximity to terrain, height within the cell, opposing quadrants, and more. Each probe pair was graded, and one or both could be culled if their score didn’t meet a threshold—helping optimize probe placement.
Each world tile would write out three CSV files, with each CSV representing a cell containing up to six LODs, that is 37,449 cells with up to two probes each. The full world consisted of 64 × 64 tiles—nearly half a billion possible cells. Fortunately, empty cells and their child nodes did not require probes, and the vast majority are empty.
I also optimized cell-to-world geometry intersection tests beyond Houdini’s standard methods, cutting HDA execution time by approximately 90%. This moved the biggest bottleneck back to the loading of the world content.
Corner Volume Trigger Generator
This Houdini tool was created for designers to procedurally detect corners in the game world where events like nemesis encounters could be triggered and AI could take cover during ranged combat. If a player or camera is in one of the volumes, the other volume could be used for many different purposes, such as a valid cover, event spawner, escape point, etc.
Description of examples (left to right):
-
A: The corner that this system operates on; concave corners are ignored.
-
B: The Corner Bisector.
-
C: The Corner Bisector Perpendicular Line—if an object is on the side opposite the bisector, the trigger is off; if on the corner side, the trigger is active.
-
D: Paired Corner Volumes—their size is set by design. If the distance from the corner to the volume is too great, the corner may be considered invalid. If the gameplay asset is inside of one volume, then the other volume is not visible, and therefore, any gameplay logic can be added as needed.
-
E: Blue line illustrating the connection between the volumes, as the nearest volume is not always its pair.
Prototype: Procedural Reverb Volume Generator
This Houdini reverb volume prototype was created after a meeting with the Audio Director, where we brainstormed a list of things that the Houdini process could help his team. In past projects, the audio department, who, by their own account, were not experts at creating geometry in our editor, manually placed all the reverb volumes themselves. They also added the volumes at the end of the project when content was locked down; this made iteration and testing hard. This tool would have made the reverb volumes for them anywhere sound bounced off two or more walls if a specified distance was needed. Then if an area changed, the tool just needed to be re-run. This never made it to the game, but adding reverb volumes was tasked until the studio closed.
Descriptions of examples left to right:
-
Reverb generated on single concave geometry.
-
Reverbs are generated on the intersections of geometry.
-
Reverbs are generated on noncontiguous geometry.
-
Reverbs are generated on noncontiguous, non-wall geometry.
-
Reverbs are generated on something close to typical use.
-
Reverbs are generated on random boxes, which is a worst-case test.