Issue with position based physic solver

Development Asset Creation
, ,
1

Hi,

I’m having issues with chaos solver when high speed objects are colliding head-to-head.

The objects being at very high speed, instead of being pushed away from where they came from, they climb onto one another.

From what I understand, Chaos default solver is position based, meaning that on interpenetration it tries to find the closest non colliding state for each object ; and when the interpenetration is to high, it results in the behavior described above.

So my question is, does Chaos provide a velocity-based solver, and if not, can I get close to the behavior of said solver by changing engine/objects parameters?

A few more informations about the issue :

  • The shapes thinnest areas are about 60cm wide, ideally I would like not to modify them
  • They go up to 200 km/h (meaning a maximum of 400km/h difference when they collide)

Thank you for your help,

Cheers,

Nicolas

2

Hello [mention removed]​

Thank you for reaching out.

Have you tried enabling CCD?

[Image Removed]Let me know.

All the best,

[mention removed]​

3

Hey Rafael,

Thank you for taking the time to answer.

CCD is enabled for both objects, it helps with collision detection, not for solving from what understand

Here are the current solver settings :

[Image Removed]

Cheers,

Nicolas

4

Hi Rafael,

Please find attached a repro project, to launch it you can open VehicleExampleMap and just press play.

You’ll notice (through ChaosVisualDebugger) that upon collision, normals correct vehicle bodies so they stack onto each other instead of launching them away from each other.

Cheers,

Nicolas

5

Hi Rafael,

Thank you for digging into the issue.

Yes your first screenshot shows the behavior I want to avoid.

As for CCD not actually being enabled in the physics body, you’re right I forgot about that in the repro project, although I did notice it in my actual project and forced it through code.

So I enabled it in the physic asset to match your previous post in the repro project on my end and here’s what I’m getting.

The unwanted behavior is still happening even with CCD enabled, you can notice the contact normals pointing down.

It result in vehicles being expelled respectively upwards and downwards.

[Image Removed]When the physics step ends with a low amount of body penetration, the contact normals are as expected and the bodies are expelled away from each other.

[Image Removed]I would like to ensure this is the outcome everytime, for now it seems to depend on the penetration distance at the end the physics step where the collision is detected.

All the best,

Nicolas

6

Hi Rafael,

Having an overly simplified version of the collider is kind of my last resort.

Although I can’t afford primitives nor colliders that differ that much from the visual mesh because other parts of the game rely on contact points being relatively accurate.

I also tried a simple collider for collisions with high speed objects and detailed collider for collisions with static meshes.

It ended reaching another physics solver limit as it was having trouble finding contact points and was not solving the collision at all.

Please find more details about this here :

[Content removed]

I fear that the setup you tried above will stumble upon the exact same issue.

I would rather find a way to keep convex shapes close to visual meshes, even if it takes a performace toll

Best regards,

Nicolas

7

Hi folks. George Bain (Carpool’s TAM) has asked me to jump into this thread.

Thank you Rafael for looking into this (and for context, he has been asking me questions in the background for this ticket).

The reason why the cars are mounting each other is because the collision detection has calculated that the shortest path to de-penetration is that direction. If you take a look at the triangles, many of them are not perpendicular to the ground. The way the collision detection/resolution system works is by discrete timesteps, do there will be penetration, and if those non perpendicular triangles are part of the collision there will be an upwards impulse applied.

I’d be wary of trying to go down the ‘ultra accurate route’ you suggest - it could be done by making the CCD more precise - but this will cost a fair amount.

I’d also be curious if you are planning to replay these events? Especially with a slowmotion side. If not, and if they are going to be crashing at a potentially 400kmph velocity, it would be difficult for a player to see any inaccuracies, so there may be some room there to alter the geometry.

I’ve had similar issues with productions I’ve been involved with, and there are generally 2 ways to resolve this. The first is the one which Rafael has suggested - essentially you alter the geometry to put a bumper car type shape around the lower part of the car which has all vertical triangles, but tracks the visual mesh as closely as possible. The second is to alter the collision impulses in a handler to remove any vertical component to the collision impulse - that can be extremely hard to tune correctly though - and may also cause penetration and strange collisions.

I’d strongly suggest CCD and altering the collision geometry to resolve this as a first step - that should get you to what you need in most cases.

All the best

Geoff Stacey

Developer

8

Hi Geoff,

Thank you for taking a look at this thread.

Here’s some more details, hopefully it helps you getting a better overview :

First off CCD is enabled, I double checked in the Chaos Visual Debugger, I forgot to check it directly in the physics shape in the repro project.

Our vehicles can go from very low speed to 200 km/h, hence the repro project simulating a collision with a 400 km/h impact speed which is our most extreme scenario (max speed front collision).

I don’t need collisions to be “ultra accurate” but roughly accurate, the box shown in Rafael’s answer is too far from the visual mesh, we can’t afford to have a box collision for a rounded shaped vehicle.

A couple reasons for this, as you mentioned, replay and slow motion are indeed planned, the upper part of the vehicle can also be subject to collisions with other dynamic objects (which I don’t need to be as accurate as front and side collisions though), and low speed collisions are quite common and need to be believable (not realistic)

Fiddling with collision shapes and making them a lot “higher” than the visual mesh does fix the issue but I would like them to be roughly the height of the vehicle, I’ll try adding again a bumper collider as you suggested, hopefully the solver can deal with the multiple colliders now that they are simplified.

