Cameras & saved views

"Camera" means two different things in 3dCMS, and keeping them straight saves confusion:

• Saved views are your working camera bookmarks while editing (the 1–4 slots, see Moving around the viewport).
• Camera objects are nodes in the scene that define the viewpoint your visitors start from when they open the published page.

This article is about the second kind.

Adding and aiming a camera

Create a camera with Create ▸ Camera, then position it like any object. The Properties panel's Camera section gives you:

• Set Active Preview Camera: makes this the scene's active viewpoint. The active camera is where the published page (and the consumer preview) opens.
• View from camera: snaps your editor view to look through it, so you can frame the shot.
• Align to viewport: moves the camera to match your current editor view (frame it by eye, then lock it in).

One camera position is a different picture on every screen: a wall composed to fill a desktop shows a sliver of itself on a phone held upright. A camera can instead declare how many metres wide its view must be (fitWidth, set through Claude or the Assistant). The visitor's camera then slides forward or back along its own line of sight until that width fits the screen, keeping the direction and the orbit pivot. It applies on arrival, when flying to a page, on a #view deep link, and from a viewpoint sign. Cameras without it are untouched.

By default that width is exact, so a wide desktop screen slides the eye closer as well as a phone sliding it back. Inside a room that can go wrong: a room page's pivot often sits behind the back wall, so pushing in lands a desktop visitor half a metre from the canvas. Set fitWidthMode to "min" on the camera and the width becomes a floor: a narrower screen still backs up until it fits, and a wider one keeps your composed pose exactly. Cameras without it frame as before.

Lens controls

The viewpoint a page drops you at

When a visitor navigates to a page in a published scene, the camera flies to an auto-framed pose: far enough back to see the whole page node. That is always correct and always generic: it has no idea which side of a room you meant them to walk in from.

