I keep Unreal Engine scenes inside their frame budget — and I measure what they cost.

Problem

The level shipped lit exactly one way: baked, static, night. A second time of day was not a slider, it was a second bake — and the project was running DX11 with Shader Model 5, so Lumen and Virtual Shadow Maps were not disabled, they were unavailable.

Constraints

A third-party environment used as-is, in a project holding around thirty other baked levels that all had to keep working. The pack’s candle Blueprint carried a shadow-casting point light, and there were 132 instances of it.

System

Moved to DX12 and Shader Model 6, enabled Virtual Shadow Maps, set the sun, sky and every local light to Movable with the sky light on Real-Time Capture, and took the baked lighting data out of the content directory. On top of that, a C++ actor holding two instances of one struct: a preset describes an entire look — sun angle, colour, intensity, volumetric scattering, sky, fog, grade, lamp multipliers and particle visibility — and the controller applies or interpolates between them at runtime.

Result

143 dynamic shadow casters down to 11. 1.1 GB of baked lighting data removed. 49 standalone lights and 264 inside Blueprints converted to Movable. Frame time before and after has not been captured.

Technical artist — lighting pipeline, C++ tooling, optimisation

What it taught Three bugs were worth writing down, and the most expensive was measurement rather than code: the editor viewport applies physical camera exposure and Movie Render Queue does not, so every value tuned by eye was about ten stops out when rendered.

Read the case study →

Problem

Optimising your own environment proves very little — if the frame gets faster and you also control the art, nobody can tell whether the win came from engineering or from quietly deleting half the foliage. The goal was a measured optimisation pass where that ambiguity is impossible.

Constraints

A third-party scene, none of it authored here, so every millisecond had to come from engineering. Measured at 2560×1440 native, Epic scalability, on an RTX 3060.

System

A benchmark harness built before any optimisation, then tested against itself before its numbers were trusted. Profiling identified the cost as the scalability preset rather than the scene: at Epic, ShadowQuality@3 sets the directional virtual-shadow-map LOD bias to −1.5, and the scene’s directional light carried a ShadowResolutionScale of 8.0 on top of it.

Result

32.99 → 44.37 average FPS, a 34.7% improvement. Frame time 30.45 → 22.60 ms, GPU time 29.60 → 21.76 ms, 1% lows 31.87 → 41.91, VRAM 4 327 → 3 790 MB. Every camera improved and the worst baseline camera improved most. The 90 FPS target was not reached.

Sole author — benchmark harness, profiling method, optimisation decisions, QA pass

What it taught Two hypotheses died on contact with the data. Switching Lumen to software tracing was expected to be cheaper on a mid-range card and was 5.9% slower, so it was reverted.

Read the case study →

Problem

Changing how an asset looks meant a round trip to Substance 3D Painter — re-texture, re-bake, re-import — and that loop gets slower the more assets share a look, because one art-direction change fans out across every texture set in the environment.

Constraints

It had to be drivable by an artist who does not want to open a material graph, and it had to cost less memory than the texture sets it replaces, not more.

System

One master material blending several material layers — base wood grains, painted metals, emissive trims — resolved inside a single material instance. An ID map assigns material properties to regions of a mesh, so the handle and the panel are addressable independently within one material. The parameters that actually get adjusted in practice are exposed on the instance: colour tint, roughness and metallic scalars, and static switches for optional features such as surface wear.

Result

Retexturing becomes a dropdown rather than a round trip, and shared tiling textures plus channel-packed masks carry the detail instead of unique bakes. No measured numbers yet: shader instruction count, texture sets replaced, texture memory and a shader-complexity capture are all outstanding.

Sole author — master material, layer set, ID-mask logic, exposed parameter interface

What it taught A system nobody else can drive is not a system.

Read the case study →

Problem

A hangar has to read as enormous and as functional, and those goals fight: the scale that makes a space impressive is exactly what makes it repetitive and expensive to texture, and a big open volume gives the viewer no obvious route through it.

Constraints

Industrial scale without the texture budget that usually implies. Work in progress — the images show the environment mid-development.

System

A modular kit rather than a single environment: structural trusses, floor gridding and wall panels that snap to a consistent grid. A single 4K trim sheet in place of unique bakes per beam and panel. Lumen lighting used navigationally, picking out the central maintenance platform first. And a Blueprint that instances and deforms static meshes along a 3D spline for the transit tube, recalculating segment count, orientation and spacing as the spline points move.

Result

One 4K trim sheet and one material ID across the environment. Triangle count, draw calls and frame time have not been captured.

Sole environment artist — kit design, materials, lighting, set dressing, Blueprint tooling

What it taught Scale is only legible against something already familiar — the cones, crates and terminals are placed to make the trusses read as massive.

Read the case study →

Every lap you drive walls off the track. How many laps before there's no line left?

Genre

Racing

Platform

HTML5/browser

Status

In development

AI disclosure

AI Assisted

Play on itch.io ↗