3dCMS Knowledge Base
Open the editor
Performance

Building fast scenes

The handful of habits (render quality, LOD, instancing, decimation, texture caps) that keep big scenes running smoothly.

Open in the interactive manual →

The interactive version has full-text search, a table of contents, and light/dark themes.


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.

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.
Build a kit, not a scene For anything you want a lot of (trees, rocks, crowd props, fences), model a small kit of reusable low-poly pieces once, then assemble and repeat. You get endless variety from transforms and tints while the GPU only ever sees the handful of source parts. That's the pattern behind every performant large scene in 3dCMS.

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, and in a background sweep for older models and AI generations), and phones and tablets download that file instead of the original. Desktops keep the full-resolution one, so what you author is what you see. See Shrinking model textures.
  • 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 typical phone, 1024 on a low-end one. 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.

Optimize the heaviest first Run the compatibility check, look at the "heaviest nodes" list, and fix the top one or two. A scene's cost is rarely spread evenly: a single over-detailed model is often the whole problem.
Spotted something off, or want a topic covered? Email hello@3dcms.info.