Interactive Doors, Lights & Material Swaps

Every interaction needs a starting gun, and in archviz there are two you use constantly. The first is a click: the player points at an object and presses a button, firing an On Clicked event on that actor. Click is perfect for deliberate choices - open this door, press that switch. It needs the object set up to receive cursor or controller hits, but once wired, clicking is the most intuitive interaction a client understands.

The second is an overlap trigger: an invisible volume - a Trigger Box or the collision on a component - that fires ActorBeginOverlap when something enters it and ActorEndOverlap when it leaves. Overlaps drive automatic behaviour: walk toward the entrance and the doors part on their own, step into a room and its lights come up. You place a box actor across the doorway, size it to the swing area, and wire its overlap event to the door logic. No clicking required - the space simply reacts to your presence, which feels magical in VR.

Choosing between them is a design decision. Clicks give control and are unambiguous - nothing happens by accident. Overlaps give flow and immersion but can surprise people if the volume is too big or badly placed. Many experiences use both: automatic sliding doors on overlap, but a deliberate click to change a finish. Get the trigger right and the rest of the interaction is just deciding what happens next.

Two practical notes make triggers reliable. For clicks, the mesh needs collision that responds to the trace channel your controller uses, and the Player Controller must have click events enabled - otherwise the cursor passes straight through. For overlaps, both the trigger volume and the thing entering it need Generate Overlap Events ticked, or the box stays silent. A robust setup for automatic doors is a Box Collision component built inside the BP_Door class, sized to the approach zone, so the trigger travels with every copy and never has to be placed by hand.

If you wire a click straight to Set Relative Rotation, Yaw = 90, the door works - but it teleports open in a single frame, which looks broken. Real motion happens over time, and the tool for that is the Timeline node. A Timeline is a little animation curve living inside your Blueprint: you give it a length (say 1.5 seconds) and a curve from 0 to 1, and when you play it, it outputs a smoothly changing value every frame for that duration.

You use that output to drive the rotation. The Timeline's value (0 to 1) feeds a Lerp (linear interpolate) between closed (0 degrees) and open (90 degrees), and you feed the result into Set Relative Rotation on the door mesh. Now the door eases open across a second and a half. Shape the curve with ease-in and ease-out and the swing gets a believable weight - slow to start, slow to settle - instead of a mechanical constant speed. This same Timeline pattern animates anything continuous: drawers sliding, blinds lowering, a lamp dimming up.

Timelines also handle the return trip elegantly. Store an IsOpen boolean; on click, check it, and either Play the Timeline forward (open) or Reverse it (close). One Timeline, one boolean, and your door toggles smoothly both ways. Build all of this inside a Blueprint Class called BP_Door - mesh, pivot, click event, Timeline and boolean together - and you have a single reusable door you can drop throughout the building, every copy swinging identically.

A subtlety worth knowing: the Timeline gives you events as well as a value. It fires an Update every frame while playing - where you set the rotation - and a Finished event when it reaches the end, handy for playing a latch sound as the door settles or enabling collision only once it is fully open. Because Reverse re-uses the same curve, an eased door feels equally natural opening and closing from one tidy graph, and a single boolean gate stops a rapid double-click from fighting itself mid-swing.

Lights are the simplest of the three and the most atmospheric. A light in Unreal - a Point Light, Spot Light or Rect Light - exposes properties you can set at runtime from a Blueprint: Intensity, Light Color, and simply Visibility (on or off). A switch, then, is an event that changes one of those. Wire an On Clicked (or overlap) event on a switch actor to a Set Intensity or Set Visibility node targeting the lamp, gate it with an IsOn boolean so each press flips the state, and you have a working switch.

What makes it read well is nuance. Instead of a hard on/off, run the intensity change through a Timeline so the light fades up like a real fixture warming. Change Light Color and you shift a room from warm evening (around 2700K) to neutral daylight (around 4000K) - the exact interior mood decisions covered back in the artificial-lighting lesson, now under the client's finger. You can group several lights so one switch drives a whole scene, or wire a master control that dims everything for a night mode.

A performance note worth carrying: real-time lights are not free. Movable lights that can change at runtime cost more than fully static baked ones, and stacking many dynamic shadow-casting lights eats your frame budget - which matters doubly in VR. So make interactive only the lights that genuinely need to change, keep the rest static, and lean on Lumen's indirect light rather than scattering dozens of movable fixtures. Interactivity and performance are always a negotiation, and lights are where beginners overspend first.

One more honest constraint: changing a light's color or intensity at runtime is cheap, but toggling many shadow-casting Movable lights, or moving them, forces Unreal to update dynamic shadows every frame. A convincing trick is to leave the fixtures static and instead animate the post-process exposure and one or two subtle Rect Lights for the interactive mood shift - you get the feel of the room changing from day to evening without paying for dozens of live shadow casters, which is the difference between a smooth demo and a stuttering one in VR.

The showpiece interaction for interiors is swapping a finish live - oak to walnut, white wall to sage, matte to gloss - while the client watches. There are two clean ways to do it. The blunt one is Set Material: every mesh has one or more material slots (element indices), and a Blueprint node can assign a different material asset to a slot on command. Wire a swatch's click event to Set Material (element 0) = MWalnut_ on the floor mesh, and the floor repaints instantly. Prepare a handful of finished materials and a button per option, and you have a working finish picker.

The more powerful way uses a Dynamic Material Instance. Instead of swapping whole materials, you create one master material with exposed parameters - a base colour, a roughness, a texture - and at runtime you change just those parameters. Click a colour and Set Vector Parameter Value recolours the surface; drag a slider and Set Scalar Parameter Value takes it from matte to gloss. This is exactly the physically based material thinking from Module 3, now driven live: one master, endless variations, no new assets. It is how a real configurator offers dozens of combinations without dozens of separate materials.

Either way, the pattern is the same as the door and the switch: an event (a swatch click) wired to an action (set material or set parameter) on a target mesh. Keep the target as a variable so one swatch can drive the right surface, store the current choice in a variable so you can show or save it later, and you have the seed of the configurator built in the last lesson of this module. Three interactions, one grammar - and the whole experience starts to feel like something the client owns rather than watches.

Keep one variable pointing at the target surface and another holding the current choice, and a single swatch can be reused across rooms while still remembering what each surface shows. That habit - a target reference plus a stored selection - is precisely the scaffolding the configurator in the last lesson expands into dozens of coordinated options.