Scoping a room to its neighborhood

A multi-room scene keeps every room in one scene tree, and by default the runtime draws all of them from everywhere, so a lamp in room six is shaded every frame while the visitor stands in room one. Neighborhood scoping fixes that: bind an object to a page, and it switches off while the visitor is in another neighborhood, then back on as they return.

It is opt-in, per node. A scene that never uses it behaves exactly as it always did.

The control

Select any object and open Neighborhood in the Properties panel's Transform section:

The section only appears in a scene that has pages, and not on a page node itself (a room can't belong to itself) or a backdrop layer, which carries its own copy of these two fields.

Bind the group, not every object in it

Binding is inherited. Switching a group off takes its whole subtree with it, so binding the group that holds a room is the whole job: every prop, tree and lamp under it follows. Binding each child individually adds nothing and is only a chance to contradict the parent.

It matters most when you copy a furnished room to make the next one. A duplicate carries its data across verbatim, including the binding, so children copied out of room one keep claiming room one: they then switch off in the room they are actually standing in and on in a room nobody is near. The scene lint now names exactly that shape, an object bound to a different neighborhood than the group it sits in, and the fix is to clear the binding on the children and leave it on the group. (Duplicating a room from the editor's own room tools re-binds the copy for you; this is about copies made object by object, or by the Assistant's duplicate and scatter operations.)

Which room is on

The visitor is in exactly one neighborhood at a time (normally the page whose centre is nearest), and only that page's objects are switched on. It's ownership, not a distance fade: there's no radius to tune, and two rooms can't both be half-on. A few metres of stickiness at the boundary keep a camera parked between two rooms from flickering between them.

A room also holds on to a visitor who is plainly still inside it, whoever is nearest. Nearest-centre on its own puts the handover exactly half-way between two pages, so with rooms 70 m apart a visitor standing 25 m back from a wall, looking straight at it, is only a few metres of orbit from watching that entire room switch off. The distance a room keeps is worked out from the spacing you actually used, so there is nothing to tune: rooms 12 m apart still hand over promptly, and rooms 200 m apart stop dropping a room somebody is standing in the middle of. It applies to free roaming only. Click a link sign and the room you chose takes over straight away, rather than stranding you in the one you just left for most of the flight.

The page a visitor navigated to holds the room until proximity is clearly against it, with the same few metres of margin. That matters the moment you compose an arrival viewpoint: a shot standing well back from page A, looking at it across the floor, can easily be nearer to page B's centre, and by distance alone B would win, switching A's props and lamps off while the URL, the page title and the menu all still say A. Walk properly into the next room and it hands over as normal.

Switching off an object takes its whole subtree with it: everything parented under it, and for a light its shadow pass and volumetric beam too. An object bound to a page you later delete stays on rather than silently vanishing.

Binding a repeated model also takes it out of automatic instancing, so each bound copy draws on its own. That is the right trade and it is worth knowing you're making it: twenty identical crates in one room cost twenty draw calls while that room is active, and nothing at all from any other room. Shared batching would have cost one draw call from everywhere, forever.

It's why a later room gets shadows

Only four lights in a scene can cast shadows, and they're picked in scene order, so on a six-room site, rooms one and two spent the whole budget and the rooms you built last got no shadows at all, however far away they were, with nothing saying why. Bound lights get their own four per neighborhood. Unbound "everywhere" lights share a pool of four between them.

Binding every light you place in a room is the single most valuable use of this feature. The Inspector's "(n/4 used)" count reads within the selected light's own room, so it means something again on a scene with a dozen lamps. A lamp bound through its group counts in that group's room, not in the everywhere pool, the same way the renderer and the weight meter read it.

Rooms dissolve instead of popping

Crossing between neighborhoods used to switch a room off and the next one on in a single frame, mid-flight, which reads as objects blinking out of existence. They now fade, and only the two rooms that are actually changing pay for it.

Neighborhood fade (ms) sits with the other neighborhood controls in Settings ▸ Selection + Visual Feedback, just under Show neighborhood plates. The default is a short dissolve; 0 restores the instant switch exactly as it was.

0 is worth reaching for if a long fade ever costs more than the pop did, and here is why: a room in the middle of a dissolve is being drawn, and drawn in the transparent pass, which nothing else in the scene has to pay for. Both ends of the ramp put every material back exactly as you authored it, so a room that is simply on is an ordinary opaque room and not a transparent one parked at full opacity. Bound lamps dim with their room rather than snapping out, and keep their shadow slot the whole way through so nothing else in the room flickers. Their handover is quicker than the room's: the leaving room's lamps are out by the middle of the dissolve and the arriving room's come up after it, so two rooms are never lit at once, which is what lets a room switch happen without a shader recompile.

What it does to scene weight

Scene weight knows about scoping. The render-cost categories (draw calls, shadows, lights, beams, particles, force fields, animation) are charged on the busiest single room plus everything unbound, because that's the most a visitor's GPU ever draws at once, and the meter's detail line names both figures when culling is doing work ("25 draw calls (est.) in the busiest neighborhood, of 100 in the scene"). Memory costs (geometry, textures, node count, the scene file) stay whole-scene: a switched-off subtree stops being drawn, it doesn't stop being resident. A six-room demo scene dropped from 97.2 to 35.6 points on that change alone.

The model reads inherited bindings the way the runtime does, so binding one group credits everything under it. Before that, every child that inherited its binding, which is every prop anyone actually builds, was priced as if it drew in every room at once, and binding the group correctly bought nothing.

The Assistant and Claude over MCP can set the binding as they build (data.zonePageId, with data.zoneRadius for something that has to stay visible from outside its room), and are told to bind every light and prop they place in a room of a multi-room scene.

If one room is much bigger than its spacing suggests, the distance it keeps can be pinned per page with data.zoneKeepDistance (in metres) on the page node. There is no control for it in the editor: it's an override for the rare room the derived figure gets wrong, and the Assistant can set it on request.

Duplicating a finished room to make the next one keeps its bindings straight: the copy's objects are re-bound to the copy, along with its arrival camera and any link signs pointing inside it, while a sign aimed at a room elsewhere in the scene still means that room. (Before this, a duplicated room stayed bound to the original, invisible from inside itself, and quietly spending the original room's four shadow slots.)

While you're binding rooms, it's worth giving each one the viewpoint a visitor arrives at as well: scoping decides what a room draws, and the arrival camera decides where someone is standing when it comes up.