Video of the bug: UE4 4.18 (and previous) physics time dilation bug - YouTube
Physics acts differently with different global time dilations. Including breaking apart / erratic behavior on physics objects and ragdolls.
Replicate the error:
- Create a new project with the First Person template
- Add a key to toggle Global Time Dilation from 0.1 to 1 in the character BP (or use any numbers)
- Create a new actor and add a cube. Turn Simulate Physics on.
- Create a stack of cubes.
- Enter the game and press the time dilation key. The cubes will separate when you press the key, repeated pressing causes them to gain more and more speed until they are flying apart from each other, even if they were stationary before you began.
- Push one of the cubes with and without time dilation; they will be pushed entirely differently.
- To test with Ragdolls, create a bind to turn on / off physics simulation on all bodies, test it with the time dilation and you will get a different result.
What I’ve tried:
- Turning on substepping, this doesn’t appear to fix anything although maybe the settings I have tested aren’t correct, or aren’t applying - it seems to make little to no effect.
- Different engine versions, it seems to occur in 4.16, 4.17 and 4.18
Hey,
So I went through your repro steps and I couldn’t replicate the issue in 4.18.
- I made a new first person project
- Added a toggle for Global Time Dilation. Set it 0.1 and 1
- Made a cube actor with simulate physics on
- Added a stack of cubes and tested the Global Time Dilation with them
Results: They acted “normal” as in they didn’t move when I toggled between the Global Time Dilations. When I knocked them down they fell as they should. However for the ragdolls and other skeletal mesh actors the result you got is expected behavior due to limitations with PhysX. If you could, can you send me the project you replicated this is in so I can see the issue with your cube actors?
http://lmargison.com/Fileshare/DilationProject/DilationBug.rar
Here’s the project file, I followed exactly those steps you said. I have used the “F” key to toggle the time dilation.
If you press it and hold it you will see a subtle movement where the boxes shift/begin to float, until you let go. If you repeatedly tap it they quickly fall apart.
As for the ragdoll limitation, would it not be possible for the engine to effectively ‘downsample’ the physics calculation and blend between poses for ragdolls? I’m doing something similar but manually via blueprints, where I simulate the ragdoll in realtime and save the poses, then blend through them, but it’s messy and wouldn’t work for all use-cases. If the engine could separately run realtime physics on them but play it back in slowmotion to the user it would bypass the limitation.
Hey,
I was able to get information about this from Nvidia. I’ve been informed that PhysX should generate smooth behavior at smaller timesteps up to around 0.03s. A dramatic switch in time dilation won’t guarantee smooth results and causes static meshes, like cubes, to behave as you’ve shown. We do have a bug logged for skeletal meshes that is being investigated for erratic behavior with their physics when changing time dilation multiple times in rapid succession.
Thank you for your time and effort in regards to this.
I’ve been informed that PhysX should generate smooth behavior at smaller timesteps up to around 0.03s
Could you elaborate on this? Am I right in thinking that if the timedilation changes at 0.03 or less per frame it should stay smooth? Not sure if I’m misunderstanding.
We do have a bug logged for skeletal meshes that is being investigated for erratic behavior with their physics when changing time dilation multiple times in rapid succession.
The erratic behaviour seems to happen even if the time dilation is set at a constant rate (eg. it’s 0.1 the whole time, the skeletal mesh will wobble and move a lot more than with 1.0)
Thanks for the help
To answer your first question, timedilations should act smooth at rates between 0.1 and 1 but jumping between two timedilations in a short period casues the static mesh actors to accelerate and decelerate. This leads to the cubes wobbling around and moving irradically. To further elaborate for the smoothest frame rate experience it would need to go from 1 to 0.97 to 0.94 and so on per frame.
In regards to your second question, I did some more research and experimentation in editor and saw that the cubes (static mesh actors) did not behave irradically when falling at dilation speeds of 0.03, 0.1, 0.2, and 0.3. I tested this in the project you provided and held down the ‘F’ key until the cubes settled. I did not jump to the default speed at all in those tests.