Understanding Root Parts
Understanding Root Parts
What’s a Root Part?
Weld|Welds and other rigid
Motor6D|Motor6Ds combine multiple parts into a single “assembly.” If none of the parts in an assembly are anchored then each assembly forms a single rigid body. Every assembly has a single root part which you can check with
Welds and Motor6D joints have no defined direction. When you change C0/C1 or animate a Motor6D which part is Part0 and which is Part1 does not matter for answering which part moves. To answer that you first need to ask which part will be the root part.
The root part of an assembly is the one that does not move when rigid joint
DataType/CFrame|CFrames are updated.
With welds you should never need to care: if you use
WeldConstraint|WeldConstraints or otherwise just move both parts where they should be before welding them you avoid the problem. However, if you’re using Motor6Ds for animation you need to know which part will move.
To handle this internally we start by first picking the root part based on the part sorting rules below, then we build a spanning tree from the graph of rigid joints that branches out from the root part. When a rigid joint CFrame is updated the part that is closest to root will stay put and the child part and its children will move. Basically, we internally build a conventional transform hierarchy for each assembly.
Here’s a visualization of this tree in a basic R15
Humanoid|humanoid rig on the left, and a representation of this implicit tree of which parts move relative to which parts on the right.
A typical Humanoid rig is a single assembly joined by Motor6Ds.
HumanoidRootPart is typically the root part because
Accessory|Accessories are “massless” and the name “HumanoidRootPart” applies a special hacky 10x multiplier to the part’s
BasePart/Size|Size based sort size (from a time before
The root part is also used for physics replication. For physics replication to work correctly all clients will have to have the same root parts. Separately, when constraints are involved we also need a consistent mechanism structure for network ownership assignment to work.
Root Part Sorting Rules
For choosing a root part parts are compared on, in order:
- Anchored (anchored parts will always be their own assembly root)
- Legacy sort size based on the largest surface area of the object aligned bounding box defined by Size with an additional multiplier for Seats (20x) or parts named “Torso” (5x) or “HumanoidRootPart” (10x):
floor(maxPlanarSize() * 50.0) * specialMultiplier
That last rule is very old and many games rely on it without realizing it. To avoid it, you can use the other rules to determine which part should be the root, such as by setting the RootPriority higher on the part you want to be root!