Building a Renderer System for Unreal Engine Configurators
The renderer is the most visible part of a product configurator — and the most commonly underengineered. After building configurators across automotive, watch, and luxury sectors, we have arrived at a renderer architecture that treats rendering not as a scene, but as a system.
The first decision is separating the rendering pipeline from the configurator logic entirely. In early-generation configurators, lighting, cameras, and post-processing are set up once and forgotten. When the product line expands, those baked assumptions break — a leather bag needs different lighting than a watch, and a car interior needs a different camera rig than a shoe. Our renderer system defines a clear contract: the configurator tells the renderer what object is active; the renderer handles everything else.
The lighting architecture is built around what we call a lighting envelope — a parameter set that defines the character of the render without exposing raw light properties to the configurator logic. Each product category gets its own envelope: key light intensity, fill ratio, rim contribution, ambient base. These envelopes are stored as data assets and swapped at runtime, giving content teams control over the look without touching C++ or Blueprints.
Camera management is handled by a Camera Director component that reads product metadata to position, orient, and transition the camera. Default views per product step are declared in data — center the watch face when the dial step is active; show the clasp when the strap step is active. Transitions use UE5's camera interpolation with custom easing curves defined per product category.
Post-processing is where product visualization lives or dies. We use a layered PP volume stack: a base volume for global film grain, vignetting, and exposure; a product-category volume for color temperature and contrast adjustments; and a step-level volume triggered by specific configuration choices — enabling extra depth-of-field for engraving close-ups, for example. All three layers are data-driven and blend at runtime.
Rendering output — still images for print, thumbnails for the web, video for social — is handled by a Render Queue system that runs headlessly. Configuration snapshots trigger the queue; the queue resolves the current state, applies a render preset, and fires Movie Render Queue. The output lands in a cloud bucket, with a webhook notifying the backend. Product imagery is always up to date without manual intervention.
The hardest part of building a good renderer system is not the technology — it is the discipline of keeping it separate from everything else. The moment rendering logic and configurator logic bleed into each other, both become harder to change. Treating the renderer as a standalone system, with a clean API, is the decision that makes everything else easier.