I’ve been told that this issue began with 4.22 when UE changed its physics interface.
When one (or more) objects have CCD enabled and are simulating physics, interactions between both objects tend to cause frequent hitches, or freezes. The objects can be left floating in mid-air for a short time, for example, as the engine tries to get them out of this situation.
Sometimes they freeze before they even collide. Almost as if the engine is overcalculating and preemtively stopping them. But then they get stuck and it takes a noticeable amount of time to get unstuck.
I can confirm that disabling CCD removes this issue but we’re relying on it for our game so it’s a bummer.
We’re using 4.23.
While its possible that the interface changes introduced hitches, I’ve not seen any other reports of this, nor have I been able to reproduce any noticeable hitching of meshes ‘freezing’ in either 4.22 or 4.23. As far as I could tell enabling/disabling CCD at both a component and/or a project level didn’t seem to change this. CCD by its nature is more expensive than not, but I would not expect to see hitches like you describe. Would if be possible for you to provide more detailed repro steps and the exact behavior your seeing, or provide a minimal repro project exhibiting the issue?
Thanks for the project. It seems like the hitches/freezes you’re seeing are due to the objects becoming embedded in each other which can lead to the physics engine not knowing how to perform de-penetration. This looks like its mostly a result of solver instability. Because you have two large opposing forces acting on the same pair of objects and they aren’t dissipated by the initial collision, small inaccuracies can build up in the simulation culminating in the objects becoming embedded in one another. Without CCD, these objects may end up passing through each other entirely. The new interface may have exacerbated this instability, however it would have been there either way. To improve stability you may want to consider reducing the strength of the competing forces and/or reducing the contact time. The physics engine relies on small time-steps for accuracy, so increasing performance, or enabling sub-stepping with decreased delta time and increased iterations, are also ways to improve stability.
We suspected the same, but the behavior can be seen even when the objects never touch. For example, in VR, if two swords swing at each other relatively fast with CCD enabled, they will often freeze up before they even get close to touching, and then proceed to float around each other until they unfreeze.
A bug was submitted by MordenTral detailing this further: UE-82340
I see the bug report. I can’t say I’ve specifically seen a case of the objects freezing, however I have seen similar reports of collision happening too soon. This is typically a result of how the physics engine detects collision in regards to contact offsets and how it can be over eager in some cases. This becomes more severe for faster moving objects/lower frame rates resulting in larger steps per frame, which is likely why it’s more pronounced in VR. In addition to the recommendations above for improving stability, you can also try lowering the contact offset properties directly in the project’s physics settings.
Has this ever been solved? I’m facing the exact same problem right now and didn’t even think of CCD being the problem. Turning CCD off seems to solve the problem, but may cause inconsistent behaviour in my game.
Hello! I have been studying UE PhysX fairly extensively lately and can chime in with some info on the limitations and best practices that may be relevant here:
I have noted using CCD on moving objects causes objects to become stuck together.
Objects of smaller sizes than 1 in game unit travelling at speeds of more than 10,000 in game units often pass through one another.
UE PhysX has it’s limitations and if you want to pass those limitations coding custom solutions are required.
Pretty interesting, I may need a custom solution, however, I forgot to mention I’m using UE5 and do not have the problem with UE4, if I follow the following steps:
create static mesh actor, choose shape_sphere as static mesh component
activate ccd for the component
add high impulse to one direction after like 2 seconds
place actor somewhere in the level where it can collide with a wall
In UE4 this works without any problems for me. In UE5, the hitching and freezing takes place after the impulse is applied.
I’ll have a deeper look, maybe not using CCD could work for me, too.
I’m having the same issue and it happens more often with CCD on, but it’s even happening to the starter content blue chamfer cubes without CCD. In my project I use a physics constraint to ‘hold’ physics actors, while they are being ‘held’ the collision is set to not react to the player. It runs with no issue whatsoever about %99 of the time but sometimes the physics actor will freeze in place and not move until reacted with again. The objects do this while free-floating in the air, sometimes not even near any other objects. I’m desperate for a solution, and I’m willing to give any info needed to help solve this issue. I’m also using Unreal 5.
I’m having exact problem with UE4.27 with CCD fast moving physics objets get stuck for about second, disabling CCD solves this issue, but then objects start to move through each other.
The CCD system is a best-effort conservative advancement scheme. It runs a finite number of CCD substeps (defaulted to 1) and drops any remaining time. Usually, time is only dropped on high-speed objects at the moment of impact so it is not noticeable. However, this artefact can become noticeable if you simulate an object that is sufficiently small/thin relative to the simulation time-step that the object could tunnel if it was accelerated by gravity from rest for 1 frame, i.e. a paper-thin rigid body. Such an object would always be moving at above its CCD velocity threshold and could result in a large proportion of simulation time being dropped for that object and any objects in the same island as it (any objects whose bounds overlap the bounds of that object). This could cause a noticeable slow-down/stuttering effect caused by the objects in that island becoming noticeably out-of-sync with the rest of the simulation. It is therefore recommended that paper-thin/tiny objects should be avoided if possible.