Question Help with Physics.Simulate() on local physics scene.

I'm not a 3D physics dev but all Local Physics Scenes of which the default is one (just the default one) all use the global settings. Also, when you set the bounce threshold, it iterates all physics scenes and sets them individually. A test would be to have the bounce threshold set to something obvious you can check and see if it's applied to the default physics scene and not one you create. Or create two physics scenes and compare them.

Also, the Physics.Simulate() call and Unity automatically calling simulate are the exact same code-path.

If you think there's a bug then you're best to submit a bug report so it can be looked at.

 

Feel free to ask though if something isn't making sense.

 

Test 1 makes it very clear that something to do with the bounce-threshold is wrong. This would suggest that, for some reason, when the local physics scene is created, it's not having this set. But this cannot be true (on the face of it, looking at the code) because the "default" one is created in the same way in the same bit of code, there's a "CreateScene()" call. So that is strange.

Test 1, it's not clear how dragging is moving to another scene. I can only presume you do that as part of the dragging but yes, seems to confirm bounce-threshold not correct for sure.

Test 3, if I follow correctly, would seem to confirm that the initial bounce-threshold then isn't being applied and being that I can see it is applied (in the PhysX Scene Description) then that is very confusing.

They do go through the same code path. There's a single entry point in common which does all the simulation work. There's no special preparation before that whether it comes from Unity or from the scripts. The only thing that differs is where the time-step value comes from and the scene settings.

Although I'm confused on the comparison between the above two things. Physics.Simulate just automatically grabs the default scene because it doesn't have a scene argument. It then calls that scene via physicsScene.Simulate. It is the same. They both call Simulate_Internal which calls the C++ method "Simulate"

Don't take my word for it though, the code for this is public here.

Here's the start of the C++ side. PhysicsManager::Simulate is what "Simulate_Internal" calls:

Code (CSharp):

1. void PhysicsManager::FixedUpdate()
2. {
3.     if (!m_AutoSimulation)
4.         return; // in this mode the users are expected to call Simulate themselves
5.  
6.     float dt = GetTimeManager().GetFixedDeltaTime();
7.  
8.     Simulate(GetDefaultPhysicsSceneHandle(), dt);
9. }
10.  
11. void PhysicsManager::Simulate(PhysicsSceneHandle sceneHandle, float dt)
12. {
13.     // Fetch the physics scene.
14.     PhysicsScene* physicsScene = GetPhysicsScene(sceneHandle);
15.     if (physicsScene == NULL)
16.     {
17.         WarningString("Physics.Simulate(...) was called with an invalid scene handle therefore the simulation was not run.");
18.         return;
19.     }
20.  
21.  
22. ...

I added the FixedUpdate portion too. This is internal to Unity and you can see that all it does is call the exact same code-path above.

The only differences possible are the physics scene i.e. the physics world and its settings.

Conclusion

Whilst I'm not a 3D physics dev and this isn't my responsibility, I do know enough about this to continue helping you. If you don't mind, could you host your Test 1 set-up somewhere so I can take a look at it? If you want me to host it for you, DM me with your email and I'll set-up a private workspace only you and I can use for you to upload. Better still, you could submit this as a bug because this really does look wrong and I can take a look. I won't be the person fixing it but I can try to fast-track the confirmation of the bug and possibly submit a potential fix to the 3D team to verify.

Hope this helps and thanks for taking the time to clearly demonstrate the issue.

 

Maybe, sort of looks like way but potentially it's something related to PhysicsMaterial bounce (restitution) although that would be easy to test if the collision were at a low angle and the friction were high.

Do you have the case number?

 

Sounds like something was fixed. Note that I was looking specifically at our trunk code which is 2022.2.

I'll take a look though at it, thanks.

 

So yes, I found a change in 2020 onwards. It was fixed via this report: https://issuetracker.unity3d.com/is...t-bouncethreshold-that-predate-their-creation

The change was indeed related to when the local physics world (scene) was created where it copies all the global settings; it was missing the bounce threshold. It seems the update of that setting was already being applied to all scenes so that part works.

 

It would seem that way yes.

 

So I just took a look at the C++ source but it checks to see if the threshold has changed so as to avoid unnecessary work so you'd need to alter first to something different than what it is and then back to whatever value it was unfortunately i.e. something like:

Code (CSharp):

1. var threshold = Physics.bounceThreshold;
2. Physics.bounceThreshold = threshold + 0.1f
3. Physics.bounceThreshold = threshold;

Awful workaround but in theory it will work.

 

Good to hear, good luck!