re: https://issuetracker.unity3d.com/issues/dots-physics-center-of-mass-does-not-apply-when-entering-the-play-mode
Have you guys narrowed this down? I see its under consideration for 1.0.x but I would appreciate just a quick local fix I can apply if you have one figured out
#ECSB-367 - incorrect physics center of mass
fossil socket
nimble slate
cc @brave orbit
brave orbit
Let me have a look.
@fossil socket : I am downloading the test project right now. In the meantime, is it possible that the trash bags on the left are actually the PhysX ones which, in a recent Unity Physics version, are not simulated anymore when a subscene is open? This is to deal with clashes between PhysX and Unity Physics causing the scenes to loose their authoring state. That would explain why they don't move.
If you close the subscene, does the behavior between Unity Physics and PhysX match?
fossil socket
no, its the center of mass when baked. deleted the project prematurely but i think the center of mass from physx rigidbody baked to dots appears that physx by default uses the averaged center of the mesh, and dots uses the pivot of the mesh.
when you close the subscene there should be different behaviour from left to right though iirc they should be using the same settings for center of mass
additionally changing the center of mass in the physx rigidbody does not appear to have any bearing on what the baked center of mass is
brave orbit
Ok. So it's not about whether these objects move or not. It's about where specifically their center of mass is. That makes more sense.
With the subscene open, the issue description is somewhat misleading 😅
"Reproduction steps:
- Open the attached “Test Project” project
- Open the “Scenes/SampleScene” Scene
- Enter Play Mode
- Observe the Game View
Expected result: 3 “TrashBag” GOs on the left of the Game View fall down
Actual result: 3 “TrashBag” GOs on the left of the Game View do not move
Reproducible with: 1.0.0-pre.65, 1.0.8 (2022.2.21f1, 2023.1.0b17, 2023.2.0a16)
Not reproducible with: 1.0.0-pre.44 (2022.2.21f1, 2023.1.0b17, 2023.2.0a16)
Couldn’t test with: 2020.3.48f1, 2021.3.26f1 - No support for Entities Graphics"
If you see the video above, the trash bags on the left do in fact not fall down, but they are not even affected by gravity whatsoever since the simulation for these is turned off.
fossil socket
fairly certain thats not what i wrote
brave orbit
Yeah. I will correct that.
In IN-41446 it says exactly that.
But in any case, if I understand you correctly, when the trash bags are landing on the ground the behavior between PhysX and Unity Physics is different
And this is because of the center of mass supposedly
(could be the inertia tensor also, but I'll check it out)
fossil socket
i also noticed IN-34662 the title and repro steps seem to have been edited(fairly certain i didnt title it as joints spaced too far apart when baked - though that was observed when I reported that report)
brave orbit
So, to confirm my understanding, you would expect the way they fall over to be the same in PhysX and Unity Physics, correct?
fossil socket
yeah just seems to be the center of mass baking difference between
simulated dots (physx rigidbody -baked-> dots)
vs
simulated physx (physx as a gameobject)
brave orbit
Ok cool. I'll check this out.
Regarding IN-34662, this might be fixed already in a future version. Without now drilling into this too much (since it's not related to the issue this thread is for), the problem might have been due to scaling of your game objects.
The scale was not correctly considered when baking built-in physics joints (Configurable Joint, Hinge, Spring etc.), which lead to the joints being offset (spaced apart if you will). This is already corrected in our latest code base.
brave orbit
@fossil socket : I can confirm that the issue is that the default spherical inertia tensor is used for all of these objects in Unity Physics, which is a bug that was already fixed in a future version.
Here you can see the Unity Physics rigid bodies on the right all using the same spherical inertia tensor (for a unit sphere).
In order to work around the issue, you can apply the following one liner fix:
Add this line here:
In com.unity.physics/Unity.Physics.Hybrid/EntitiesBaking/BakingSystems/RigidbodyBakingSystem.cs
fossil socket
hmm so it still seems like I still cant set the center of mass for a physx rigidbody, though it does mimic the previous behaviour
brave orbit
Yeah, looks like this doesn't work.
The left one is a built-in Rigidbody and the right one is a PhysicsBody. Both have the same inertia tensor and center of mass (default, automatic), despite me overriding the inertia and com in the built-in Rigidbody on the left. So that's definitely a bug.
(on top of the bug that in the latest 1.0.X version we use spherical inertia for built-in, which is fixed with the change I suggested above)
brave orbit
Alright, so I have a fix for this. I can share the code here for now and we will get this as a fix into an upcoming release.
@fossil socket : This should work with the latest 1.0.X version of Unity Physics. Let me know how it goes.
fossil socket
thanks, that seems to do the trick.
brave orbit
Great. I'll prepare the patch then.