No Angular Velocity With Continuous Collision Detection?

Unity Engine
,
1

See gif of falling wheel, apologies for crappy quality but its good enough to show the issue.

In discrete mode (first run) it behaves as you would realistically expect, the wheel hits the ground and tumbles. But in continuous (normal or dynamic) it seems that only the collision is resolved with no angular momentum added. Not on the first big contact anyway. If I significantly decrease the fixed timestep it works correctly. So its like a deep collision only resolves the collision. But a shallow one also adds some angular force as you would expect.

Is this just a limitation of continuous detection or a bug?

2

Looks like a bug to me. I managed to reproduce it locally and I’m currently investigating. Could you report it as a bug to get the proper Issue Tracker going?

3

Okay thank you. I made an incident bug report and uploaded the basic project. Issue number is IN-37276

4

Hey, so after some digging around, this seems to be by design of PhysX. The code path for adding angular momentum after a sweep-based CCD collision is hidden under a compile time define. The reason is that the angular response from this method often leads to even more tunneling. Nvidia recommends using speculative CCD if angular response is required.
I’ll use your report to update our docs.

1 Like
5

Interesting, thanks for looking into it. I am surprised that this was not already a known limitation, though perhaps it was.

So it seems that if you want lifelike rotation for fast moving bodies the options are speculative CCD, or discrete with a really low fixed time step.

Cheers!

6

I was not aware of it, learned something new :smile:. I quickly scoured old reports and it seems that PhysX 2 in Unity 4 used to properly support this but PhysX 3, 4, and 5 don’t.

Yep, although I’d start with speculative before changing the fixed time step.

1 Like
7

Is changing the fixed time step really that big of a deal?..I mean for say a desktop only game?

I’ve seen behind the scenes stuff for past games where they have run their physics at 360Hz, that’s a significant difference from Unity’s default 50Hz.

I know Unity doesn’t run it exactly like that, it gets called multiple times in succession before rendering. But still kinda the same thing :shrug

8

Changing the fixed time step is no deal at all. Just ensure your target platforms are capable of dealing with the increased CPU consumption.

For example, in the Perrinn 424 project we simulate the physics at 500 Hz (fixed time step = 0.002). It runs perfectly in regular desktop devices (both PC and Mac). Even my 6-year old PC plays this simulation fine from the Unity editor.

That’s incorrect. With the default settings Unity calls the physics simulation at the intervals given by the fixed time step, and introduces frame rendering cycles (Update, LateUpdate etc) between the simulation calls.

For example, at the default fixed rate (50Hz), if your display is configured with vsync at 120 Hz, then Unity will invoke 2-3 rendering cycles beween each simulation cycle. If vsync is disabled, then the rendering cycles between each simulation cycle will increase as much as your CPU and GPU are capable of. However, at a fixed rate of 500 Hz, then Unity will likely have to invoke several simulation cycles between each rendering cycle.

Here you have more details on how the order of the execution actually works in Unity.

2 Likes
9

I am dealing with this issue for a very long time now.
Speculative CCD is not the solution here, in fact, there’s no proper solution for a very basic physics behavior, it is ridiculous that it is “by design”.
Any solution for this? It just got broke in Unity 2022 and on.
This is definitely outraging…