Physics Best Practices

Hello Developers!

Over several years the physics team has responded to your bug reports and other issues on the dev forum, often explaining how a part of the physics engine works or offering an alternative approaches. There is a wealth of knowledge out there, but being spread out across the forum can make it difficult for developers to find. This post is intended to be a hub of physics best practices, tips, and FAQs. It’s a direct response from our recent Physics Discussion and Survey

Developing games with physics can be tricky. It requires lots of trial and error, patience, and hard work! But with the right knowledge and tips, it can make some of the more difficult parts less difficult. The Roblox physics team is dedicated to help make working with physics as seamless as possible, and we hope this information can help.

We also want you to know that this is intended as a living document. Please share any feedback, suggestions, or questions you have about this post and Roblox physics. We will update it with more info over time.

– Using Physics –

Constraints are used to manipulate how parts interact with each other and move around the world. If unfamiliar, you can read an intro on how to use them here

Building With Constraints

While we have done a tremendous amount of work on making constraints work as smoothly as possible, there are several things you can do to make keep your mechanisms performing well:

  • Use the minimum number of constraints to get the job done. While a door in real life may have three hinges, in Roblox you only need one.
  • But don’t be afraid to mix and match! You’ll often want to use more than one constraint to get a certain interaction feeling right. For example combining a Spring with a Prismatic for suspension, a Ball Socket with AngularVelocity for a damped rotation joint, or simply VectorForce and Torque for precise movement control.
  • Avoid having misaligned constraints before running your game. You can tell something is misaligned when you see any red bits on the constraint or attachment renders. Misaligned constraints will cause parts to apply forces to snap together on Start, and cause unexpected behavior.
  • Avoid large differences in mass between parts connected by a constraint. If you have a very large part (or group of connected parts) that are constrained with some very tiny parts, then you might run into this. You’ll want to increase the small part’s density of its CustomPhysicalMaterial, and decrease the large part’s density, to have the two parts almost equal in mass.
  • Setting MaxForce to infinity on a constraint is rarely the best option. Try to find the actual highest force needed to get your desired behavior.

TIP Make sure to use Show Details, Draw On Top, and Show Welds when working with Constraints!

All “BodyMover” objects and Surface Joints/Welds are legacy and not officially supported.
Except BodyVelocity, otherwise they all have supported Constraint analogs. A BodyGyro can be replaced by AlignOrientation, and a BodyPosition can be replaced by AlignPosition. Constraints are more likely to provide smooth motion and less simulation errors than their BodyMover counterparts.
However, if you find that a BodyMover object still accomplishes something that constraints can’t, please report this as a feature request and we can review!

CFrame with care.
Editing a part’s CFrame (CFraming) should be reserved for one-off constructions at run-time. Remember that changing a CFrame is essentially a teleport, and shouldn’t be happening every frame. This is because you are potentially sending network signals to every player observing the part, without interpolation, and causing jittery motion. CFraming to update “local-only” parts may be a valid strategy, but is more likely to cause over-constrained situations and undesirable collisions. Essentially, CFraming should be reserved for specific teleportation, like resetting a part’s position to be physically simulated after.


This simplifies some of the placement of constraints, preventing weird behavior from misaligned constraints, and simplifying the use of complex yet common constraints. It’s just a prototype now, but after some testing and feedback, we will look into proving more formal constraint helper tools.

Collision Groups

Collision groups can be used to filter specific collision logic between sets of parts. For example your game may have a set of vehicles and you don’t want to have any of the cars collide with the trees/bushes in the game, but you may still want the players and other objects to collide with them.

By default, everything collides with the Default group (even raycasts!). So if you set a group to not collide with Default, its totally invisible to all raycasts! This means things like the selection tool and nametags will break. Unless you are specifically looking for this behavior, we recommend never setting a group to not collide with Default, and instead create new groups for your case.

– Debugging Physics –

This section is on information on how your creations can effect physics performance, and things you can do to minimize their impact.


You can view parts sleeping and waking up by turning on Show Awake Parts in the Physics Settings. Awake parts will be highlighted in red.

Whenever a part is moving around or interacting with other parts, the part is known as “awake”. This means the engine is running physics calculations on that part. When a part stops moving for some time, the engine will put that part to “sleep” and stop running those physics calculations. This helps with performance significantly, we don’t need to run calculations on parts that aren’t moving!

If a sleeping part or any of it’s connected parts gets touched, or has a property changed, then the engine will tell that part to “wake up” so it can run calculations on it again.

