LIVE - Upcoming Physical Properties and PartMaterial Changes

Hey Guys’n’Gals,

You may remember me talking about an upcoming new feature (see: where I talked about introducing a new system that is incompatible with how things are currently done in ROBLOX. Originally we were planning on handling this by leaving in a Workspace flag (as you may remember from this post), but the more we thought about it the more we realized that leaving in another Workspace flag that changes internal physical behavior will only hurt the platform in the long run (imagine Toolbox models that magically don’t work because you have a certain Workspace-level flag disabled). In short to deal with this, we will be enabling a temporary workspace flag that allows users to Opt out of the system, but we will eventually be migrating EVERYONE to the new system.

Now, keep in mind that most of your games will be unaffected by this change. When this feature launches, we have a fairly consistent way to migrate custom-set Elasticity and Friction settings into the new mode (and we do so automatically if you flip your Workspace.PhysicalPropertiesMode to New, however in case your game relies on Buoyancy and Density being identical, you may start seeing different behavior.

GameTypes which MAY be affected by this change

  • Zero Gravity games may be affected by density change, we encourage
    you to use the “GetMass()” function to correctly cancel out gravity!
  • Physics-Based Submarine and Boat Games may be affected by new
    Buoyancy and Density behaviors.
  • Flight Simulators that use airfoil simulation may find that the
    center of mass has moved on objects that have different materials.


Our plan to Roll this feature out revolves around having 3 phases:

  • Phase1: Workspace property introduced.
    • Leaving PhysicalPropertiesMode as Default will automatically enable the new PhysicalProperties system during the next stage of
      the migration process.
    • Changing PhysicalPropertiesMode to Legacy will grant users more time in the old PhysicalProperties system, perhaps allowing them
      more time to migrate their games to use the system manually.
    • Users who have set their property to New or Legacy will not see any behavior changes after switching to these modes during the
      next section of the Migration.
  • Phase 2: By default, PhysicalMaterialsMode is now enabled.
    • Places that left PhysicalPropertiesMode as Default will now be automatically migrated to the new system.
    • Places that chose to set PhysicalPropertiesMode to Legacy have another month of using the old system.
  • Phase 3: The great migration.
    • All places regardless of PhysicalProperetiesMode will begin using the new PhysicalProperties system.

This time-period should give users enough time to figure out if they are affected by this change.

Now to the fun stuff!

Basically, by default parts you create will have Elasticity, Friction, and Density associated with that Material. You can override this default behavior by assigning a CustomPhysicalProperties item to the object, allowing you to customize Density, Friction, Elasticity away from anything pre-set by the part’s Material.


  • Set custom properties on a part: Part.CustomPhysicalProperties =, friction, elasticity, frictionWeight
    = 1, elasticityWeight = 1)
  • Disable custom properties on a part: Part.CustomPhysicalProperties =
  • Read-Only components
    • Part.PhysicalProperties.Density
    • Part.PhysicalProperties.Friction
    • Part.PhysicalProperties.Elasticity
    • Part.PhysicalProperties.FrictionWeight
    • Part.PhysicalProperties.ElasticityWeight


  • Friction and Elasticity between two interacting objects is determined
    by a pairwise weighted average function.
  • (Friction_a * FrictionWeight_a + Friction_b * FrictionWeight_b)/
    (FrictionWeight_a + FrictionWeight_b)
    • You can see how if FrictionWeight_a >> FrictionWeight_b, the result ends up coming out as FrictionWeight_a.
    • If FrictionWeight_a ~ FrictionWeight_b, the result is right between the two values.

I’ll post here once we have a more concrete timeline. Keep in mind, ,that the length of the Phases are still up in the air, but we are thinking about 1 Month for each phase. As it stands right now, this may start in about 2 weeks. You should be able to test your places on GameTest1 even ahead of the release.

Troubleshooting If Your Game Behaves Unexpectedly
  1. Your characters feel like they have too much momentum, and take a while to speed up and slow down:
    Check what materials you are using on your floor objects. Are they slippery like Glass or Ice? You may want to modify the frictional properties of these objects to make them more sticky (higher number).

  2. Your Zero-Gravity parts or missiles propelled by BodyForces, BodyVelocities, or BodyGyro’s behaving incorrectly:
    Verify what material they are now, as these objects are likely to have different masses. You may need to re-tune BodyForces.

  3. Some of your mechanisms have gained a weird vibration and erratic behavior:
    Are your mechanisms combining heavy materials with lighter materials? Hinges and Motors joining objects with huge mass differences may have behavioral issues. If you have a metal-chassis car with small plastic wheels you may experience some problems. Try to decrease the density of the car!

Script 2: Set ALL Densities to 1 (does not include things you load it from assets dynamically)

function recursiveSetAllDensityToOne(instance)
	if instance:IsA("BasePart") then
		-- See if this is a CUSTOM Physics part already
		if instance.CustomPhysicalProperties then
			local oldProp = instance.CustomPhysicalProperties			
			local physicalProp =, 	oldProp.Friction, 
			instance.CustomPhysicalProperties = physicalProp
			local oldProp =		
			local physicalProp =, 	oldProp.Friction, 
			instance.CustomPhysicalProperties = physicalProp	
	for i,v in pairs(instance:GetChildren()) do
		pcall( function()recursiveSetAllDensityToOne(v) end)


Script 2: Set any non-Custom parts to OLD defaults.

function recursiveSetDefaultsToDefault(instance)
	if instance:IsA("BasePart") then
		-- See if this is a CUSTOM Physics part already
		if instance.CustomPhysicalProperties then
			local oldProp = instance.CustomPhysicalProperties			
			local physicalProp =, 	oldProp.Friction, 
			instance.CustomPhysicalProperties = physicalProp
			local physicalProp =, 	0.3, 
			instance.CustomPhysicalProperties = physicalProp	
	for i,v in pairs(instance:GetChildren()) do
		pcall( function()recursiveSetDefaultsToDefault(v) end)


PS: Pardon the spelling/grammar. I have been writing more English today than C++ today, and a sane person can handle that for only so long in a given day. I’m just trying to get this info out to you guys as soon as possible! Post questions here!


Will the terrain material physics be able to be disabled? I don’t want my players having a different gameplay experience just because I wanted to make a small patch of ice.

1 Like

Currently we don’t have a way to disable this behavior for Terrain.

Will FormFactor be deprecated with this update? I feel it should go along with this.

1 Like

Separate update. I now realize the perils of including that section in the picture I had chose. Let me get some scissors.


Will plastic parts behave the same in the new system as the legacy system?

I believe the terrain object should include a toggle to turn off physical behavior.

Forcing physical behavior may restrict a developer’s options when deciding whether or not to use terrain in their game, for fear of the terrain’s properties having an unintended effect on gameplay. Lava terrain doesn’t hurt the character when they touch it, and being underwater doesn’t drown the character either. Behavior like this doesn’t exist because it would clearly have a impact on games that not all developers might agree with. In the same way, ROBLOX shouldn’t force these physical properties upon developers. A toggle that turns off physical behavior of all terrain in the game would completely alleviate this problem.


Mostly the same as old system Default parts. Previously all parts had density 1.0, but the system that I have been testing, plastic had Density 0.7. Friction and Elasticity is the same as defaults however. From my testing I haven’t seen any negative effects from the minor density change.

Can we all just agree we have to hype this?

More on-topic:
If we set Density to 0, does it mean the part has no mass?

Not going to allow it. Minimum settable density is 0.01f. Setting Density to 0 means when you collide you apply a force to a mass-less object. f/m = a. You get infinite acceleration. No bueno.


No density means it can’t be touched, right?
So it would be a part that can’t collide and has no gravity.
(Well, maybe collide as in, fire Touched, but not do physics stuff about it)

Just having a property as GravityAcceleration would be nice too… (just saying hint hint)

1 Like

At that point why wouldn’t you just set it to CanCollide=False and Anchored?

Because in my idea the part still has physics, as in, it can have Velocity and RotVelocity.
It just doesn’t collide or get infuenced by gravity.
(Basicly it keeps moving/rotating at the same speed in the same direction forever until manipulated)

CanCollide=False + Zero Gravity by BodyForce

If your terrain will remain unchanged throughout gameplay, you can add an invisible brick right over the ice. Temporary fix but no one will be the wiser.

@Sharksie @Gusmanak

After talking with some people the plan is as follows:

Release as is (no disabling terrain PhysicalMaterials). You guys should play around and see if using FrictionWeights is enough to deal with this problem. Having a simple “disable” boolean on terrain would be problematic because it doesn’t work like the rest of the feature, its much closer to a workspace flag this way than a “CustomPhysicalProperties” boolean that parts have.

If I can imagine a more in-line solution with what we are looking for, I can imagine us letting you customize how terrain ice behaves specifically (leaving the other values as default). This avoids having a single switch acting as a make it or break it for terrain behavior.

TLDR: Try to see if you actually need the ability to customize terrain, I have a feeling with Friction Weights and Elasticity Weights on other parts will solve pretty much all your problems. If this is not the case, we can add a customization feature to Terrain before the 3-month migration period is over!

Uh. Well, when you throw a ball against the floor, it basically has 0 mass compared to the earth, and it bounces elastically with its maximum change in velocity being equal to 2*(vel.norm)/(norm.norm)*norm, so we know that, at least with non-spinning point masses, you can limit mass to 0 and be okay. Can’t you take the equation and limit one of the masses to 0, and have two cases:
two objects, a and b
amass>0 & bmass>0
amass>0 & bmass==0

And if both a and b have no mass, assume they both have a mass of 1 and solve with the first case.

Of course, the physics engine probably has to deal with multiple collisions at the same time, so maybe it’s too many cases.


Actually, I think this could all be done in terms of mass ratios, that might be cleaner.

So theoretically there is nothing wrong with your example of ball dropping on earth, and the ball might as well have 0 mass when describing the interaction of their momentum.

The problem is that when you get down to the solver level, you are generally storing masses of individual objects as mass-inverses (1 / mass). If you introduce mass ratios, you still have to weigh them against a constant so that the mass ratios are consistent between multiple constraints/collisions. If you’re doing that you might as well just make it so that 0 mass = 0.01 mass. If you’re doing this at the solver level, you might as well not let mass be zero at UI level right?

Hey All,

I’ve configured GameTest1 to function as if we were on the final stage of the new feature migration. Meaning, any place you upload to GT1 will act as if the new system was enabled. Please use this time to do some early testing to see how your games behavior with new Density, Friction, Elasticity settings. Please let me know if you notice any anomalies!

Every time I hop into Play Solo on the GT1 build studio crashes :sad:

Edit: and I get a “fake” crash prompt every time I open the place that says studio crashes but still lets me use studio in the background

Here’s the place file I’m trying to jump into play solo with:
Crashes.rbxl (10.7 KB)