Why Is Collision/Physics so Messed Up?

I am trying to get the physics in this engine to a usable state, but man it just doesn’t want to to the bare basics at all correctly. I am using UE 5.2.1 since 5.3.0 is somehow even worse… and I am contemplating downgrading back to UE 4.26/27 if this keeps up.

The issue(s):

  1. Assets that fall on top of another asset with a rotating collision surface does not trigger any further physics:

Notice how the asset on top is perfectly flat when instead it should be sliding off. There doesn’t appear to be any errors in the collision boxes themselves and the engine correctly sees the surface collision as rotating. Yet the unexpected happens and the slime stays exactly there while the surface pivots.

  1. Physics is completely random. I do not want this, when I have an object dropped from X height on an angled surface, I expect the same results every single time to happen. It would be insanity to expect otherwise, yet for some reason this is the case with Unreal…

What can be done to fix these errors? Or is this engine just really not up for the task of consistent game dev?

5.3.1. What else are you doing? Any details? Tested a capsule, too. Seems more stable than any physX implementation in 4.x


If you’re having issue with very slowly moving physics sims falling asleep too early, try:

image

p.Chaos.Solver.SleepEnabled 0

1 Like

Sorry for the low res, ShadowPlay throws a fit trying to record play in UE. This was just a simple drop test to make sure the slimes won’t get stuck on top of radar. The slimes collision box is:

The expected should be the slime bounces off the dish at the angle the dish is at when it hits. It does not do that all the time, 1/3rd of the time ends up like in the video.

1 Like

How’s the hierarchy of the slime actor? Can we see it? Is anything scaled?

1 Like

Hierarchy as in the blueprint viewport? It is just the slime mesh as the root, most of the times I don’t even use a blueprint class and just test directly with the static mesh. or do you mean something else?

The slime is scaled to 0.02 since it is massive in the Blender file i made them in, I was planning to resize them a bit later when I convert them into skeletal meshes. the Radar is scaled slightly too, by about ~0.2 IIRC.

1 Like

I’d start with this. Almost 100% this is the issue. You could try xFormTransform in the engine:

But scale will trip up physics often. Especially non-uniform scale on sphere and capsule colliders. I’d ensure that scale is within the range of an order of magnitude of the final scale you want to see. Scaling up is usually less problematic.


There’s some really good frames in that video, definitely undesired behaviour:

image

Try running it with:

ShowFlag.Collision 1

To see where the collision is. It may look OK but still behave poorly. Curious what shows up in your case.


Another thing to avoid is to rotate components whose collision shapes were welded. Not applicable here atm. But may become applicable with skeletal meshes.

1 Like

Scaled size to the correct scale before importing. Scale of asset in game is 1.0. Tested using same collision boxes as before, worse result as the rectangular boxes are no longer being detected.

Changed collision boxes to an auto convex collision and increased physics substepping to max (16). Asset doesn’t get stuck but ends up clipping thru the dish when it’s about to.

I just don’t get it, how can this engine be this bad at physics? It is starting to seem easier to just build a physics engine from scratch over using this… IDK how any AAA could consider this engine if you can’t expect results to be the same across runs or even expect normal collision behavior without it clipping/going thru other assets…

EDIT: Here is with showFlag.Collision 1

Testing dropping a basic cube with CCD enabled also gives similar bad results. Cube will clip thru the dish or fly off at random unrealistic angles.

Alright, found a solution that works. The issue seems to stem for the dishes simple collision, which is quite odd considering it was a pretty basic cylindrical collision. But by changing the collision to using complex as simple, the physics interaction works correctly.

1 Like

Sounds like a bug with the flat edges of the cylinder collider, then!
You should probably file that. (Cylinders are a pain, I’m not surprised that has bugs.)

2 Likes

Definitely a bug partly with cylinder collision. I think this may be part of a larger limitation on the current physics engine, and frankly it is a finicky mess.

For instance, if I simulate physics on just the root part of the radar, the base, then the collision breaks and I get either assets falling directly thru the dish or the assets land flat and the collision isn’t detected as pivoting. But if I enable physics on just the dish, then it still correctly does the physics. Yet if I enable physics on both the base and the dish, collision works but now the dish does not stay attached to the base assembly. It’s very odd behavior.

1 Like

Further trying to troubleshoot this to get it to work 100% the way I wanted, the error seems local to imported assets:

I built I test asset out of basic shapes in the engine and collision works fine running the same pivoting blueprint and same asset blueprint hierarchy. Yet my asset does not work when I enable physics on the base, but it works on the test asset.

What could be causing the collision to constantly break? I can provide the files if need be.

If there are two objects, that both have simulate physics turned on, then they will have to be attached with some kind of joint to stay stuck together.

1 Like