Storefront Thumbnail Generator

Pipeline | Storefront Thumbnail Generator

UI pipeline, triggers when the storefront DB is updated. Captures photos in a specially-modified 'Home Space' environment, post-processes them using PIL, and copies the output into a new Perforce changelist. I used this to generate all 400 wheel thumbnails on the storefront.

(SQL Database ↔ PowerShell ↔ Game Client) → Py.PIL → Perforce

Applied Skills: PowerShell | C# | PIL | SQL

Description

The ADs wanted FM8's storefront thumbnails to be rendered in-game, which is why this pipeline came to be. We only used it for the wheel thumbnails, but it can easily be re-configured for other assets. My final deliverable included a core PowerShell script, a Py.PIL image utility, a purpose-built environment, some setdressing props, and a few HDRs.

To set up the scene, I created a custom 'Home Space' environment, made a specular-inducing HDR, and collaborated with our amazing Lighting Team to add an FM8-colored 'three-point' light rig. Then, to capture the images, I developed a PowerShell script which checks the storefront SQL DB for any Live-pending changes, and if it finds any, it opens a new game instance, loads the asset, captures a color image and a greyscale image, opens our Python image utilities, masks the color image with the greyscale image, post-processes the resultant image, and adds the final thumbnail image to a pending Perforce changelist.

XP

Since Forza Motorsport is a live-service, we needed a pipeline to generate spiffy new UI thumbnails for fresh content, and it had to be fast; we only had a narrow period of time during which newly-added rims had not yet been promoted to Live. It was mandated that the images had to be captured in-game; I couldn't create proxy materials and capture them in VRay, for example. Due to our use of RTR, the pre-existing pipeline from FM7 was almost entirely unusable (among other reasons), and I had to come up with something new.

From beginning to end, my pipeline is fully automated; the only thing the user has to do is validate the output and submit the new, pending CL. Many folks were really happy with this tool, across multiple of teams. The procedure is easily-adaptable, and I'm stoked to see how it will be used for driver suits and other storefront items, down the line.

Background Environment

To set up the background, I made a special version of the 'Homespace' scene and made a few custom assets such as a large, creased tapestry to give the reflections some texture. I worked with our amazing Lighting Team to set up a dope, blue-tinted, three-point lighting in accordance with the project's visual target. Subsequently, I made a single-frame cinematic in which the wheel was dead-centered, and the camera was set to use a wider-angle macro lens to give the wheels a slight fisheye effect.

Capture Procedure

This task was assigned right before ship, during the frenzy before 'ship lock', when there were countless Rendering and Engine changes being submitted left-and-right. This caused significant issues when I was capturing the images, especially when updated content was only compatible with an updated executable. I had to work around a lot of unpredictable graphical issues on a very tight schedule.

One submission signifcantly-decreased the reflection resolution on objects with small surface area, and due to higher-order content changes, I couldn't revert back to an older executable. To get around this, I ended up building a custom executable in which I'd adjusted some of these rendering settings.

Another submission forced the game to use lower LODs, which was particularly egregious for lower-poly Legacy wheels. I initially thought about editing the contents in the runtime-unpacked ZIP, but the deadline was tight and I kept running into issues. My simple workaround was to make a masking function using in PIL.

Since the wheels were all the same size, I made a circle-shaped mask and subtracted its inverse from the game-captured mask image, and then applied a slight blur to the edges of the shape, which made the wheel's outer edge a perfect circle.

When I did my first pass, I noticed that dielectric materials looked really dull. The ADs did not like it, and our BCD was due in two days. We were in the middle of adopting RTAO, and at the time, its implementation was pretty rough. Worseo, I was only able to use an older, RTAO-free executable for some of the wheels, and our BCD was due in two days. My three-point rig did help quite a bit, but I still needed some more range in the ambient lighting.

I knew I needed to adjust the sun position and intensity, but due to engine constraints, I couldn't move it to the appropriate, physically-inaccurate position. I also couldn't move the lower-level scene geometry/splines without causing a bunch of other issues that I didn't have software licenses to fix. To work around this, I ended up using our debug HDR sky system and made a custom texture where the sun was properly positioned.