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.
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.
Plugin!
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.
https://www.roblox.com/library/3138660394/Constraint-Usability
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.
Sleep
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.
Contacts
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.
Plugin!
This will expose the Physics Settings mentioned here to your plugin toolbar to make it easier to toggle them on and off. (Thanks to @Maximum_ADHD for letting my fork his Decomp Geometry plugin!) https://www.roblox.com/catalog/03175945142/redirect
– More Information –
Here, we will build a list of other helpful technical information on Roblox posted around the forums.
- Massless and Root Priority New BasePart Properties: Massless & RootPriority
)
