Building fast scenes

A few habits keep even ambitious scenes fast. Most are settings; all of them compound.

Let quality adapt

In Settings ▸ Viewport Feel, leave Render quality on Auto. It detects each visitor's device and serves a cheaper frame to phones and low-end machines (lower pixel ratio, shadows and antialiasing off) while giving capable machines the full treatment. The low tier also sits out the post-processing look and the sun's god rays and lens flare, which on a weak GPU cost more than everything else in the frame put together; the colour LUT stays. The verdict reads the graphics chip as well as memory and cores, so a tablet with plenty of RAM but a slow fill rate is still served the light frame. iPhones and iPads get a tier of their own, phone: Safari doesn't report memory, so they used to be mistaken for desktops and crash under WebKit's lower memory ceiling. The phone tier keeps the post-processing look and shadows but renders at a slightly lower pixel ratio, gives each room two shadow-casting lights, halves particle counts and decodes one model at a time. A slow connection or Save-Data only shrinks what the visitor downloads (textures, resident pictures, particles); it no longer costs them shadows or the post look, since bandwidth has nothing to do with frame rate. Pinning Render quality to High overrides all of it, on every device, if the look matters more than the frame rate.

Use level-of-detail

Enable low-poly LOD so distant objects automatically swap to cheaper geometry. Set the switch distance to taste.

Spread the site into neighborhoods

Put your content under page nodes placed well apart (tens of metres, not a few) and a published visitor only downloads the models near them, with the rest arriving as they travel. It's the single biggest lever on how long a big scene takes to start, and it costs you nothing but layout. See how a published scene loads, and check the split in the Scene Weight window.

Then bind each room's objects to its page, which is the frame-rate half of the same idea: a bound room stops being drawn while the visitor is elsewhere, instead of merely arriving late. It's also the only way a fifth or sixth room gets shadows.

Keep models light

• Decimate heavy imported models, especially anything you place many times.
• When you generate fill objects, ask for the low tier.
• Repeated objects are instanced automatically (see Reuse parts to instance below): each copy still carries its own triangles, so low-poly source models matter.
• For set dressing you'll place several of, check whether the public library already has a cheap version. The -lowpoly picture frames are the clearest example: same silhouette as the sculpted ones, a hundred triangles and no textures instead of tens of megabytes each.

Reuse parts to instance a whole scene

Instancing is automatic, and it's the single biggest lever for large scenes. Any time the same model is placed two or more times, every copy collapses into one GPU batch, so your draw-call cost tracks the number of distinct models, not the number of copies. A forest of 500 trees built from a dozen shared parts still draws roughly like a dozen parts. It works the same in the editor and on the published site.

• Share the source. Duplicate an existing object, or place the same library / generated asset again: copies that point at the same model batch together. Two objects that merely look alike but were imported separately do not.
• Group freely. Batching looks at the model, not the outliner: identical parts nested inside different groups (say, the trunk and canopy blobs of every tree) still instance together across the whole scene.
• Vary each copy for free. Position, rotation, scale, and a per-copy tint all stay inside the one draw call, so a batch never has to look copy-pasted.
• One-offs aren't batched. A model placed a single time renders on its own, no penalty, just no saving. The win starts at the second copy.
• Nor are moving copies. A copy carrying its own animation steps out of the batch and draws separately, so animate a few focal objects rather than a whole forest.
• Nor are room-scoped copies. A copy bound to a neighborhood draws on its own, because unloading it when the visitor leaves the room is worth more than sharing a draw call with the rooms they are not in. A room full of identical props is the best batching candidate there is and the best scoping candidate: scoping wins, and the props unload.
• Primitives batch too, on the published site. Boxes, spheres, planes, cylinders and tori that share one shape (the same dimensions, segment counts and cuts) and one material draw as a single batch: a wall of two hundred identical bricks is one draw call, and the weight meter credits it. Vary copies with position, rotation and the object's scale; changing a brick's width or its material starts a new batch. Bricks inside a room-scoped group batch as that room's own set, so they still switch off with the room. The editor draws every primitive on its own so selection, hover and component editing keep working per object.

Let your models ship smaller textures

The textures baked inside a downloaded or AI-generated model are usually 2048 or 4096 pixels square, far more than a phone can show, and the biggest single reason a scene kills a mobile tab. 3dCMS handles this in two places, and you don't have to do anything for either:

• A pre-shrunk copy of each model. Your Asset Library builds a 1024-pixel twin of every model you own (at upload time for anything you upload, on the server for AI and MCP generations, and in a background sweep for older models), the server adds a 2048-pixel one, and phones and tablets download the twin that fits instead of the original. A model whose textures are already that small is simply served as itself. Desktops keep the full-resolution file, so what you author is what you see. See Shrinking model textures.
• Sharpen on approach. A phone loads every model at 1024, then swaps the 2048 textures onto the one model nearest the camera, releasing the previous one as the visitor moves on, so the thing they walk up to looks crisp without the whole scene paying for it. It waits until every model has arrived, and never runs on a slow link, with Save-Data on, or on an Android phone with under 4 GB of memory.
• A cap at load time. Whatever file arrives, oversized textures are scaled down to the device's limit before they reach the GPU: 4096 on desktop, 2048 on a capable phone or tablet, 1024 on iPhones, low-end devices, and Android phones with 4 GB or less or a budget graphics chip. Forcing a tier is the Render quality setting in Settings ▸ Viewport Feel.

The one thing left to you is not using a 4K model where a 1K one would do, and reusing models instead of importing near-identical ones, since texture memory is charged per unique model, not per copy.

Cap textures on mobile

For image-heavy scenes (think a big website import), the Max image textures setting limits how many pictures stay in GPU memory at once: the rest stream in and out as the camera moves. It's the single most important knob for keeping phones happy.