[Full Release] Important Changes to Inertia and Volume Calculations

[vespa_rbx]

This is a multi-phase change - please see below for the latest updates

In an effort to make physics behavior more consistent and accurate to the real-world we are introducing a few physics-related changes and would love your feedback:

• All part types would now be considered as solid bodies.
• Fixing an issue where Wedges and CornerWedges calculated mass and volume incorrectly.

All these changes affect body mass properties and may affect physics in experiences. Please read more to learn if your experience will be affected and any next steps.

While we are planning to roll this from Opt-in to Full Release over the coming months we are open to feedback and adjustments. See the timeline and additional updates at the bottom for more information.

---

Overview of Changes

Current State

Previously we had inconsistencies in mass properties for parts:

• Some parts were considered to be hollow (block, wedge, corner wedge), others were solid (sphere, cylinder).
• All imported meshes were considered to be solid in closed geometry.
• For mass calculations, we consider density evenly distributed like for a solid body, however for inertia calculations of a block for example the mass was concentrated on the surface (hollow body).

Volume:

• Wedge and CornerWedge volume calculations were incorrect as volume was equal to the bounding box.

Updated State

Consistency for all parts:

• All parts are now solid bodies.
• Mass is evenly distributed across the body and consistent with density distribution.

Volume:

• Wedge and CornerWedge volume calculations have been fixed.

Here’s a full overview of these changes:

Part	Before	After
Sphere	- Solid body	- No changes
Cylinder	- Solid body	- No changes
Block	- Hollow shell - All mass concentrated at the hull of the block	- Solid body - All mass evenly distributed throughout the block
Wedge	- Hollow shell - All mass concentrated at the hull of the bounding box “block”, doesn’t match the wedge form - Volume equal to the bounding box	- Solid body - All mass evenly distributed throughout the wedge - Volume math is corrected, V = ½ of bounding box volume - Mass properties reflect wedge form
CornerWedge	- Hollow shell - All mass concentrated at the hull of the bounding box “block”, doesn’t match the wedge form - Volume equal to the bounding box	- Solid body - All mass evenly distributed throughout the corner wedge - Volume math is corrected, V = ⅓ of bounding box volume - Mass properties reflect corner wedge form

Examples

Block Moments of Inertia

Old Block Inertia:

New Block Inertia:

Place:

MomentComparison.rbxl (37.7 KB) thanks to @AxisAngle for providing the example (see Blocks Moment of Inertia is Wrong)

Wedge Moments of Inertia

Place:
MomentsWedges.rbxl (38.5 KB)

CornerWedge Volume Affecting Mass

Place:
CornerWedgeMass.rbxl (31.3 KB)

---

How to Use

The new behavior is available by enabling the Workspace.PhysicsInertiaAndVolumeFix property.

You can enable it temporarily in testing to see how your experience behaves and if any adjustments are necessary.

If you want this to be available in live experience, you need to enable this property and publish your changes.

---

Effects of Changes

In many cases, the change won’t really affect simple mechanisms’ behavior and may only affect complex mechanisms introducing some instabilities due to overall lower inertia.

Volume changes

With Wedge and Corner Wedge volume calculations fixed volume gets two times smaller for Wedges and three times for Corner Wedges. With reduced volume mass will be proportionally reduced.

Inertia changes

With bodies becoming solid, the mass will be distributed evenly across the volume. As a result, inertia becomes smaller and parts tend to start and stop moving more easily in response to external forces.

---

Next Steps

This is a major physics change and as such we will be rolling out these changes over time. The timeline below is tentative. We understand this could have a major effect on some experiences and we want to work with you to address cases even if that means delaying changes on our end.

First Phase - Opt-in (Ended June 16, 2022)

• Workspace.PhysicsInertiaAndVolumeFix will stay in Default=Disabled, developers can enable for testing or in published experiences.
• We highly encourage developers to try this and see if their experiences need to be adjusted.
• This period will last two to four weeks depending on the impact.

Second Phase - Opt-out (Current Phase)

• Workspace.PhysicsInertiaAndVolumeFix will be set to Default=Enabled.
• If you see issues in your experience as a result then you can disable it.
• This period would last three to four weeks and should be used as a chance to troubleshoot unexpected behavior.

Third Phase - Full Release

• This change will be enabled on all experiences by default.
• This will close the cycle and experiences will no longer be able to opt-out.

---

Thanks for reading! Please flip these settings on and let us know any feedback or questions you may have.

Updates

June 14, 2022 - Beginning Opt-Out Phase

[Full Release] Important Changes to Inertia and Volume Calculations

Thanks so much for all your feedback! Later this week on Thursday, June 16th we will begin the Opt-out Phase. The Opt-out phase will last for three to four weeks, before moving to the full release. During this time we invite any and all feedback! Thanks again.

June 22, 2022 - Opt-Out Ending August 1st

[Full Release] Important Changes to Inertia and Volume Calculations

Hello developers, We’re one month into the opt-out phase and are glad to see that most places are now using the new inertia changes. However, there is a very small percentage of places that have not yet updated and we are nearing the window where we will be disabling the opt-out capability. Please review and take the time to update your experiences before August 1. If you have any issues updating your experience please reply to this thread as soon as possible so we can help.

August 1, 2022 - Full Release

[Full Release] Important Changes to Inertia and Volume Calculations

Hey developers, Thank you for your continued feedback throughout this process. As of August 1, 2022 we have moved to the full release. This is now enabled for every place on the platform. If you have any feedback or questions feel free to continue to reply in this thread!

[Cabdevs11 (Dev)]

Question why wou

@vespa_rbx

Third Phase - Full Release

• This change will be enabled on all experiences by default.

