Place it, organise it,
and watch solo forget what you changed.

Primitives are the fast way to block something out: a crate-sized cube next to a person-sized cylinder tells you more about scale in ten seconds than any measurement will. Models are the real thing, and they arrive through the Models panel — the same panel that imported and thumbnailed them.

Every object gets a unique id the moment it is placed, which is how it stays identifiable across a save and load even if you rename it or move it.

This is the conventional behaviour in every editor of this kind, and it is still the single most common way to lose two minutes of careful picking. The habit worth building is to reach for the add-modifier before the second click rather than after.

Two shortcuts exist that select a whole set at once, and both are covered in the next tutorial: selecting everything on a layer, and selecting everything in a group. If you find yourself click-adding more than three or four things regularly, one of those is what you actually want.

That sounds like a triviality and it sets up the whole of the next tutorial. A scene always has at least one layer, everything lands on it, and nothing is grouped until you say so. So an unorganised scene is not in a special state — it is simply one layer with everything on it, which is exactly what layer 0 is.

It also means the organisation tools are additive: you can build a whole scene without touching layers or groups, then organise afterwards, and nothing has to be undone first.

That last row is the one worth remembering. A placed object can carry a link to a definition — this cube is the crate you authored in the Definitions workspace — and that link is part of the scene file, not a runtime convenience.

Loading into a different editor instance is what makes this a real test. Reading a value back from the editor that just wrote it proves almost nothing; reading it out of a fresh one proves the file carries it.

None of those are things a set of objects has on its own — they are things a layer has and lends to whatever is on it. That is the whole reason layers are exclusive: if an object were on two layers with different visibility, the question "is it visible?" would have no answer.

Exclusivity is not a limitation here. It is what makes the properties meaningful.

You group a selection, the members all get the same name, and from then on that name will give you the selection back. Verified: grouping two of three objects left the third untouched, selecting the group returned exactly those two, and objects could be added and removed from the group afterwards.

The "nearly" is that a group name also lets you hide or lock the whole set at once — verified: hiding a group hid both members and left the ungrouped object visible. So a group is a handle for three things: re-select, hide, lock.

What it has no notion of is colour, ordering or solo. Those belong to layers, and a group has no opinion about them at all.

Read down the two columns and the pattern is clear: they agree on everything about membership and differ on everything about presentation. Layers are how the scene is structured for looking at; groups are how a selection is remembered.

★ The one asymmetry that is not about presentation: everything is always on a layer, and nothing has to be in a group. Layers partition the scene exhaustively; groups cover only what you have chosen to name.

Because both are exclusive, you cannot use them as two overlapping tagging systems — an object cannot be in "crates" and "north side" at once. If you find yourself wanting that, the answer is to pick whichever axis you will want to hide, make that the layer, and use the group for the other one.

Select a layer and everything on it is selected — verified, one object on the layer gave one selection. Select a group and its members come back — verified, a two-member group returned two.

So the workflow that avoids the selection trap entirely is: group things once, when you first make them, and select by name forever after. The two seconds spent naming a set is the last time you have to pick it by hand.

That is the behaviour you want and it is not the obvious implementation. The lazy version of solo makes everything visible when you turn it off, which silently undoes any hiding you had done for your own reasons. This one snapshots the visibility of every layer before isolating, and restores that snapshot on the way out.

Verified: with layer 1 hidden on purpose, soloing layer 2 and then un-soloing left layer 0 visible and layer 1 hidden — exactly as before.

Layer 0 started visible and ended hidden, and nothing told you. The step that did the damage is the third one, which does not look like it touches visibility at all — adding a layer is about as innocent an action as exists in this editor.

What happened underneath: the structural change clears solo without restoring, so the editor forgets it was ever isolating. The next solo therefore treats the currently-isolated view as the baseline to return to. Every subsequent un-solo restores that.

Deleting or reordering a layer does the same thing, for the same reason.

If solo is off when you add, delete or reorder a layer, there is no snapshot to lose and nothing happens. The memory only exists while solo is on, so the fix is simply not to change the structure during that window.

If you think it may already have happened, the recovery is manual and easy enough: turn solo off and set each layer's visibility by hand to what you meant. Nothing is destroyed — the objects are all there, on their layers, unchanged. Only the visibility flags drifted.

It survives a save and load into a fresh editor, verified, so it is genuinely part of the scene rather than a live convenience. It is the only structural connection between the 3D workspace and the Definitions workspace, and it is what lets a scene be a layout of your mod's content rather than an unrelated pile of boxes.

The Definitions workspace reads the live scene through this link when it builds an export bundle — which brings us to the thing this ladder has been deferring.

The scene is captured into the export bundle as plain records, and the game adapter does not emit them, because there is nothing for them to become. This is the same finding the Definitions ladder reached about quests and events: the Mod Kit can author it, and the game has no counterpart.

So what is the 3D workspace for? Three real things:

That is a workshop, not a level editor, and it is genuinely valuable as a workshop. The mistake to avoid is spending a week arranging a village in the belief that the village is the deliverable. The models are the deliverable; the scene is how you check them.