Day/Night & Configurators

Daylight in Unreal comes from a Directional Light standing in for the sun, and its rotation is the time of day: pitch it low near the horizon for morning and evening, high overhead for noon. A day/night slider, then, is simply a control that maps a value - say 0 to 24 hours - onto that light's rotation. Drag the slider and you rotate the sun; the whole room re-lights in real time because Lumen recomputes the global illumination live, exactly the payoff of real-time you met back in the lighting module.

Mechanically it is a UMG Slider widget whose On Value Changed event feeds a Set World Rotation (or the Sun Position / Sky controls in an environment setup like the Sun and Sky actor). You map the slider's 0-to-1 output to a pitch range - roughly a sunrise angle up to noon and down to sunset - and, if you want it convincing, also drive the sky, fog and light colour and intensity so dawn glows warm and low while noon is bright and neutral. Unreal's environment tools can tie sky and sun together so one control moves the whole time of day coherently.

Why clients love it: light is the thing renders freeze into a single moment, and here the client controls it. They can check whether the west-facing living room bakes at 5pm, whether the courtyard catches morning sun, how the material reads at dusk versus midday. Those are real design questions, answered by their own hand on a slider - the kind of decision-making that used to need a dozen separate renders and a week of waiting. It is the sun-and-daylight lesson made interactive.

A precise mapping helps it feel right. Map the slider's 0-to-1 onto a sun pitch of about -5 degrees (just below the horizon at dawn and dusk) up to perhaps 60 to 75 degrees at local noon, and drive the light's color temperature warm (around 2000 to 3000K) near the horizon and neutral (around 5500K) at midday, easing intensity down toward the ends. If you use the Sun and Sky actor, whose Time of Day property is already an angle, you feed the slider straight into it and the sky, sun disk and horizon all move together - far more convincing than rotating a lone Directional Light against a static sky.

A configurator is the archviz showpiece: a set of options the client can combine - floor finish, wall colour, kitchen layout, lighting mood - to build their own version of the design and see it instantly. Under the hood it is nothing exotic. Each category is a variable that holds the current choice (Floor = Oak, Wall = Sage, Light = Neutral), each option is a menu button that writes to that variable and applies the change, and the scene simply reflects the current state. The whole thing is the menus from lesson 3 writing to variables and calling the swaps from lesson 2.

The design craft is in structure. Organise options into clear categories so the client is never overwhelmed - a row per decision, the active choice highlighted, as the figure shows. Decide which options are independent (any floor with any wall) and which constrain each other (a layout that only allows certain finishes), and enforce that in the logic. For layout changes - swapping a kitchen island for a galley, or furnishing an empty room - toggle the visibility of pre-placed alternative meshes rather than deleting and spawning, which is cleaner and faster. Keep every choice in a tidy set of variables and the configurator stays easy to reason about even as options multiply.

Watch two honest pitfalls. First, order of operations: apply every change through the same function the menu calls, so selecting an option and loading a saved choice run identical code - otherwise a restored configuration and a freshly-clicked one can quietly drift apart. Second, avoid a combinatorial explosion of prepared assets: for finishes lean on Dynamic Material Instances (a colour parameter, not a new material per shade), and for layouts pre-place the alternatives once and toggle visibility. Both keep the option count linear instead of multiplying into an unmanageable pile.

A configurator gets far more valuable the moment it can remember. Because every choice already lives in a variable, capturing a configuration is just recording that set of values. Unreal's Save Game system (Create/Save/Load Game Object) writes them to disk so a client can leave and return to their configuration; a lighter approach keeps them in a Game Instance so choices persist as they move between rooms or levels within a session. Either way, the principle is the same: state you can store is state you can restore.

Beyond saving, think about showing the result. A summary panel can list the current selection - Floor: Oak, Wall: Sage, Light: Neutral - so the client sees exactly what they have chosen in words, not just in the room. You can offer preset schemes (a curated Scheme A / B / C) as one-tap starting points, then let them fine-tune. And you can surface the choices for follow-up: a specification a client can screenshot, a set of camera views captured per configuration, or - reaching into later modules - a version delivered by pixel streaming so they configure it in a browser, or explored in VR where they pick finishes from inside the room.

This is what turns interactivity into a deliverable. A saved, shareable configuration is something a client takes away - and something that feeds straight into your actual documentation, because the finishes they chose are the finishes you specify. The interactive model stops being a pretty presentation and becomes part of the project's decision trail, which is exactly the value a serious practice wants from real-time.

Mechanically, a Save Game is its own small object: you make a SaveGame Blueprint with variables mirroring your choices, then Create Save Game Object, copy the current selections in, and Save Game to Slot under a named slot. On startup, Does Save Game Exist then Load Game from Slot reads them back, and you re-apply each through the shared apply function. Because it is plain variables in and out, adding a new configurable category later is just one more field on the SaveGame object - no new machinery to learn.

Step back and see what this module has built. You started with a static, if beautiful, real-time scene. You added a grammar - events wired to actions - and used it to make doors swing, lights switch and finishes swap. You put those controls on screen with UMG. And now, with a day/night slider and a saving configurator, you have something a client does not just watch but uses: a small product for exploring and committing to a design.

Thinking of it as a product changes how you build it. A product needs an obvious way in - a clear opening state and a hint of what can be changed - and an obvious way around, so a first-time client is never lost. It needs restraint: the architecture leads, the controls stay quiet, and no option exists just because it is technically possible. It needs to perform - a configurator that stutters or a sun slider that lags kills the magic, which is why the optimization module matters and why you make interactive only what needs to be. And it needs a purpose: every interaction should help answer a real design question or win a real decision, not merely show off.

That product mindset is also where the career is. A studio that can hand a developer a configurable, saveable, immersive model - by screen, by browser, by headset - offers something a folder of stills cannot. You now have the whole chain: import, materials, light, interaction, interface, and a configurable result. The next module takes this same responsive scene and puts the client inside it, in VR, where a configurator becomes something they reach out and touch.

That framing also disciplines scope. Before adding any control, ask what design question it answers - if a toggle does not help a client see, compare or decide something real, it is noise competing with the architecture. The strongest interactive presentations often expose fewer options than you could build, each one deliberate, fast and obvious, which is exactly why the optimization module that follows matters as much as this one.