If the Cube is a Weld, it doesn’t seem to impact the physics.
However, if the Cube is connected through AlignPosition with RigidityEnabled and ReactionForceEnabled it is impacting the Sphere’s Physics. Despite Massless being enabled.
Though when RigidityEnabled is set to true the affected Part would change NetworkOwnership to whatever the constraint is attached to, similar to as if you welded it. But what’s the intended behavior for the Mass and the Physics?
And I don’t think there’s a way to solve that, like the Weld solves it (but doesn’t lock the axis).
But is setting everything in CustomPhysicalProperties to 0, the correct and exact solution?
Re-production Steps
See the uploaded files and videos in the Private Message.
Hi Karl, thanks for posting. Everything you’ve observed is correct, and it comes down to how we treat mass when using welds vs physical constraints.
When you weld parts together, you are creating a single Assembly, which is represented in the physics engine as a single rigid body. From the documentation on BasePart.Massless:
If this property is enabled, the part will not contribute to the total mass or inertia of its assembly as long as it is welded to another part that has mass.
So, when you weld the cube to the sphere, the cube will not influence the mass/inertia of the resulting assembly when Massless is enabled.
Constraints (like AlignPosition) work differently. Unlike welds, connecting two parts with a constraint does not create a single Assembly. In this case, the sphere and cube remain two separate assemblies, each represented by a separate rigid body with their own mass and inertia. This is true even when RigidityEnabled is enabled. Behind the scenes, RigidityEnabled just changes the mathematical formulation of the constraint being used, but we still treat the sphere and cube as separate rigid bodies.
For single part assemblies like the cube, the Massless property doesn’t do anything. The only way to change the mass of the cube is to change its density, but note that we clamp the minimum density. The physics engine determines how assemblies should move by solving F = ma. If we allowed assemblies to have zero mass, we would get infinite accelerations and…
In general, adding physical constraints between parts with very different masses should be avoided. The physics engine struggles to converge when high mass ratios are present. In the case you’re considering, distributing the mass roughly equally across the sphere and cube would make the physics engine happiest.
If that would make both spheres, with and without cube, equal.
I don’t know if Density at lowest amount is considered equal. I guess if the cube still has mass, I guess not? Not sure if it’s only equal if the total mass is equal?
Not sure about the other physical properties though.
But the NetworkOwnership isn’t separate.
Unless that’s intended.
Is the minimum Density the same as Welding something, or not?
Would a Weld that doesn’t inherit axis be realistic for having stay on one rigid body?
If I’d alter the sphere and the cubes Density and the rest, or create a second sphere. And make it so the total would match up the other sphere. Would it then be equal?
Would a Weld that doesn’t inherit axis be realistic for a Physics Engine?
No, physics engines all operate on rigid bodies, and all “parts” of a rigid body must move and rotate together.
You can always kinematically move the cube to the sphere’s position and give it the same velocity and whatever orientation you want. But getting the correct dynamics would require the cube to have a nonzero mass and inertia.
If I’d alter the sphere and the cubes Density and the rest, or create a second sphere. And make it so the total would match up the other sphere. Would it then be equal?
You can get the total mass to be equal by splitting the mass across two rigid bodies however you’d like. Getting the inertia to be exactly equal will, in general, be impossible since the sphere will be free to rotate but I’m guessing you don’t want the cube to rotate.
What’s the purpose of this movement?
I’d guess it’s a ball rolling in a 3D environment with the cube visible as moving across surfaces.
If not and you are moving across a flat plane, or in one dimension, it may be easier to use a CFrame Position for an anchored cube.
Of course if the ball is physics based and the cube is CFramed there’d likely be a visual difference in Position depending on the speed of the ball/cube and the users ping.
But these operations are costly, if it’s done too much it will need throttling or some kind of scheduling, but it could bring delay as well.
But maybe what I saw in some different game, could have been a bug in whatever they were doing. I still don’t know, I made MicroProfiler tests and sent it to Roblox Staff to ask them about the differences.
