[Activated!] New Part Physics API

Today we are releasing some new physics properties and functions for BaseParts! They do require some explanation, so read on!


First, we’ve added five new properties that further introduce a concept that may be new to some of you: the assembly.

In Roblox, an assembly is a set of unanchored parts connected by WeldConstraints, Motor6Ds, or other rigid joints. Internally, these parts form a single rigid body with a velocity, position, and mass.
Read more about assemblies here!

These properties are now all exposed as properties of the BasePart:

  • float AssemblyMass [read only] - The total mass of the part’s assembly.
  • Vector3 AssemblyCenterOfMass [read only] - The world space position of the part’s assembly’s center of mass.
  • Vector3 AssemblyLinearVelocity - The linear velocity of the part’s assembly (at its center of mass).
  • Vector3 AssemblyAngularVelocity - The angular velocity of the part’s assembly.
  • BasePart AssemblyRootPart [read only] - A reference to the root part of the assembly (the same part that’s returned when you call Part:GetRootPart()).

More things to know about assemblies:

  • When working with a single part, that part is an assembly itself.
  • Every assembly has a root part. The root part is defined by several factors including the RootPriority property. A more in-depth breakdown can be found here: Documentation - Roblox Creator Hub
  • An assembly only exists in the Workspace or another WorldModel instance. If you have a set of parts welded/connected and stored outside of Workspace/WorldModel, all of those connections are disabled and each part becomes its own assembly.
  • When one of the parts in an assembly is anchored, that part becomes the root part and all the other parts become implicitly anchored with it. You could think that the whole assembly is anchored, and you can still set the AssemblyLinearVelocity property for conveyor belt behavior.
  • Once more than one of the parts in an assembly is anchored, the assembly will split, with each anchored part being the root part of its own assembly. If you anchor all the parts, they all become their own assembly.


A much requested feature has been for a method to apply an impulse to parts. An impulse can be interpreted as an instantaneous force or impact applied to a part for a single physics step. This is ideal for launching physics-based projectiles!

  • void ApplyImpulse(Vector3 impulse) - apply an impulse to the assembly at the assembly’s center of mass
  • void ApplyImpulseAtPosition(Vector3 impulse, Vector3 position) - apply an impulse to the assembly at specified position.
  • void ApplyAngularImpulse(Vector3 angularImpulse) - apply an angular impulse to the assembly

Looking Forward (Activated as of Feb 3!)

BasePart.Velocity and BasePart.RotVelocity are now deprecated (hidden from Properties window). There were multiple issues in their operation when dealing with a part and its assembly. For example, setting velocity on a part that isn’t a root part just doesn’t work, but it always reads the velocity of the specific part. The AssemblyLinearVelocity and AssemblyAngularVelocity properties, along with the new impulse functions, should provide all of the options necessary for setting specific velocities.

As for reading linear velocities of specific parts or positions, BasePart:GetVelocityAtPosition(Vector3 position) has been added which will return the specific velocity for any point on your assembly (more flexible than BasePart.Velocity).


Thanks for reading this big post! We are working on a more in-depth and definitive article about Assemblies for the developer hub. If you have questions, please post them here!



This is absolutely amazing, and I’d always wondered why setting BasePart.Velocity didn’t work with players. I can finally make server-sided cannons and things! I am seriously more hyped than I should be.

Good update.


What is the point of the property if the function does the same? Or will the latter be deprecated in favor of the former in the future? Or maybe I don’t understand how this works

dang, rip

Thanks for the rest of the info though, never knew this. I don’t even know if this is documented.


How will this work with reading the velocity of the basepart? Will the new properties allow us to read their magnitude and do maths with them?


Yes we will likely deprecate BasePart:GetRootPart in favor of the new property.


From what I gathered, you can get the velocity for individual positions on the assembly. So say for example, you had one assembly balanced on a fixed point, and it fell to one side, you could get the velocity of the falling side, and the velocity of the rising side separately.


What are the benefits/tradeoffs of setting AssemblyLinearVelocity versus using a BodyVelocity?


Thanks to you. I didn’t really use for the moment the root part in my script but I will see this a day !

1 Like

A BodyVelocity applies a force so that a part will maintain a constant velocity you set.

Setting the AssemblyLinearVelocity is mostly the same as setting Part.Velocity, it just sets the velocity for that frame, and normal simulation takes over from there. It’s basically like applying an impulse, in which case you should just use the new impulse functions instead.


This is really cool, I was going to make a custom water system with good physics and I think this might’ve just made everything much more easier!

Great Choice and Thank you.


As for specifically why readonly properties are preferable when possible over getters is that you can see properties in the properties panel in Roblox Studio, vs getters are more hidden.

Would you rather have to call :GetAssemblyMass() in the command bar, or just be able to see what the assembly mass is in the properties panel? That’s why it’s exposed as .AssemblyMass instead.


I’m really liking the :GetVelocityAtPosition. This could mean that things such as launching projectiles and whatnot can be easily read from when trying to calculate how much damage a player should take based on velocity when the “mortar ball” hits the player.


Oh I get that, my point was mainly why have both that do the same. But now that I know :GetRootPart() might be deprecated in the future, I see why they introduced the property. And I agree with it being easier to find.


This look great, I’ll definitely experiment in a bit! Question: what happens when applying impulses over a network? (e.g a server applies an impulse to a part with a client network owner)

The reason I ask is that setting the velocity of a part from the server with client ownership is unreliable, and therefore considered a bad practice.


I’ve actually just tested this and it acts the same as if you set the Velocity property directly. In other words it doesn’t do anything if you don’t have network ownership.


Question: For the Position arguments in each of the methods, are those relative to the world or the root part?

Really liking this update. This’ll clean up some of my code :slight_smile:


How will scripts using Velocity and RotVelocity work? will they still be supported as long as possible despite deprecation? because conveyors use Velocity, and i know a game that uses Velocity and RotVelocity alot, so it would be nice if both the new stuff and the already existing stuff were supported.


Hello everyone my apologies but this is causing some new studio crashes. We need to disable this until the bug has been resolved!
EDIT: No more releases this year - check back in January!


:pray: :pray: :pray:

This is so cool! Really removes a lot of cases where you have to do odd workarounds and makes the physics engine feel much more… complete?

You can now do a lot of things without making & destroying an object. Stuff like jump pads, punching objects with knockback, making a domino fall over, etc.


Awesome! This will all be extremely useful for my game (which uses the physics engine + body movers to simulate flight) and I look forward to making the switch. Currently, I had to go through a bunch of hoops to get desirable behaviour; this should simplify a lot of mechanics in my game (as well as introduce some new ones)!

I only ask that while deprecated, the Velocity properties are not removed. I know this is probably what you mean by “deprecated” anyway, but just so that our needs are clear; those properties are useful (when doing some tricks), and I will without doubt forget to switch over to assembly velocity at least somewhere in my code base.