Exploring a published scene
The visitor's-eye view: how people move through your 3D site on desktop and mobile, and the controls they get for free.
Open in the interactive manual →The interactive version has full-text search, a table of contents, and light/dark themes.
When someone opens your published link, they land in the consumer view, a clean, fullscreen experience with no editor chrome. You can see exactly what they'll see with File ▸ Preview.
The loading screen
3D scenes take a moment to arrive, so the first thing a visitor sees is a branded loading screen rather than a blank canvas. It carries:
- A determinate progress bar with a percentage, so the wait has a visible end. It never jumps backwards, and it gives up gracefully rather than hanging if something is slow.
- Your scene's name, so people know they're in the right place.
- A "how to move around" row tailored to the device it's actually running on: on a desktop it leads with Click objects to explore, then drag-to-look and scroll-to-zoom; on a touch screen it's tap, one finger to tumble, two to pan, pinch to zoom. Visitors arrive already knowing what to do.
- A card showing a real model from the 3dCMS asset library, and a small 3dCMS mark, quiet branding while the scene streams in.
If your scene uses corner joysticks for touch, the loader adds a line pointing them out, so nobody spends their first ten seconds hunting for the controls. The editor shows the same loader when you open a scene, with the editor's own Alt-drag camera hints instead.
Moving around
| Platform | Controls |
|---|---|
| Desktop | Drag to look around and move through the scene; on-screen hints point the way. |
| Keyboard | W A S D pan the camera, on every scene including single-page ones. The keys stand down while you type in a field and whenever a modifier is held, so Ctrl+S, Ctrl+D and Ctrl+A still reach the browser instead of nudging the camera. See accessibility. |
| Mobile | Drag to orbit, swipe ← → to move between pages, and swipe up (when zoomed) to open a page's gallery. |
Page-stepping (the mobile swipe and the desktop ← → keys) belongs to multi-page scenes. In a single-page scene those gestures do nothing at all, and the on-screen hint stops advertising them, so nobody swipes at a site with nowhere to swipe to. A quick one-finger flick that swings the camera more than about 15 degrees is a look, not a page change, so glancing round a room never flies anyone off to the next one, and Alt+← (the browser's own Back) is left to the browser. A stylus counts as a mouse for all of this.
Panning follows the shape of the scene. W/S and a middle-button drag move along the ground in a scene laid out across the floor (a room, a landscape), so holding a key walks the visitor through the space instead of lifting them into the sky or under the floor. A scene stacked up the vertical, a tall wall of panels read top to bottom like a page, pans up and down the screen instead, the way it scrolls. 3dCMS reads which one it is from where the content sits; there is nothing to set. A two-finger drag on a phone or tablet always pans with the fingers, left, right, up and down on the screen, the way every 3D viewer does, whatever shape the scene is.
Zoom never hits a wall. Scroll and pinch used to stop dead a short way in front of whatever the orbit pivot sat on, so a sign standing in front of a model meant you could never zoom past the sign to the model. Now, when the camera reaches that point, the pivot moves on ahead along the view and the same gesture keeps travelling forward, on every scene and every input. A visitor who wanders well out past the framing, or zooms into an object, gets a ✕ that returns to the default view.
No flight holds a visitor hostage. A flight to a page or viewpoint lasts at most eight seconds whatever pacing the author chose, and a real drag, a scroll or a movement key lands it on its destination at once; a plain tap does not, so the sign that started the flight cannot cancel it.
New scenes ship with Corner joysticks on: visitors get a Move stick and a Look stick, and the one-finger orbit and pinch in the table above keep working alongside them. Touch input mode in Settings ▸ Mobile & Touch offers other answers to "what does a finger do here": Gestures removes the sticks, and:
- Corner joysticks: an FPS-style pair of sticks, "Move" on the left and "Look" on the right.
- Guided scroll: a swipe up steps to the next section, the way a 2D page would, and dragging sideways looks around.
- Page scroll (1-finger swipe pans): one finger drags the view up and down the way a 2D site scrolls on a phone, and two fingers pinch. It is for a scene that is a page (a wall of panels) rather than a place you walk around. A scene left on auto that reads as a page stacked top to bottom gets this behaviour on its own.
- Auto: page scroll for a scene whose pages stack top to bottom, gestures for a room. It now has its own entry in the menu, so a scene left on auto shows as Auto rather than as Gestures.
Tapping things
Objects you've given a tap action respond when a visitor taps them: opening in a fullscreen viewer, flying the camera over, or following a link. The cursor turns into a pointer over anything tappable, so people find them without a hint. Everything else stays scenery: a click on it does nothing.
Back and forward
A ← → pair sits at the top left of every visit: in the header bar on desktop, and at the left end of the slim top bar on phones and in embedded scenes, where there's no header to put it in. Both buttons are always there and simply grey out when there's nowhere to go, so a visitor looking for "how do I get back" finds the control in the same place either way. The arrows are drawn with a heavy head rather than set as a text glyph, so they stay legible as arrows over a bright or busy scene.
They work like the browser's own controls, but for your scene: Back returns to the previous page and the exact camera pose the visitor was at, so a tap-to-travel trip or a viewpoint jump is always reversible, and Forward flies them back to where they'd travelled. Forward is deliberately cautious: when 3dCMS can't be sure there's a view ahead it leaves the button greyed rather than offering one that does nothing. (The browser's own Back and Forward keep working regardless: these are the same history, just reachable without the browser chrome.)
The visitor's toolbar
On desktop the controls sit in a slim header along the top of the page. On phones and in embedded scenes there's no room for a header, so the same controls collapse onto one quiet translucent top bar: back / forward at the left, the 3dCMS brand pill centred on the bar, and a Menu pill at the right that opens the rest. Either way, visitors get:
Knowing which page you're standing in
A multi-page scene tells visitors where they are. On desktop that's a small card docked in the header: the page name, a hint line about the links leading out of this page, and a chevron that opens them.
On a phone, and in an embed, that card would sit over a good fifth of a 390px screen, and the scene is the whole point. So the same control becomes a full-bleed banner flush under the top bar, reading as a second row of the same chrome: a third of the bar's height, carrying the site's name in bold and then the page's own title. On the home page, whose title usually is the site name, it says it once. Everything that doesn't fit on one line is dropped rather than crammed, and nothing is stranded: the pager at the bottom steps between pages and Menu opens the full page list. Tapping the banner still drops the links panel, now the full width of the screen.
In the desktop header the everyday actions are compact icons, because they sit in a row where five written labels would swamp it. Stacked inside the mobile Menu they'd be a column of bare glyphs instead, so there each row carries a written label ("Mute sound", "Search pages", "Fullscreen") on one shared row shape.
Share ↗ opens a small dialog with the page's link ready to copy, a QR code to point a phone at, and the same one-click share targets a creator gets, so a visitor who wants to pass your scene on doesn't have to fish the URL out of the address bar. It shares exactly where they are, page and all, minus any preview or measurement switches in the URL. If they're standing at a saved viewpoint, that survives too: a #view/<slug> link is the one spatial anchor a visitor can pass on, so "look at it from here" is shareable through the product's own share button.
A creator can put the same action inside the scene: a sign or tappable object whose URL is #share becomes a "send this to someone" button. On a phone, Safari or Edge it opens the device's native share sheet with the current page; elsewhere, or if the sheet fails, it opens this dialog. Dismissing the sheet just closes it.
The screen-space version of that sign is the share badge: a round button pinned to the bottom-right corner of the published view, so it is in reach whatever room the visitor is in and it never bends under lens distortion the way a 3D sign can. Its words run around the rim and turn slowly (they hold still for a reduced-motion visitor), the share mark sits in the middle, and a tap takes the same route as a #share sign. Switch it on in Settings ▸ Visitor Chrome ▸ Share badge, where you also pick its colour and the words on the rim (up to 40 characters; the default is Share this, and a screen reader announces the same words). It stacks itself above the right joystick pad or an on-scene guestbook pill rather than covering either. Off by default.
Its bottom-left twin is the action badge: a round link that sends the visitor somewhere, such as a sign-up page, a booking form or a shop. It is a little smaller than the share badge with bigger words, because the words are the button: a short label set large in the middle (up to 24 characters, split over two lines at most; the default is Sign up), and an optional line that turns around the rim (up to 40). Switch it on under Settings ▸ Visitor Chrome ▸ Action badge and fill in Action link: a full https address, a mailto:, or a path on your own site like /pricing. Anything else is refused, and the badge stays hidden until the link is set. It is a real link, so a screen reader announces it and a middle click opens a new tab; inside an embed it always opens a new tab. It stacks above the left joystick pad. Badge style sets the disc of both badges: dark (the default) for a dark scene, or a white disc for a light one.
Mute is remembered. The mute toggle is a fact about the person, not about one scene, so a visitor who silences a scene stays silenced, across page navigations, across visits, and across every 3dCMS site they open. Unmuting is equally sticky. (In a private window where storage is blocked it holds for the session instead.)
On a genuinely public visit the desktop header also carries a small "Made with 3dCMS" credit linking to the Explore gallery, an unobtrusive way for a visitor who likes your scene to discover more. It's shown only on published visits, never in your own draft preview. The compact top bar shows the 3dCMS brand pill in its place, on phones and in embeds alike; in an embed that pill opens your scene full-size and is joined by a Build your own → link. A paid plan hides all of them.
The next few pages cover the standouts: guided scroll, the tour, the search palette, visitor reactions, and the accessibility defaults.