Having a large amount of awake parts in your game can slow performance, so it’s good to use this to get an idea and see if all your parts seem to be sleeping and waking appropriately. Occasionally, parts will not wake up when they should, and instead appear stuck in place. Turn on Show Awake Parts to verify that it is a sleep issue, and not some other bug in your game.

TIP Anchored parts are always asleep.


You can view contact points by turning on Show Contact Points in the Physics Settings.

When two parts touch each other, the physics engine creates a contact point. The engine then uses the contact point to calculate how the two parts should move and react with each other.

If your game is generating lots of contact points, it can slow performance. You can prevent extra contacts by either eliminating the collision (CanCollide, collision groups) or by altering the objects to use simpler collision geometry. Or, you can use the NoCollisionConstraint to prevent collisions between two specific parts, especially if they are part of an isolated model.

It’s also important to be aware of what parts are listening on Touch events. Contacts will still be generated between two parts that are CanCollide false if one of them is listening on a Touch event.

TIP Showing contact points is also a really great way to debug gameplay issues in your game. (i.e. is this part really getting hit by the door here?)

Mesh Collisions

You can view the mesh collision geometry by turning on Show Decomposition Geometry in Physics Settings.

Unions and MeshParts will generate a collision decomposition geometry. This is the actual shape that the physics engine uses when calculating collisions with other parts. You can change the fidelity of this decomposition with the CollisionFidelity property. Using the Default is often more precise than you need, and is also the most expensive, so it’s worth looking at the decomposition geometry to see if you could use Hull or Box fidelity.

TIP Avoid using MeshParts or Unions as rolling objects. The decomposition geometry will not be perfectly smooth and the part may bounce around. The Roblox sphere and cylinder collisions are calculated differently, and thus will roll as if perfectly smooth.

In our example gif, changing all the Union parts to Hull will result in a much simpler geometry, improving performance.

Network Ownership

You can view network ownership by turning on Are Owners Shown in Physics Settings. Any color that matches the colors around a player are owned by that player, and anything with another color is owned by the server.

Every part in Roblox is either owned by the server or client (the player). The owner determines the device that the physics calculation is run on. In general, if a part is near an in-game character, its physics will be simulated by that player’s device; otherwise it will be calculated by the server. If you are not the owner, then the parts have their position updated for you via interpolation. The interpolation is done by replicating the position, orientation, linear and angular velocities.

When parts are highlighted red, they are being simulated on your device, but you do not own it. This is generally just a transitional state used to avoid instability. The parts become simulated for a frame, then are corrected by interpolation.

This is important because objects simulated on your machine will impact performance, so this view can make it clear what is actually running on your machine, versus being interpolated.


This will expose the Physics Settings mentioned here to your plugin toolbar to make it easier to toggle them on and off. (Thanks to @CloneTrooper1019 for letting my fork his Decomp Geometry plugin!)

– More Information –

Here, we will build a list of other helpful technical information on Roblox posted around the forums.

I found some spelling and grammar errors here and there:

Under Debugging Physics / Sleep / Description / Paragraph 1

  • part to “sleep”, and >> part to “sleep” and

Under Debugging Physics / Contacts / Description / Paragraph 1

  • pats >> parts
  • create >> creates

Under Debugging Physics / Contacts / Tip

  • i.e. is this parts really >> e.g. are these parts really OR e.g. is this part really

Under Debugging Physics / Mesh Collisions / Description

  • Default is often be more precise >> Default is often more precise

Under DP / Network Ownership / Description / Paragraph 1

  • the server , or by the client >> the server or the client

Under DP / Network Ownership / Description / Paragraph 2

  • highlighted in red, then they are >> highlighted in red, they are
  • on your device but you do not own it >> on your device, but you do not own it (missing comma)
  • This generally >> This is generally

This is a very useful document by the way, I never knew half of these physics settings existed, especially the debugger portion!


Glad it was useful! And thanks for the corrections, the post has been fixed. (That’s what I get for drafting most of it on the forum itself. :upside_down_face: )


Agree with goldenstein64, and I encourage Roblox Staff to post more informative content such as this over time. Such posts don’t need to be this long, but the amount of specific detail here is very helpful.

“Here’s the current best practices for X (or use Service_X). You should know about settings Y and Z. Here are some Tips, and here’s are some relevant considerations.”

That sort of thing.


Such content should ideally go on the Developer Hub / API documentation – not great to set the expectation that these things should be found on obscure places on Developer Forum.

Longer posts like this one are good for the Developer Forum.


I agree, there’s lots of valuable information & guides that staff and others have posted on the forum recently, but unless for whatever reason they are replied to often, they just get lost among all the other posts

1 Like

You mention you do interpolation when a client is not the physics owner, but is it just linear interpolation or something more complicated? Is velocity replicated through the network or calculated manually based on change in position/change in time?

