New BasePart Properties: Massless & RootPriority

physics
motor6d
welds

#1

We’ve just enabled two new properties for parts to give you more power over root selection and the physical properties of your models.

image

BasePart.Massless

If Massless is enabled the part will not contribute to the total mass or inertia of its rigid body as long as it is welded to another part that has mass.

If the part is its own root part according to BasePart:GetRootPart() then Massless will be ignored for that part, and it will still contribute mass and inertia to its rigid body like a normal part. Parts that are massless should never become an assembly root part unless all other parts in the assembly are also massless.

TL;DR it’s like avatar hats.

This might be useful for things like optional accessories on vehicles that you don’t want to affect the handling of the car or a massless render mesh welded to a simpler collision mesh.

BasePart.RootPriority

RootPriority is an integer between -127 and 127 that takes precedence over all other rules for root part sort (including the weird rules based on part size). A part with a higher RootPriority will take priority over other unachored parts with equal Massless values and a lower RootPriority.

Use this to control which part of an assembly is the root part and keep the root part stable if size changes.

What’s a Root Part?

Welds and other rigid joints like 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 CFrames are updated.

With welds you should never need to care: if you use 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 rig on the left, and a representation of this implicit tree of which parts move relative to which parts on the right.

image image

A typical Humanoid rig is a single assembly joined by Motor6Ds. HumanoidRootPart is typically the root part because Accessories are “massless” and the name “HumanoidRootPart” applies a special hacky 10x multiplier to the part’s Size based sort size (from a time before 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.

Updated Assembly 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)
  • Not massless
  • RootPriority
  • 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 one is very old and many games rely on it without realizing it, so we can’t change it.

Now when you know which part should be root take control and avoid the weird old rules by setting the RootPriority higher on the part that you want to be root!


Creating a tool from a model: welding issue
November 2018 Recap: Keeping Up With the Developer Community
[Solved] Welding a non-collidable part forces the whole model to move
Changing the Behavior of Welds to Anchored Parts
#2

Perfect timing for a project that needs just this! Thank you!!


#3

Perhaps its just late for me, or something, but I have read the post 4 times and I am still not quite getting what Root Part is or exactly when and why we would set it.

So it might be good if someone were to make a detailed and maybe visual tutorial on this, especially if we are being encouraged to “Avoid the weird old rules and take control…”


#4

“will be more likely to be root”

Does this mean if you have an assembly with a bunch of parts, and all of them are -127 except for one part which is 127, that part is still not guaranteed to be the root?


#5

Describing some of these concepts is hard sometimes. I changed the wording. Let me know if this makes sense now.

A part with a higher RootPriority will take priority over other unachored parts with equal Massless values and a lower RootPriority.

So yes, it is guaranteed, but you have to consider Anchored and Massless as well which can take precedence in the root sort comparisons. See the root part sorting rules section.


#6

Alright. Parading in the streets with this thread.

In all seriousness though, Roblox has been on some whack fire with these new updates. I can already see the use of these for both builders and scripters, especially the massless part. Until some time ago when I discovered the use of some of BasePart properties I often set the Density to a low value so that the player wouldn’t be flung around by those parts. Now this can rectify the issue and I can have giant assemblies on players without them being bogged down, shoved into the ground, flung or anything.

I appreciate this update very much.


#7

I added some pictures showing an R15 rig as an example. Let me know if that helps make it any easier to understand!


#8

Papa bless. Papa bless so much. I can finally make my game as intended.
Swords bigger than your character are now viable.


#9

Possibly best update of 2018


#10

Does this mean I can make the root part of a humanoid the left hand or right foot? That would be a funny test of the new system :yum:.
edit: not really sure what i was expecting to happen


#11

It’ll be nice seeing dogs wag their tails instead of the other way around :slight_smile:


#12

Yes, thank you, its much more clear now. :slight_smile:


#13

I’ve had a lot of weird issues with this, both when welding to vehicles and to the player character. I find setting the C0/C1 values more reliable for positioning with welding.

And this might actually explain loads of the weirdness I’ve been seeing when making characters really small then giving them tools. Hope the new update allows me to fix them! :smiley:


#14

Very exciting! Does massless improve performance / physics usage? Say if I had a large character with lots of smaller, non-collide, detail parts welded on - would making the detail parts massless improve or hinder performance? Or is it pretty much the same?


#15

Same. Doesn’t improve performance by itself. It’s mostly for things you don’t want to affect mass or how they behave physically.

You can use this to help optimize for performance in some ways. If you’ve built something with detailed meshes or multiple meshes with different materials you might want to optimize those for efficient rendering (like removing internal faces) in ways that would make them generate an inaccurate or overly complex collision mesh with the default automatic convex decomposition setting. In that case it might be better to make your visual meshes Massless, CanCollide false, and CollisionFidelity to Box on them (important! less internal collision shapes to update in broad-phase). Then you could build your physics/collision shape out of simple shapes or one simplified mesh that would perform better for physics.


#16

Can I have a more in depth example on what a rootpart is and how it can be used for us developers? I’m a little confused on this.


#17

99% of the time you shouldn’t need to care about root parts. They’re an implementation detail that leaked into the interface due to some design flaws. The only time you should really need to know about them is when root selection doesn’t do what you wanted.

I think this is one of those things that will probably click when you run into issues with it. If you haven’t yet: good! I hope you never do!

That said I know it could be explained in a more approachable way than I have here. If there was enough demand I could do a video and longer writeup. Anyone else is free to take a crack at explaining this better too!


#18

This is great to hear! Will solve a lot of issues we have with dropped items in Vesteria


#20

How does animation work in respect to rootpriority? I rigged a couple of npcs up to a sort of vehicle with ball socket constraints, and at root priority 0 in their rootparts, neither of them animate. (The animation controller is playing tracks, but it won’t actual play on their rig). Setting both of their root part’s to root priority 1, one animates but not the other. This is all server sided and so are the animations

Seems like two rigs with animation controllers welded to another rig causes some big issues for replication. (It’s fine on the client who owns all the rigs physics)


#21

I guess the animation system cares if the assembly tree matches the animation joint tree and if it doesn’t it gives up?

Can you send is a repo (here or dm works) and I’ll file a ticket for it.