Broken pieces from a Geometry Collection move with one frame delay

Development Asset Creation
, ,
1

When a Geometry Collection is broken by a collision with a moving rigid body, the simulation of the broken pieces seems incorrect. The pieces are assigned the correct velocity on the frame when the breaking event happens, but their position is not updated according to the impulse they have received.

See the example in the attached map. The ball flies towards the box GC:

[Image Removed]

and it breaks the GC on the frame corresponding to the impact; but the GC pieces maintain the initial position on that frame instead of being correctly pushed out (and they interpenetrate with the ball):

[Image Removed]

The pieces start moving on the following frame and only later get pushed out:

[Image Removed]

This looks like a bug since the broken pieces should ideally be pushed out on the same frame when the GC breaks.

[Attachment Removed]

2

Steps to Reproduce
Open BreakWithCollision in the attached project and play. The simulation will pause on the first frame. Step ahead for a few frames. You’ll see the Geometry Collection being broken into pieces but the pieces stay in the initial position, interpenetrating with the ball instead of being pushed away by it.

[Attachment Removed]

3

Hello [mention removed]​

Thank you for reaching out and bringing this issue to our attention.

Also, thank you for taking the time to create a repro project.

I was able to reproduce the behavior you described.

I’m still investigating, but upon verifying with Chaos Visual Debugger, it looks like the GC goes to sleep.

I’ll paste a print for each frame so you can follow what I’m seeing:

Frame 1:

[Image Removed]Frame 2:

[Image Removed]Frame 3:

[Image Removed]Frame 4: [Image Removed]Frame 5:

[Image Removed]

I’ve tried adding a field to keep the GC awake and got a more accurate result.

[Image Removed]Frame 1:

[Image Removed]Frame 2: There is still some interpenetration, but there is no frame delay between the collision and the fragments being moved (it’s hard to tell without a proper reference, but they start moving right away).

[Image Removed]Frame 3: The result looks more accurate as the sphere stops with the forward motion after hitting the GC, indicating that momentum was transferred.

[Image Removed]Frame 4: At this point, they move away from each other, with the sphere moving backwards.

[Image Removed]

I’ve also noticed that you haven’t enabled CCD on the fast-moving sphere.

Once you enable that, there is still some interpenetration, but it looks like the result is closer to the one we see by not letting the GC go to sleep, so you might want to investigate that.

I’ve tested this against a Static Mesh cube, and without CCD there is also interpenetration.

Let me know if this information is helpful.

I’ll make a bug report and include this data as well.

All the best,

[mention removed]​

[Attachment Removed]

4

Hi Rafael,

Thanks for looking into this.

I have tried to enable CCD on the sphere and indeed the interpenetration is minimized. I am still seeing seemingly incorrect behavior though. The GC fragments do move on the frame on the collision/breakage, but the movement is minimal and much less than I would expect. You can see it better if the sphere moves faster and has a higher mass:

Frame 0 (left sphere has 4x speed and 10x mass; right sphere is as before):

[Image Removed]Frame 1

[Image Removed]Frame 2 - the boxes break and move slightly in the direction of the impulse. The box hit by the faster sphere moves slightly more.

[Image Removed]Frame 3 and 4 - the fragments get pushed forward at their correct speed.

[Image Removed] [Image Removed]Note how the faster sphere seems to unrealistically “pause” on frame 2 before resuming movement on frame 3 and 4.

I have attached the latest version of the map for a repro.

[Attachment Removed]

5

Hi

I’m going to try look at running the attached project on my end

There’s few things that comes to my mind that may cause this:

  • the momentum restoring feature :
    • we restore some momentum to the impacting object in order to not be stop instantly by the larger object collision while it could break through the smaller fragment ( and because of the way we swap larger cluster for smaller ones in the solver )
    • there’s a cvar : p.RestoreBreakingMomentumPercent that is set to 0.5 right now
    • I’d recommend trying with it set to 0 and see if that changes the behavior
  • When we break from a cluster to smaller pieces , we have a simple way we transfer the linear and angular components to the children that could certainly be improved ( especially on the angular side )
    • This one may be a contributing factor , but I suspect the momentum restoring feature to have a larger effect , as it will keep the sphere to move forward

I’ll try this on my end too and will report later

[Attachment Removed]

6

Hi

I got the core physics team to help on that and the issue is coming from the limits on the pushout velocity when de-penetrating the rigid bodies after the collision solve phase

By default the limit is set to 1000 as shown below in the project settings

[Image Removed]You can increase this value or set it to 0 ( which means infinite velocity )

I tried your level with a value of 0 and the collision was fully resolve in one frame

[Attachment Removed]

7

Hi Cedric,

Thanks for looking into this. Here’s what I am seeing:

  • Setting RestoreBreakingMomentumPercent to 0 reduces the “re-acceleration” of the sphere post-break, but the effect is still there. It can be visible by setting a higher mass on the sphere (5000).
  • Setting the pushout velocity limit to 0 did not affect the CCD collisions (by design I guess, since there is no penetration in the first place?). With DCD it fixes the collisions in the last map I attached, but it doesn’t seem to work fully if I scale the objects up (repro attached): [Image Removed]
    [Attachment Removed]
8

Hi,

RestoreBreakingMomentumPercent set to 0 does not cancel out the natural momentum left in the sphere after the collision with the initial clustered object, that’s why you are seeing it still moving forward especially when increasing the mass

Regarding the large sphere / box collision in the screenshot, I had a look at the project and the issue comes from the fact that you are using a non uniform scale for the sphere while keeping a simple sphere collider

Chaos uses the shorter axis as the radius for scaling the sphere to be conservative which result in a visual interpenetration of the objects

I recommend using a convex if you want to be able to handle non uniform scaling in that case

[Image Removed]

[Attachment Removed]

9

Hi Cedric,

Good catch, I didn’t realize that the collider wasn’t scaled. If I use a uniform scale there is indeed no penetration.

> RestoreBreakingMomentumPercent set to 0 does not cancel out the natural momentum left in the sphere after the collision with the initial clustered object, that’s why you are seeing it still moving forward especially when increasing the mass

That’s right, but what I’d expect to see with RestoreBreakingMomentumPercent = 0 is:

  • body moves with velocity V during frames 0...N-1
  • body breaks GC on frame N, loses momentum, moves with velocity V - X during frame N until end

Could you confirm that this expectation is correct?

What I see instead is:

  • body moves with velocity V during frames 0...N-1
  • body breaks GC on frame N, moves with velocity ~0 during frame N
  • body moves with velocity V - X during frame N+1 until end

[Attachment Removed]

10

What you see is likely an artefact of the fact that the breaks are processed at the end of the physics frame

Clustering.AdvanceClustering is called after integration and solve

So what happen , is that the sphere will detect the collision with the unbroken object, collisions will be detected and resolved, stopping the sphere in its position at frame N

then break will happen and new rigid bodies bodies will released and momentum on the sphere is restored

the sphere will start moving at frame N+1 when the integration happens and the solver runs a new loop

We have discussed many time ways we can fix that ( like running extra steps after AdvanceClustering - that could require collision detection and another solve but that could also lead to more destruction :slight_smile: ) but we haven’t had the chance to tackle this yet

[Attachment Removed]

11

Sorry for the late answer Cedric - thank you for the explanation! Is there an issue on the tracker I can reference for this?

[Attachment Removed]

12

Sorry for the delay , here’s a public reference to the issue

https://issues.unrealengine.com/issue/UE-372244

[Attachment Removed]