A page can name a camera to arrive at instead. Select the page, and in the Page Surface section of Properties pick one from Arrive at viewpoint, a dropdown listing every camera in the scene, with Auto-frame (default) at the top. Every route into that page (a link sign, a deep link to /3d/<slug>, the page tour's next, even the browser Back button) then lands on that composed shot. Reset view returns there too, rather than to a frame the visitor never saw.

• It goes on the page, not on the signs. One field covers every way in. Aiming individual link signs at a viewpoint instead would fix only the doors, and would leave the URL and page title describing the room the visitor just left.
• Empty is the default, and keeps the existing auto-frame exactly: nothing changes for a scene that never sets it.
• It fails safe. If the id doesn't resolve, doesn't point at a camera, or holds a nonsense pose, the page falls back to auto-framing. Delete the camera it names and the dropdown says so, ⚠ missing viewpoint (auto-framing), rather than quietly resetting itself, because losing the reference is how you find out the camera is gone.
• The lens comes with it. The camera's field of view is honoured on arrival, so a 20° telephoto shot arrives as a telephoto shot, not re-rendered at the default 42°.
• A deep link paints it directly. Opening /3d/<slug> renders the composed shot on the first frame rather than framing the generic view and then swooping to it.
• It doesn't read as "zoomed in". Arriving at a close viewpoint used to leave the runtime believing the visitor had zoomed into something, which stalled guided scroll, showed a Return-to-default-view ✕ that did nothing, and nudged the camera back off the shot. The framing now sets the reference distance, so an arrival pose is simply where home is.
• The room lights itself. Neighborhood scoping follows the camera, so arriving at a viewpoint deep inside a room switches that room on as normal, and the page you navigated to holds the room even when a neighbour's centre happens to be nearer.
• A visitor can zoom in from it. Arriving at a viewpoint composed well back from a page used to hit an invisible wall: scroll or pinch moved you toward a point a fixed 2.5 m in front of the camera, which for a shot 20 m out was empty air, so you stopped short of the board you were trying to read. Zooming now pulls toward the page the camera belongs to (and for an entry camera that sits at the scene root rather than under a page, toward the nearest thing it is actually looking at: a hero model, a board, never a light or another camera), and the close limit dropped from 1.2 m to 0.35 m. Even that is not a wall any more: keep zooming at the limit and the camera carries on forward, past a sign to what stands behind it. Your composed shot is untouched: only how near a visitor may get from it changed.

The Assistant and Claude over MCP can set it too: ask them to give a page an arrival camera, and they can create the camera and wire it in the same turn.

Orbiting stops at walls (opt-in)

By default a visitor orbiting on the published page can swing the camera out through a room's walls or ceiling, which is usually what lets them back out to see the whole space. A page can ask for the opposite: set data.wallCollision to true on that page's arrival camera (or cameraWallCollision in the scene's viewport settings, for every page at once) and the camera holds just inside the nearest wall, floor or ceiling instead, then eases back out to where the visitor wanted to be once the way is clear. Only big solid surfaces count: props, signs, glass and imported models (a picture frame, a canvas, a statue) never stop it, and anything right next to the orbit pivot, such as the picture being looked at or the wall directly behind it, is ignored so an arrival never snaps onto the subject. It stands down during page flights and camera rides. Switch it on for the whole scene with Orbit stops at walls in Settings ▸ Viewport Feel, or per page through the Assistant or MCP; a room with enough space around its subject rarely needs it.

To leave one way out, mark a wall as passable: data.cameraPass set to true on a wall's geometry node keeps that surface open to the orbit while every other wall still stops it, so a visitor can always back out of the room through, say, its open front. In the editor, select the wall and tick Camera passes through in the Inspector, or set it through the Assistant or MCP.

Threading a doorway: arrivals with legs

A flight is a straight line between two viewpoints, and a straight line into a room behind a wall goes through the wall. A camera can name the viewpoints a flight to it should pass through first, in order (data.viaCameraIds, up to eight): put one camera in the doorway aimed into the room, name it on the arrival camera, and every route to that camera, a page arrival, a link sign, a deep link, rides one smooth curve through the door instead of the wall. The flight takes longer in proportion to the longer path and skips the mid-flight bow, since the legs were placed to fit under a lintel; a via camera's own legs are not followed, so two cameras naming each other cannot loop; a leg that names a deleted camera is skipped and flagged. A camera can also carry its own pacing: data.travelScale (0.25 to 4) multiplies the scene-wide Flight length below for every flight that ends at that viewpoint, so a hero room gets a slow reveal at 2 while a side alcove is a quick hop at 0.5. Today both fields are set through the Assistant or MCP; browser Back restores an exact pose and flies straight, as before.

How the flight feels

Every camera move a visitor makes is a flight rather than a cut, and three settings in Settings ▸ Selection + Visual Feedback (type "camera easing" into the Settings search to jump there) shape all of them at once: tapping a link sign, the bottom pager, the guided rail and keyboard, the browser Back button, opening a shared deep link, and tapping an object to fly to it.

The editor previews all three: composing a move against the same curve and the same duration your visitors get is the point of it living on the scene rather than on individual link signs. Whatever the curve, a flight always lands exactly on the pose you composed.

A camera that rides a curve

A camera can be put on a curve the same way an object follows a path: select the camera and, in its Ride section of Properties, set Motion to Ride a path and pick the curve. From then on every flight that lands on that viewpoint, a page arrival, a link sign, a shared #view link, the entry camera on first load, ends at the curve's start and the visitor's camera rides the curve from there: a slow pass along a gallery wall, a fly-round of a building, a dolly into a room. The camera's own Position and Rotation no longer say where visitors start (the note under Transform says so, and the move gizmo stands down; drag the curve's control points instead). View from camera takes your editor eye to the start of the ride, and Align to viewport reminds you that only a Keep its rotation ride keeps the heading you set.

• Facing: Along the path looks down the curve, Toward a point keeps one spot framed while the camera circles it, Keep its rotation holds the heading the visitor arrived with. There is no Front or Up for a camera: its lens leads.
• Pacing, Start along the curve, Ride it backwards, Duration, Loop, Delay: as for an object ride. On an open curve pick Once or Back and forth (or tick Closed on the curve): a plain Loop cuts the visitor back to the start every lap, and the panel and the scene check both say so. Back and forth turns the camera round on the return leg rather than backing up.
• Ride ends on: what hands control back. Any input (the default) ends the ride on a drag, a wheel, a key or a tap. Movement only ends it on a drag, a wheel or a movement key (WASD, arrows, Page Up and Down), so a tap on a sign still navigates and a stray click does not stop the ride. Nothing keeps the visitor on the rail until a Once ride reaches its end or they navigate somewhere else; the orbit controls are off for the length of it. Over MCP this is data.rideBreak: any, move or none.

A ride that plays Once leaves the visitor free at its end pose. Any navigation always ends a ride; a tab left in the background pauses it rather than skipping to the end; a stray wobble on a tap still counts as a tap. Tick Play in the editor viewport to preview it: the camera marker rides the curve when the View menu shows camera markers and the camera is not the one selected. The curve itself is a helper on the published site, drawn only if you turn on Show on the published site in the curve's Inspector, and it costs nothing against the scene weight unless you do. The Assistant and Claude over MCP can build the same thing in one turn: make the curve, make the camera, put the camera on the curve.

Where visitors spawn: the Entry point

A scene has exactly one spawn point, and you can put it on either kind of node:

• Select a camera and click Set as Entry Camera in the Camera section of Properties. Once set, the button reads ★ Entry Camera (visitors spawn here).
• Select a page surface and click Set as Entry page at the top of its Page Surface section. Visitors then open the scene framing that page.

The two share one slot: flagging either clears whatever held it before, so you can never end up with two competing spawns. Should a scene arrive carrying both anyway (one built over MCP, say, or an older save), the camera wins, whichever comes first in the tree: a composed shot beats an auto-frame. Both outrank the editor camera captured at publish time, and a pinned Settings ▸ Visitor Spawn outranks both.

An Entry page also decides what the bare site URL is about. Its title becomes the browser title, its description and canonical go into the page's <head>, and its words are what the crawlable scaffold, the plain-text view, llms.txt and the sitemap all present as the root document, along with the HUD label and the page menu. With no Entry page set, the root URL means the page flagged as home, or failing that the first page in the scene. So the marker moves the whole document rather than just the camera: the page a visitor lands on and the page a crawler is told about stay the same page.

Idle camera drift

A camera that sits perfectly still reads as slightly dead: real footage always has a little life in it. Settings ▸ Viewport Feel ▸ Idle camera motion adds a subtle handheld float to the camera in your published scene: a slow, layered drift of a few centimetres that never quite repeats.

The slider runs from 0 (off, the default) to 3. Around 1 the movement is small and gentle; 3 is a real handheld sway. For the jitter of a camera in someone's hands, add Camera shake (0 to 1) just below it: faster, jerkier motion with a slight tilt, on top of the drift. Both fade out the instant a visitor starts moving the camera themselves and ease back in once they let go, so they never fight their input, and both are switched off entirely when reduced motion is in effect, whether that's the visitor's own system setting or the scene's reduce-motion toggle. It affects the published view only; your editor camera stays rock steady.