Mesh and Structure

A raw CAD tree rarely has the shape a machine model needs. Sometimes one mesh holds five parts that have to move separately; sometimes eighty screws should be one mesh so the renderer stops drawing them one by one; sometimes the parts of one movement are scattered across three branches of the tree.

The tools on this page reshape that tree. All of them live in the context menu — right-click a node in the 3D view or a row in the hierarchy, both open the same menu — and every one of them is a single undoable step.

Splitting a mesh

Separate ▸ appears on any mesh and offers two ways to break it up:

Into parts… splits the mesh by connectivity: every set of triangles that hangs together becomes its own part. This is what turns a single imported body into the five plates it visibly consists of.
By material group… splits by the mesh’s material groups instead. Offered only when there are at least two, and the right choice for a multi-material mesh, which the connectivity mode refuses.

The editor context menu on a selected part of the demo cell: Focus, Select, Kinematic, Separate and Hide, with the Separate submenu open and offering Into parts… — the part itself is outlined and carries the transform gizmo

Both first show a preview: the analysis runs in the background and reports how many parts you would get before anything changes. Confirm and the source node becomes a group with the parts one level below it, still selected where you left off. Cancel and nothing happened.

Normals, UVs and hard edges survive the split untouched — the analysis welds positions only to work out what is connected, and the parts are rebuilt from the original vertices.

You get a reason rather than a silent no-op when a split is not possible: the mesh is a single connected part, multi-material — use By material group instead, or, if two leaves in the tree share a name and the path is ambiguous, a request to rename the duplicate first.

Merging meshes

Merge into one mesh… does the opposite on a subtree: many small meshes become one, which is the cure for an assembly whose draw-call count is dominated by fasteners.

The preview tells you what will happen before you commit — how many source meshes there are, how many meshes come out, and how many nodes are kept rather than merged away, broken down by why:

kinematic and CAD anchors — nodes something else depends on,
nodes with components — anything carrying a drive, sensor, signal or similar,
nodes kept by naming convention.

That breakdown is the point: merging is safe precisely because the things that make a node meaningful keep it out of the merge. Confirm and the replacement mesh takes the subtree’s place, and stays selected.

Grouping parts

Groups are how parts that move together are collected, and they mirror the Group component of realvirtual for Unity — a node can belong to several groups, but never twice to the same one.

Kinematic ▸ (also on the K shortcut) lists every kinematic axis in the model. Pick one and the whole selection joins its group. New kinematic… takes a name and does everything in one step: it creates a top-level axis node, gives it a Kinematic component linked to the new group, assigns the selection, and leaves the axis selected so you can drop a Drive on it straight away.
A part already assigned to another kinematic group is moved, not duplicated — it cannot end up driven by two axes at once. Non-kinematic groups it belongs to are left alone.
Ungroup removes the group membership again.

Nested assets and the document stack

A document can reference another asset instead of embedding it — a cell that contains a gripper, a line that contains a station. Those references are live: the gripper is edited once, in its own document, and every place that references it follows.

Double-click a reference in the hierarchy or in the 3D view to descend into it. The referenced asset is loaded on its own, and a breadcrumb bar appears at the top of the viewport:

MyPlant.glb  ›  Filler  ›  Gripper                    [ Back ]
editing Gripper.glb — isolated — 3 instance overrides hidden

The second line says which document you are actually editing, that it stands alone rather than in its surroundings, and how many overrides the parent had applied to it that are therefore not visible here.

Back leaves the top frame and rebuilds the one above it. The crumbs are an address, not a jump target — you step out one level at a time. If the frame you are leaving has unsaved changes you are asked first; save is deliberately not offered inside that question, because a navigation gesture should not turn into a file write. The bar only appears once you have descended; at the top level there is no stack to show.

Saving

A document is saved back to where it came from, in the open project — not into a special editor folder. Which mode you happen to be in makes no difference; only the identity of the document does.

A named document never prompts. Only a document with no name of its own asks for one. Untitled counts as a name.
One save at a time. A second click while a save is running does nothing rather than starting a second writer.
Save is refused while a test run holds the document — stop the run first.
Nothing is declared saved that is not in the file. A failed save leaves no half-written document behind, and the document stays marked as changed.

When somebody else wrote first

Every save carries the revision this session last saw for that file — recorded when the document was opened, not at the first save. If the file changed underneath you in the meantime, in another tab or by another person, the save reports a conflict instead of overwriting their work.

The same care applies to the destination: if the project is switched while a save is still baking, the result is discarded rather than written into whichever project you have just moved to.

A saved asset lands in the project you are working in, and the project is itself the first library the Layout Planner offers — nothing has to be published or registered for it to be placeable.