Also, I’m already altering the collision impulses and normals for specific situations, and likewise, I find it too risky and unpredictable for the general vehicle-to-vehicle case.

Can you elaborate a bit more the “triangles not being perpendicular to the ground”? Our vehicles can go up and down slopes, so their front end won’t ever be perfectly aligned with the ground nor with other vehicles when colliding.

The goal is to have the same contact normals generated at both low and high impact speed, can you give more details on how to make CCD more precise? I’m willing to try and maybe balance the improvements versus the performance hit.

Best regards,

Nicolas

9

Much appreciated Nicolas,

Understood about the 400kmph repro, that makes sense.

I don’t think a box would be a sensible answer here either - I believe Raphael was just suggesting a different shape - not necessarily that one :smiley:

You should be able to get a decent fitting shape without making a geometry higher than the car - that sounds like it is masking the issue but making the depenetration vector large for any upwards solve.

Triangles not being perpendicular to the ground was probably a slight slip - more precisely you’d want this to be perpendicular (or close to) the Center of Mass - that was the movement creates a force as opposed a torque. Essentially the key here is not to have anything on the front of the car which is ‘ramp like’ in shape - you want it ‘wall’ shaped.

I’ll refresh my memory on the CCD side and respond a bit later on :slight_smile:

Geoff

10

Actually you may not need to tune at all - there is a CVar in the physics which may work for your case: CVars::CCDAllowedDepthBoundsScale - if you set this to a lower number you should get what you need. 0

Geoff

11

Hey,

Thank you for the leads !

Yes for now making the geometry higher than the car is masking the issue, we’ll make sure when updating the shape in front of car, nothing looks like a “ramp”

I tried modifying CVars::CCDAllowedDepthBoundsScale, and setting it to ‘0’ in the repro project (with CCD on) does produce the result I’m aiming for, meaning the contact normal are parallel to the ground at both low and high speed, and vehicles don’t climb on top of each other.

From what I understand it enables this bit of code, which allows impulses to be added during the CCD phase, and that’s whats fixing the issue :

[Image Removed]Can you explain a bit what it does, are there side effects I should be aware of?

I’m asking because I override OnContactModification_Internal to modify certain constraints (invMassScale for example), now that impulses are also applied during CCD, should I also override OnCCDModification_Internal and apply the same modifications to the given constraint?

Cheers,

Nicolas

12

Glad to hear it improved!

I’d probably set it a bit above 0. It is set at 0.2 as default. Essentially what that is saying is that the normal collision detection won’t solve it because it isn’t in penetration any more. This means it bypasses the solver - which is an issue with multibody collisions. This will cause side effects. I _think_ it should be okay not to override the modification so long as it is in some sort of penetration since it is more about impulses and positions than when it hit - but keep an eye out for any unusual behaviour.

Hope this all helps!

Geoff

13

Ok, it was more of an odd case, I still have a lot of penetration upon collision and normals going up and down.

I’ll set it above 0 and check what happens in the real project.

Do you have any more clues, or things I could check ?

Cheers,

Nicolas

14

Hi Nicolas - have you altered the bumper geometry as suggested?

15

Hey,

Yes I tried putting boxes on the repro project instead of the convex mesh, and the collision result is quite random.

Sometimes only one of the vehicle is propelled away, sometimes both, and contact normals can still point up or down

Here’s an example in the CVD :

[Image Removed]Please find the corresponding trace file attached.

Nicolas

16

Hi Nicolas - that 2nd picture is the important one - it is showing far too much penetration for a vehicle with CCD turned on, and the penetration value made small (lets say to 2cm). I’ve taken a look at the traces, and those collisions aren’t CCD enabled which is where this is coming from.

Best

Geoff

17

Hey Geoff,

Taking a look at the trace again, you’re right for the 2nd picture CCD is turned off for contacts with vertical normals and turned on for contacts with horizontal normals. CCSweep also differs from one contact to another, I don’ know if it has an impact.

Both vehicle particles have CDD enabled though, why do some contacts between them have CCD turned off?

I’m not sure I have control over this, how can I make sure every collision has CCD turned on?

Cheers,

Nicolas

18

Hi Nicolas,

Unless you are turning some of the CCD off - it shouldn’t be is the quick answer. CCD is auto controlled - you just turn it on and off, and tune it when needed. What is also weird in that case if the horizontal shouldn’t be allowing that much penetration to happen in the first place. This seems to be where this underlying issue is coming from - even with simple shapes, that much penetration means it will move it vertically to depenetrate, not horizontally.

I’ll take another look at the trace to see if there is anything else sticking out.

Geoff

19

Hi folks,

I’ve managed to take a look into this now, and CCD is getting switched off here:

[Image Removed]Looks setup related, but going to see if I can alter these now to verify.

Geoff

20

The above can be controlled via 2 CVars -

[Image Removed]This can be set to a different algorithm in order to make the bounds smaller

[Image Removed]This is probably the better one to use, and it’d be worth keeping the earlier CVar enabled as well.

Essentially CCD in it’s normal guise is used to prevent tunnelling (which happens when penetration is over halfway in an object) - so a lot of the setup defaults to that thinking. This is different to the use case you have where you need to stop a portion of penetration before the midpoint.

Geoff