I really liked this post, the body movers being deprecated without giving constraint maxforce/torque/velocity/angularvelocity etc vector types is really limiting though, and I can’t ever really use them without the feature requests for vector types being implemented

1 Like

We chose for this post to go on the Forums because we want to rapidly update it with more info and answers to questions over time. The Developer Hub doesn’t lend itself to that very well. We had a lot of great questions and topics come up in the Physics Survey and Discussion post last month, a lot of which is addressed here, and want to continue addressing these kinds of questions as they come up across the forums over time.

This post will absolutely get put on the Developer Hub later, just not right away.


The server simulates assemblies then replicates the position, orientation, linear and angular velocities. The specific method is known as Hermite spline. The post has been updated!

Can you elaborate on what you mean by vector types?
I also want to clarify that we aren’t done adding features to Constraints, just that we won’t be adding features to BodyMovers.


If we want to only AlignPosition on one axis for example we have to update Attachment1’s position every stepped right now (as opposed to if MaxForce were a Vector not a float type, we could just set it to <0,desiredForce,0>)
Would this updating fall under the cframe teleporting?

Also would it be possible to note what changes you make to the post so we dont have to re-read it/store a copy of it and diff it every time?


Would using a Prismatic constraint work? A prismatic forces a part to slide along only one axis.

And I thought about marking edits in the post, but there’s no extra info in the edit than there was in my reply, I can still mark it if it’s helpful though.


PrismaticConstraints wouldn’t work in my use case which I posted a recorded video of in this post because I wanted the character to still move to the sides and not be locked into the axis

1 Like

I would say that if you are going for more general or nuanced movement, its best to use VectorForce, LineForce, and/or Torque rather than updating CFrame on Stepped. Essentially, apply forces in a given direction when a button is held.


I’m trying to work with AlignPosition contraints, but I’m unable to achieve smooth alignment, as the parts become asleep right before they reach their destination (even though they’re still moving):

(the distance between the attachments before the parts become asleep is ~0.075 studs)

Since that happens, I’m forced to “snap” the parts together early (by enabling RigidityEnabled property), which looks rather unappealing:


Is there anything that I could do to prevent that from happening (instead of updating parts’ properties back and forth, to jiggle their way into full alignment)?
Could Roblox’s engine be more sensitive to slower movements so it doesn’t mark it as “not moving”, or mark constraint-active parts to be immune to this?

1 Like

Have you tried increasing responsiveness? You can always limit the speed with MaxVelocity if you want to keep it moving slow, but a higher Responsiveness should make sure that the attachments fully align.

I’m using low Responsiveness to give it a “smooth landing” effect. If I were to increase it, the overall movement would be rather linear, and the landing/stop abrubt & unnatural.
(I honestly would make it even lower if it wasn’t clamped to minimum value of 5, to make it even smoother.)

It does seem like you are dealing with an issue where the part is falling asleep earlier than it should. (You can always use the sleep visualization to verify this).
There are a few edge cases we run into where parts either fall asleep when they shouldn’t or don’t wake up when they should. We are continuing to experiment with ways to mitigate them.

For now, you could try and offset the attachments a bit so your part is in the correct position even if the attachments are offset. You can also continue to configure properties to get closer to the behavior you want, like trying to increase responsiveness in the end rather than enabling rigidity so there’s less of a “snap”. Or maybe an extra VectorFroce you enable to give it an extra little push at the end.

1 Like

I’m new to Roblox, and my big problem is that I can’t find a starting point for the current physics system documentation.

I want to apply a constant force vector to a part. Is BodyVelocity the correct class? It’s confusing because it is grouped under Body Movers in the API, and this post says that body movers are deprecated.

Also, I can’t tell which tutorials are using deprecated classes. For example, this tutorial uses legacy classes but has not been marked a deprecated:

It would also help to have a timeline of physics classes, so that when viewing forum posts and YouTube content we can have a rough idea if they might be using legacy classes.

1 Like

To apply a constant force you can use a VectorForce constraint.
As for constant velocity, we have the AngularVelocity constraint, but there is no LinearVelocity constraint yet. For now, you can use BodyVelocity. BodyVelocity is pretty much the only BodyMover you should need to use, otherwise you can use Constraints, here is a good starting point for them.

There is a good bit of outdated documentation, so I get your confusion. Please make specific requests in, thanks.

1 Like

If two parts are either anchored or both unanchored and welded to the same assembly, should they collide/create contacts for each other?

I was told this was the case and that they still create contacts and that you need to give them a collision group that doesn’t collide with itself, but this seems incorrect