3dCMS Knowledge Base
Open the editor
Performance

Scene weight

One number for how expensive your scene is, broken down by what is costing you, ranked by which objects are the cost, and the only performance measure that can block a publish.

Open in the interactive manual →

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


Scene weight boils a whole scene down to a single score in points, then shows you which parts of it earned those points. It's the fastest read on "is this scene too much?", and unlike the other tools on this page it has teeth: an extremely heavy scene can be refused at publish time.

Where to see it

  • The Scene Weight window (Windows ▸ Scene Weight, or the command palette), the full breakdown: what a visitor pays on arrival, what waits, and every object ranked by cost. Described below.
  • Scene stats (Viewport menu): the meter sits under the live vertex/poly/draw counts and updates as you build.
  • The publish dialog: the same meter, so you see the score at the moment it matters.

The meter itself carries a second marker beyond the red line: a publish limit tick at the hard cap, the free plan's 200 points, or whatever cap your account actually has. It only appears once your scene has passed the red line (a limit advertised to a 12-point starter scene is noise), and once you are actually over it, a line under the meter says so in words and names the paid-plan escape. Because it lives on the meter rather than in one panel, it shows up everywhere the meter does, /try included, so nobody meets the cap for the first time in a refusal dialog after signing up.

The marker follows your plan. On a paid plan, which has no points cap, the tick and the sentence are simply absent rather than quoting a free-plan number that can't refuse you. And the meter shown in the Share dialog never carries them at all: that dialog only opens on a successful publish, so the scene it's describing is already live.

Reading the score

ScoreWhat it means
Up to 45: lightShould run well everywhere, including older phones.
45 to 100: moderateFine on desktops and recent phones; older or low-end devices may drop frames.
Over 100: heavyPast the red line. Still usable on strong devices, but expect problems on phones and slow loads. The biggest bars are the cheapest wins.

The meter is stacked: each band is one category, sized by what it contributes, biggest first, so the bar itself tells you what to trim. The categories are Geometry (triangles), Draw calls, Shadows, Textures, Particles, Volumetric beams, Animation, Lights, Video, Post-processing, Scene data, and Nodes, each with the count behind it.

Shadows multiply everything else A shadow-casting light re-renders your geometry an extra time, so its cost scales with the scene you already have. What it's charged on is the size of the shadow map, not the number of passes: a point light draws a six-sided cube map and costs about 1.6 extra renders of your scene, where a spot costs 1.0. If Shadows is your biggest band, turning shadows off on one lamp (or making it a spot instead of a point) is usually the cheapest big win. Instancing is the other one: it cuts draw calls without you deleting anything.
The first animated object costs more than the next ten Animation is charged as a flat starting cost plus a little per moving object, because the expensive part isn't the movement: it's that a scene with any motion in it can never coast to an idle frame, which phones pay for in battery and heat. A dozen animated props barely registers; a hundred is a real band on the meter.

The Scene Weight window

A single total answers the wrong question: "this scene is heavy" isn't something you can act on, "these three models are the scene" is. Open Windows ▸ Scene Weight for the actionable version, in three parts:

  • Three figures across the top: on arrival, loads later, and whole scene, each with its texture megabytes. A published scene doesn't download all at once (see how a published scene loads), so the total describes a moment no visitor actually experiences. The arrival figure is the one a first impression is made of.
  • By neighborhood: one row per page node, badged on arrival or deferred, with its models, texture MB, and node count. Click a row to select that page. A model used in two neighborhoods is downloaded once but counted in both: the rows answer "what does standing here cost", so they can add up to more than the scene total.
  • Heaviest first: every object ranked by points, with its triangles, texture megabytes, draw calls, and the page it lives on. Click a row to select the object and go fix it. Copies of a shared model say so ("shared by 27 copies, charged once").

Points that belong to no single object (shadow passes, post-processing, the scene file itself) are called out at the bottom rather than spread across the ranking, so no row is inflated by something you can't select.

