The Construct editor renders its 3D viewport on a dedicated worker thread with its own GPU context — this is the default. Shader compiles and heavy frames never block the UI: panels, menus and the scene tree stay responsive even while a complex model rebuilds its shaders, and the editor opens to an interactive window in about a second.
A classic (inline) mode remains available, where the scene renders on the GUI thread inside the editor window's own graphics context. It exists as a comparison baseline and as the automatic fallback path.
Both modes render the same things the same way — SDF models, imported and baked meshes, frozen (proxied) items, tet volumes, the export-bounds preview, selection and hover highlights, gizmos and every render setting. Parity is enforced by an automated suite that renders identical scenes through both paths and compares them pixel for pixel.
On a cold start the first frame waits for the shader compile. Until it lands, the viewport shows the placeholder color of the active environment. For the default gradient that is the color behind the model, not black.
The 3D view answers the mouse the same way in both modes. To cut the view open and inspect an interior, use a bounding volume's cutaway — see Inspect interiors with cutaway and the onion.
| Gesture | What it does |
|---|---|
| Left-click | Select the item under the cursor. Clicking empty space clears the selection |
| Left-drag on a gizmo handle | Move, rotate or scale the selected item |
| Right-click | Open the item menu for whatever is under the cursor — the same menu the scene tree offers for that item |
| Right-drag | Look around |
| Wheel | Zoom |
Right-click and right-drag are told apart by the same threshold that decides a click from a drag anywhere else in the viewport, so the two can never disagree about what you just did: a right button pressed and released without travelling opens the menu, and one that travels looks around instead.
The item menu needs a target, so it opens only over an item — the one already highlighted under your cursor. Right-clicking empty space does nothing. Selection is not changed by a right-click: the item under the cursor is already highlighted, so the menu's target is unambiguous without a click that has side effects you did not ask for.
It sits with the machine-local settings rather than with a scene's look because that is what it is: which renderer this computer uses. A document never carries it, so opening someone else's scene cannot change which renderer you are running.
The switch is live — no restart, no scene reload. Your camera, selection and render settings carry over, and switching back is just as seamless. The setting persists across sessions. While the worker viewport is active the inline renderer stays dormant (it compiles nothing); turning the worker off revives it on the spot.
The first time a given app version starts on a machine, the worker compiles its render pipelines in the background — the window is interactive immediately, and the first rendered frame follows a few seconds later. The compiled pipelines are cached on disk, so every later start skips that wait and the first frame arrives almost instantly.
Clicks and hover highlights are answered by reading back the frame the GPU last drew. When that readback is unavailable — the graphics device was lost, the worker is mid-restart, or no frame has been drawn yet — the viewport has no answer, and it deliberately does nothing rather than guess.
Two failures look alike from the outside, and telling them apart is the most useful thing you can put in a bug report:
| What you see | What it means |
|---|---|
| Clicking selects nothing, and clicking empty space clears the selection | The viewport answered. You missed the item — a genuine miss |
| Clicking does nothing at all: the selection neither changes nor clears | The viewport had no answer. The readback was unavailable |
The two figures under Viewport interaction show what a working selection and a working hover look like. If clicking an item leaves it looking like the left-hand frame of the first one, the pick resolved nothing — which is the first case in the table, not the second.
The second case is deliberate. Treating no answer as you clicked the background would clear your selection on every click while the GPU was in trouble, turning a read failure into lost work. A viewport that cannot see therefore reports nothing, and your selection survives untouched.
It says so in the log. Every unavailable pick writes one line, tagged
[§CIE-C1]:
[§CIE-C1] pick readback unavailable at QPoint(412,233) — no selection change reported
If you see that tag, the viewport is not ignoring you — it is telling you it could not look. Hover deliberately stays quiet (it fires on every mouse move and would bury the log), so the pick line is the one to search for; it reports the same underlying failure, once per click. Include it when you report the problem. Switching to the classic viewport in Preferences is the quickest way to find out whether the worker is the cause.
The first launch on a machine bakes the viewport's shaders once. The header progress indicator shows the bake while the editor stays responsive. Later launches load the baked result from the cache and skip the wait.