Real-Time Texture Configurer

Pipeline | Real-Time Texture Configurer

Editor-integrated GUI. Allows artists to select assets in the viewport, configure texture properties by channel, re-export the textures from PS, and re-deploy the textures to a running game instance. This tool reduced our texture memory usage on all tracks and allowed textures to load at higher MIPs.

(Fuel Editor ↔ Photoshop) → Game Client

Applied Skills: IronPython & C# | JavaScript (Photoshop JS API)

Description

One of our ongoing problems was that certain track zones exceeded our texture memory budget, and so certain foreground textures would fail to load at the appropriate MIP. This was informally-known as the 'blurry textures' issue. We needed to cut down this memory usage; we needed a spot-based tool for editing and re-exporting unnecessarily-expensive textures.

This problem varied significantly between tracks and zones, and some were easier than others. On Suzuka, many of the budget-eating textures were renderer-insignificant MRAOs, so we were able to just cap them down to a certain threshold. Hakone was much more challenging: many of the textures had a MIP-enforcing 'TexturePri', such as the jumbotron textures and track-specific road decals, so our baseline texture memory usage was already very high. Moreover, the rest of the budget was primarily eaten away by 'Library' textures, which we couldn't downsample, as it carry over for all of our other tracks. We ended up having to chisel away at whichever Hakone-specific assets we could find, and downsample textures from texture types which we normally left alone.

To tackle this problem efficiently, I made this viewport-based tool to allow us to perform spot-fixes, and assess the visual impact of doing so. It allowed us to perform texture optimizations in certain zones and assess the visual impact, very quickly. I used our 'limiting stats data' to assess different hotspots, and I used this tool to go in and optimize the textures.

The 'Models' list is populated with viewport-selected assets, and the settings panel contains different texture export settings, such as filterable texture types, compression formats, a size cap and size scalar, and so on. When the user decides to 'Edit Selected Asset Textures', for each sub-selected asset (highlighted in blue), and for each of its textures of a particular type, it will update the TEXTURESOURCE XML with the user-specified texture properties, re-export the textures from Photoshop, and re-deploy it to a running game instance.

XP

During development, we'd noticed an overabundance of high-resolution, unoptimally-encoded textures throughout our tracks, which vastly exceeded our 'trimmable' texture memory budget. There were two problems at hand:

For some of the larger tracks (such as Le Mans) we didn't have enough memory unload the textures from the ZIP during loadtime. Even though this is simply an up-front, one-time cost (until the 'PV' part of PVSTex takes over), once the budget was overexceeded, the subsequent textures would not be loaded at all.
In certain track zones, the texture memory usage was too excessive, which caused PVSTex to run out of background textures to MIP-down, leaving it with no choice but to downsample textures in the foreground.
- This was made significantly worse by our 'TexturePri' markup, which is the CSV table which PVSTex uses to prioritize certain textures/MIPs. PVSTex would use a significant chunk of its (inadequate) budget to maintain higher MIPs for prioritized textures, but any other textures would get absolutely butchered, all the way down to MIP N.

In our initial passes, we downsampled all of the textures which were assigned to unimportant material channels, such as MRAOs (unimportant in our renderer, at least). However, there were many assets for which certain textures were much more visually significant than others, resulting in an unpredictable, significant degredation in visual quality. Each of these passes was incredibly slow; we had to go through multiple UI menus to get to the texture, edit the related XML with a script, and kick off another track build.

It was incredibly slow to do these optimization passes. Typically, we would hand-edit around thirty assets and RTU them to a running game instance, and depending on the results, we would run a script to edit each texture's related XML, and then kick off a track build.

Hand-editing them was awful; for each asset we had to open the model, click through almost a dozen material keys, and for each material key with the relevant material channel/texture type, copy the texture path, open the Texture Editor, paste the texture path, open the texture, hand-edit the relevant texture properties, check out the texture ZIP in Perforce, open the texture in Photoshop, re-export the texture, and then click the 'RTU' button to see it in-game. To make matters worse, each step could take anywhere from four to forty seconds. Testing out a handful of assets in one zone could literally take hours.