The window also surfaces the limit the meter can't draw: it tells you when the scene is over the 1,400 MB resident-texture ceiling, and warns from about 80% of it. That one is a memory limit rather than a speed one, so it can bite on a scene the meter otherwise calls light. The 200-point free-plan cap is the meter's own marker (above), so the window doesn't repeat it.

Scoped rooms are charged on the worst one, not all of them If you've bound objects to a neighborhood, the render categories (shadows, lights, beams, particles, animation) are priced on the heaviest single room plus everything unbound, because that's the most a GPU ever draws at once. Memory categories (geometry, textures, nodes) still count the whole scene: a switched-off room stops being drawn, not resident. Scoping a six-room scene routinely halves its score, and that's the honest number rather than a discount.

Textures are counted in megabytes, not pictures

The Textures band is priced on the graphics memory your images occupy once the device has decoded them, so its detail line reads as megabytes, not a picture count. That matters because two models with "three textures" each can differ by sixteen times: a 1024-pixel map costs about 5.6 MB resident, a 2048 map 22.4 MB, a 4096 map 89.5 MB. A single 4K model can outweigh a whole scene of primitives.

  • Imported models are measured, not guessed. The real size of the textures inside a GLB is recorded when it's imported, and the server measures models placed by Claude over MCP too, so a scene built by chat is scored on what it actually contains.
  • Copies are free. Every placement of the same model shares one set of textures, so a forest of 27 oaks off one asset is charged once. Using one model many times is the cheapest thing you can do here.
  • Older scenes fall back to an estimate. A model imported before measuring existed is charged a nominal 67.2 MB PBR set, and the meter says so. Re-import it to replace the estimate with the real number.
  • Page-panel imagery is charged fairly. Panel images stream in as you approach, so weight counts the worst case that can be resident at once, never every panel in a 100-page import.

Weight at publish time

  • Over the red line: publishing still works. It goes through with a warning naming the categories to trim.
  • Over the hard cap: publishing is refused, and a dialog shows the meter plus the heaviest categories so you know exactly what to shrink. Trim and publish again.
  • Over the texture-memory ceiling: refused as well, on its own axis. A scene holding more than about 1,400 MB of estimated resident texture is blocked even if its points total looks comfortable.

The points cap is a free-plan limit, set at twice the red line (200 points), far enough above it that only genuinely extreme scenes hit it. Paid plans have no points cap (the texture-memory ceiling still applies to everyone: it protects the visitor's device, not the server). An already-published site that's over a limit is never bricked: you can keep republishing it as long as it doesn't get any heavier.

The gate charges the whole scene, on purpose. Even though distant neighborhoods load later, publishing is checked against the total rather than the arrival figure. A gate exists to bound the worst case (a visitor who walks the whole site), and subtracting deferred models would quietly raise the cap for anyone who spread their scene out.

Texture memory is the one that crashes phones Points measure slow; texture megabytes measure dead. On the reference phone, frame times held steady up to about 1,000 MB of resident texture, started slipping around 1,200 MB, and the browser killed the tab somewhere between 1,600 and 1,700 MB, with no warning and no points total high enough to predict it. That's why the ceiling is checked separately. Reaching it takes roughly twenty unique full-texture models, so the fix is almost always "reuse a model" rather than "delete objects".
The numbers came off a real phone The cost of each category is fitted from measured benchmark runs on a mid-range Android phone (a Galaxy S20 FE) rather than estimated: geometry, draw calls, shadow maps and texture memory were each ramped until frames actually degraded, and the red line sits at about 70% of where that happened. So "100 points" is a measurement, not a vibe.

The AI assistant and Claude over MCP see the score too: they get a weight warning as they build, so a scene assembled by chat tends to stay in budget on its own.

Weight vs the compatibility check They answer different questions. Weight is one always-on number covering everything a frame costs (geometry, lights, effects, video), and it's what publishing enforces. The compatibility check is a deeper on-demand report that rates you per device tier and names your heaviest individual objects. Use weight while you build; run the check before you ship.
Spotted something off, or want a topic covered? Email hello@3dcms.info.