Menus, UI & Design Options

UMG (Unreal Motion Graphics) is Unreal's system for building user interfaces - the menus, buttons, text, sliders and panels that sit on top of the 3D scene. You build a UI in a special asset called a Widget Blueprint, which has two halves: a Designer tab where you lay out the interface visually by dragging elements onto a canvas, and a Graph tab where you wire up what those elements do - the same node graph you already know.

The building blocks are widgets: a Button the user clicks, a Text block for labels, an Image for a swatch or thumbnail, a Slider for continuous values, a Progress Bar for a loading state. You arrange them inside layout containers - a Canvas Panel for free placement, a Vertical Box or Horizontal Box to stack them neatly, a Grid for a matrix of options. This nesting forms a hierarchy: a root panel holding boxes holding buttons, exactly like nesting frames in a design tool.

Crucially, a UMG interface is resolution-independent when you use anchors - you pin elements to edges or centres so the menu stays correctly placed whether the client runs it on a laptop, a big presentation screen or a projector. Get the hierarchy and anchoring right and your menu looks deliberate on any display. This is the same discipline as laying out a drawing sheet: a clear grid, aligned elements, room to breathe.

Worth naming the layout logic: a Canvas Panel places children by absolute position and anchor, which is flexible but easy to misalign, while box and grid panels arrange their children automatically so everything stays tidy as you add or remove buttons. Inside a box you control spacing with padding and each child's size rule - Auto to fit its content, or Fill to share the space. Build menus from boxes and grids, reaching for the raw Canvas only for a few free-floating elements like a corner logo, and you save hours of nudging pixels.

Here is the payoff of everything you have built: a UMG Button exposes an On Clicked event, and that is identical in spirit to the On Clicked you wired on a door. In the widget's Graph tab you bind each button to an event, and from there you call whatever action you like - swap a material, toggle a light, play a door, jump to another view. A button labelled Scheme B simply fires Apply Scheme B, which runs the material swaps and light changes you already made. The menu is a remote control; the scene is the appliance.

The one new skill is talking between the widget and the world. The button lives in the UI; the wall it needs to repaint lives in the level. You bridge them by getting a reference - often via the Player Controller, a Game Instance, or by passing the actor into the widget when you create it - so the button's event can reach the right mesh. A clean pattern is to keep the actual interaction logic in the level or an actor, and have the widget button just call it, so your UI stays a thin layer of triggers over logic you have already tested.

Because buttons are events, everything you know transfers. Want a button to look pressed, or to grey out when unavailable? That is state on a variable, the same as IsOpen. Want the current choice highlighted? Read the stored selection and tint the active button. The menu is not a separate discipline - it is the same event-then-action wiring, now with a label a client can read.

There is a cleaner architecture worth adopting early: Event Dispatchers. Instead of the widget reaching into the level, the button broadcasts an event - say OnSchemeChosen with the chosen index - and whatever cares (the room, a manager actor) binds to it and responds. This keeps the UI ignorant of the scene's internals, so you can redesign the menu without touching interaction logic, and several things can react to one press. It is the difference between a menu welded to one room and one you can drop into any project.

Building a widget does not display it; you have to create it and add it to the screen. The standard pattern lives in the Level Blueprint or a controller: on BeginPlay, use Create Widget (choosing your Widget Blueprint class) and then Add to Viewport. Now the menu appears, layered over the 3D view - your HUD (heads-up display). Remove it with Remove from Parent when you want it gone, for example while the client is walking freely and you want an unobstructed view.

A good archviz HUD is restrained. A permanent corner panel might hold just the essentials - a finishes button, a day/night toggle, a floor selector - while heavier menus appear only when summoned. You control the mouse experience too: in a menu-driven presentation you often want the cursor visible and the input mode set so clicks hit the UI, whereas during free walking you hide the cursor and capture the mouse for camera look. Set Input Mode (Game, UI, or Game-and-UI) and Show Mouse Cursor are the nodes that switch between navigating and operating the menu.

Think of the HUD as the frame around the experience. Too much UI and the architecture disappears behind chrome; too little and the client cannot find the controls. The craft is a quiet, legible panel - good type, clear labels, generous spacing, consistent placement - that says here is what you can change without ever competing with the space itself. The same editorial restraint you bring to a portfolio sheet belongs on the HUD.

Input mode deserves a concrete recipe. For a menu-driven kiosk, call Set Input Mode: UI Only with Show Mouse Cursor true, so every click lands on a widget and the camera holds still. For a free walkthrough with an occasional panel, use Game and UI so the mouse can both look around and click buttons. Switching cleanly between these two modes as menus open and close is what separates a HUD that feels solid from one where clicks mysteriously do nothing.

With widgets, events and a HUD in hand, you can build the thing clients actually love: a menu that lets them explore the design on their own terms. The three most useful patterns in archviz are option pickers, scene navigation, and view jumps. An option picker is a row or grid of buttons - finishes, furniture layouts, lighting moods - each wired to the swaps from the previous lesson, with the active choice highlighted so the client always knows where they are. A scene selector lets them move between spaces or storeys - Living / Kitchen / Bedroom, or Ground / First - by teleporting the camera to preset viewpoints or loading a different level. View jumps offer curated hero angles, a gentle guide for a client who does not want to fly the camera themselves.

Good menu design here borrows from product UX. Keep the top level short - a client should grasp the choices in a glance. Group related options and label them plainly. Give feedback: the selected finish button stays highlighted, a chosen scene animates the camera rather than cutting jarringly. And always leave an obvious way back to free walking, so the menu guides without trapping. A confused client blames the design, not the interface.

This is also where a presentation becomes a product. A well-made menu turns your interactive scene into something a client can be handed - at a meeting, on a kiosk, or (with Module 8) inside a VR headset where the menu floats as a panel they poke with a controller. The last lesson of this module takes these menus one step further into a full configurator; here you have learned the piece that makes any of it usable: a clean, legible interface wired to the interactions you already own.

For scene navigation, prefer a smooth camera move between saved viewpoints over a hard cut - a short Timeline that blends the camera's location and rotation reads as guided rather than jarring, and it keeps a client oriented. Store the preset views as an array of transforms, and a Next/Previous pair of buttons steps through them: a gentle tour for anyone who does not want to fly the camera themselves, without ever taking control fully out of their hands.