Prefab Editor
A prefab is a configured piece: one model, the snap points attached to it, any extra models bolted on, and the joints — hinges — that connect them. Placing a prefab puts the whole thing on the table at once.
It lives in a <stem>.prefab.json file beside the model it was made from:
models/rack.glb the model, untouched
models/rack.prefab.json the prefab — place THIS
Three things called "prefab", and which one this is#
The word is overloaded in this editor, and the three are genuinely different:
| What it is | How many table entities | |
|---|---|---|
| Prefab (this page) | a model plus snap points, attachments and joints | one, plus one per attachment |
Model assembly (.assembly.json) |
ONE model built from several part .glbs |
one |
Asset-pack prefab (Prefabs (N)) |
a reusable single-entity template, no children | one |
The distinction is not cosmetic. A hinge joins two rigid bodies, so a lid that swings has to be its own entity — which an assembly, being one model with one body, cannot give it.
Going the other way: a prefab's body may be an assembly. Composing several meshes into one rigid shape is the assembly's job, and a prefab does not repeat it.
Creating one#
Hover a model tile in the asset explorer and click the Create prefab button (the same glyph the Prefabs folder uses). That writes the document, wraps the model as its body, and opens the new tab.
It works on both kinds of model tile:
| You started from | The document lands at |
|---|---|
a project model (models/rack.glb) |
models/rack.prefab.json, beside it |
| a built-in piece (a card holder, a tray) | models/<preset-id>.prefab.json |
Built-in pieces are included deliberately. A project that has uploaded no models of its own — which is most of them — sees only built-ins in its explorer, and "put snap points on the card holder" is the most obvious thing anyone wants a prefab for.
If a prefab already exists at that path, the action refuses rather than replacing it — a prefab carries authored snap points and joints, and a hover button should not be able to throw those away silently.
The panels#
Prefab#
The name (which becomes the placed entity's label), the body and its scale, and the body's type.
The body picker offers this project's models — .glb, .gltf and .assembly.json — and
every built-in piece, in one list. A part is one or the other, never both: a built-in body
spawns exactly the piece it would spawn on its own, with the collider and container
configuration that make it what it is, and its authored scale multiplies the built-in's own
rather than replacing it.
| Body type | Use it for |
|---|---|
| Static | a fixture — a rack, a board, a tray. The default. |
| Kinematic | something a script moves. |
| Dynamic | a piece players pick up and throw. |
A body a joint names is forced dynamic when the prefab is placed, whatever is chosen here: a hinge to a static body is a weld.
Snap points#
Where a dropped piece lands on this prefab — the reason most prefabs exist.
Each one has a name, a position in prefab space, a rotation and a snap radius (the catchment a dropped piece is pulled into). All of them are relative to the prefab, which is the whole point: move or turn a placed copy and its slots go with it. A scene snap point cannot do that, because it is a world position the table owns.
The radius scales with the placed prefab, so a rack at half size gets slots with half the catchment rather than slots that overlap each other.
Unlike a scene snap point, these have no transform gizmo. A prefab is a definition with no world transform to drag against, so the fields are numeric — place the prefab, then adjust.
Attachments#
Extra models bolted onto the body, each with its own position, rotation, scale and body type. They come from the same list as the body, so an attachment can be a project model or a built-in piece.
Each attachment becomes its own entity, parented to the body. That is what lets a joint reach it, and it is why an attachment is not simply another mesh on the body's model. Parenting is transform and organisation only: moving the prefab moves all of it.
Removing an attachment also removes any joint that named it, so the document cannot be left in a state whose error you can only fix from a row that no longer exists.
Joints#
Hinges and other constraints between the body and its attachments. Each joint picks a type
(fixed, hinge or spring), the two parts it connects, and whether those two parts
collide with each other — off by default, because a lid that collides with its own box
jams.
A joint needs two parts, so add an attachment before adding one. A joint that names a part which does not exist, or names the same part twice, is refused on save rather than written and quietly ignored.
Saving#
Like the plain file editor, edits live in the tab until you press Save, and Save Draft / Publish flush them for you. The document is validated first; a prefab with problems lists them under the header and cannot be saved.
There is no live 3D preview in the tab — the preview session loads a single model and knows nothing about prefabs. Saving re-primes the resolver and placed copies reload, so the scene itself is the preview.
Placing one#
Drag the prefab tile to the table, or click its Place button. That spawns the body, one entity per attachment (parented to the body), and every joint between them.
Each placement gets its own namespaced ids, so two copies of the same rack on one table are independent. The prefab rests on the table's live play surface, so it lands correctly on a tall table pack as well as the default one.