PcoWSkbVqDnWTu_dm2ix Understanding root parts and how to use them

"> Understanding root parts and how to use them

">
We use cookies on this site to enhance your user experience

Understanding Root Parts

Understanding Root Parts

Sep 25 2019, 2:00 PM PST 10 min

What’s a Root Part?

Weld|Welds and other rigid JointInstance|joints like 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 BasePart/GetRootPart.

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.

Humanoid rig in Workspace
Humanoid rig in explorer

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 BasePart/RootPriority|RootPriority).

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:

  1. Anchored (anchored parts will always be their own assembly root)
  2. Not BasePart/Massless|massless
  3. RootPriority
  4. 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!

Tags:
  • model
  • parts