Why would you make default though for experiences because it should be up to developers if they want it or not right?

[iGottic]

@vespa_rbx

Third Phase - Full Release

When will this be, approximately?

[tnavarts]

The key thing to understand with options is that they combine exponentially complexity wise. If you have three options, there are eight possible combinations of options. The more combinations of options there are the harder a given engine subsystem is to test and eliminate the bugs from.

That means that we can’t afford to add an option for every little thing that changes in the engine, otherwise the engine would become so hard to test and keep stable over time that we wouldn’t have any time left to develop new features.

So the question isn’t really whether to add an option for something, it’s whether to spend an option on something: That is, an option we’re adding for something is really an option we’re also not adding to something else, in order to keep the number of options in check.

So, ask yourself, when asking for a permanent option like this: Is this something you think it’s worth spending an option on?

[vespa_rbx]

tentatively in 2-3 month, we will be observing how transition is going on, this may extend the timeline

[Cabdevs11 (Dev)]

Oh ok I get it now that you said that.

[Abcreator]

No offence, but I find it a bit disappointing that Roblox as-of-recently has been making more changes with things that we as the developers cannot edit (for example, in this case we can’t edit how mass is calculated, etc.)

Personally I would prefer if Roblox were to instead invest to try and give us (the developers) more control over what these systems do and let us instead contribute fixes etc. through community resources. Not only would this allow for more complex things in-experience to made, but it would also not require a multitude of different settings (or worse, no way to revert to before the update) as developers would be providing any additional settings through their own code.

[PeZsmistic]

I’m testing this out with my custom characters, some of them have some custom physics tuning (e.g. those with physically simulated tails and snakes) and not noticing anything too severe.

However I do have a snake character that seems mildly affected, it sometimes has issues with tripping itself and it seems more prone to tripping itself with this property enabled + it has trouble getting back up. Once I turn the property back off it starts getting back up right away.

I tried to fix this by adjusting the rootpart density among other things but it doesn’t seem to help. Either way it’s not too big of an issue and I could probably mitigate it with a gentle bodygyro (I thought I already did this but I was mistaken), but it would be amazing if humanoid forces and settings for things like them being trippable or how long they stay tripped could be clearly exposed; then I wouldn’t need bodymover hacks.

anonymous

anonymous

Other creatures (huge, tiny, flying, swimming) are otherwise not affected any appreciable amount. This is probably because these are mostly made of MeshParts.

[Water_Script]

Because it was not an intended feature for how things were to work. It was a bug. Roblox is giving us plenty of time to shift into this new fix. Since this is ultimately a bug, it needs to be fixed at some point. It does not make sense to always have an option to keep a bug when it is just that: a bug that was not supposed to be there in the first place.

[Abcreator]

@Water_Script

Since this is ultimately a bug, it needs to be fixed at some point. It does not make sense to always have an option to keep a bug when it is just that: a bug

Backwards-compatability was always the word on Roblox’s mind for years, many Roblox developers have learned to use these ‘bugs’ to their advantage and personally I feel that Roblox should embrace that and as a result at least leave the option to keep the ‘bug’. Sure, support will likely be non-existent for those who keep the bug, but if a developers decides to keep it, then it’s on them…

[vespa_rbx]

Thanks for your detailed report, if you would DM me an example of this problem we could figure out a workaround

[Water_Script]

Backward compatibility for previous features, not bugs. A bug is unintended. Backward compatibility preserves older features and the uses of them. A bug is an unintended feature sure, but it is still unintended. That is why you patch them; so that things function how they are supposed to.

[Hexcede]

This is awesome, and explains so many odd inconsistencies I’ve experienced in the past and never figured out. I’m super excited to see how this effects a lot of my physics code.

@PeZsmistic

but it would be amazing if humanoid forces and settings for things like them being trippable or how long they stay tripped could be clearly exposed

Actually, I believe you can disable it! This is a humanoid state, and you can disable them preventing the engine from setting them at all.

Particularly, it’s the first state, Enum.HumanoidStateType.FallingDown. You may also want to disable Enum.HumanoidStateType.Ragdoll, but, the last time I saw this actually trigger (if I understand the mechanic right) was in 2013 or 2014 I believe, I’m not sure that it actually works/is enabled anymore.

[BillB1ox (Will)]

This has fixed a minor issue with karts in the upcoming version of Bloxy Kart. Glad to see that I do not need to do anything except toggle something.

[heedicalking]

I still don’t understand why we can’t just edit the mass property of parts. It’s a feature in almost every other engine out there.

[nooneisback]

One partially related question. Wouldn’t it be better if we could manually set the mass without having to awkwardly fiddle around with the part density? In particular, I had an issue when working on a car where I had to use a giant uncollideable block to preciselly manipulate the car’s center of mass.

[Scottifly]

Dangit, another change of Mass & Density resulting in changing buoyancy of items in water.

I have a boat game that relies on physics to float boats and make them sink or be unstable. They are mostly made using WedgeParts, Parts, and CornerWedgeParts.
I remember there was a very big change in water physics years ago (I think it was when CustomPhysicalProperties was released) that drastically affected my boats and took me a day or so to figure out. Even after fine-tuning the boats again they never really reacted as nicely as they did before the change.

[KristinaMoment (Kristina)]

@vespa_rbx

This will close the cycle and experiences will no longer be able to opt-out.

Can you just allow us to be able to choose whether a feature is on or not for a toggle just for once? It’s happened with animations, almost materials, tostring() and much more, I thought this platform was Powering Imagination?

[VortexColor]

Will this have any negative performance implications. Boxes and wedges are probably easy for the engine to optimise because they aren’t meshesh but simple geometry, so I hope this doesn’t have any negative performance implications (even minor ones).