Physics objects are falling through landscape

Physics objects are falling through a landscape, if they are small enough.

Cubes with a size of 50x50 never fall through the landscape, cubes with a size of 30x30 rarely do and cubes with a size of 10x10 almost always do.

Repro Steps:

  1. Create a landscape.
  2. Create an actor “Cube”, add a mesh and enable simulate physics
  3. Create another actor “Cube Spawner” which spawns “Cube” in the tick
  4. Place the “Cube Spawner” in the level
  5. Hit play and take a look at below the landscape

This is not only happening on a landscape but also on static meshes with a Z thickness of near 0. The “collision thickness” setting of the landacape is not changing the behavior.

Hey John,

I’ve not been able to reproduce this using the 4.8 preview 3.

I’ve setup three cubes with the size dimensions you mention.
Here is a video of my results: Dropbox - Error

With my cubes they are using a collision box for the setup. Are you using a collision box or have you enabled collision complexity to use “Complex as simple collision” (Per Poly)?


The mesh I use is the cube from the Engine Content at /Engine/BasicShapes. It’s using a collision box, I have not changed any of the collision settings.

The mesh is 100x100x100 size, so for 10x10 I spawn it with 0.1 scale. It looks like this:

Hey John,

Digging into this a little bit more this is actually not a bug, but just a way of handling collision in a performance happy method. There is a setting in for the static meshes collision that can be enabled that is CCD (Continuos Collision Detection).

When this is enabled it will increase CPU processing, but it will increase accuracy of collision for your spawned meshes. When I tested this in 4.7.6 and 4.8 p3 with this setting enabled there were none of the spawned cubes penetrating any longer.

If you hover over the CCD option in the details panel and hold Ctrl + Alt you will see an expanded explanation.

I hope this helps.


Hi Tim, thanks for looking into this!

I know that it works with CCD, but it’s just not an option for me because it’s too expensive, I can’t waste so much CPU time.

I think it is a bug, because if I have a static mesh with a thickness of lets say 50, no physics actors are falling through the landscape. But a landscape with a collision thickness of 50 acts as if the collision thickness would be 0, not 50.

If the actors are not falling through a static mesh with a Z thickness of 50 they should also not fall through a landscape with a collision thickness with 50, right?

Hi John,

I’ve submitted a ticket for Landscape Collision thickness to be investigated by one of the developers. Ticket UE-16195.

I’ll update you once there is any change with the ticket.

Thank you!


Seems like there is a fix!
Will this get added to 4.8?

Hi John,

Unfortunately it missed the cutoff for 4.8, but you can easily solve the problem by first changing the CollisionThickness property, then changing CollisionMipLevel to something other than 0, and then change CollisionMipLevel back to 0. That will regenerate the collision data (twice) with the new CollisionThickness.

  • Jack

Hi Jack, thanks for letting me know!

I have tried to change the CollisionMipLevel to 1 and back to 0, but it does not seem to change anything. The physics objects (most of them) keep falling through the landscape the exact same way you see on the gif. I have set the landscape collision thickness to 500, so this should be thick enough I guess.

any idea why it does not work?

Why was this marked as resolved? If the changing of CollisionMipLevel does not update the physx collision thickness, the fix mentioned above will also not fix this bug.

The CL has been fixed internally with 4.9. The fix that Jack suggested is a workaround and not the submitted fix.

I know, but I looked at the commit I linked and it only adds another condition to the if, before it was

else if (GIsEditor && (PropertyName == FName(TEXT("CollisionMipLevel"))))

and the fix changed it to

else if (GIsEditor && (PropertyName == FName(TEXT("CollisionMipLevel")) || PropertyName == FName(TEXT("CollisionThickness"))))

And as my test showed changing the CollisionMipLevel also does not fix it, so even with the fix it will not be fixed I think. “RecreateCollisionComponents” is called after I change the MipLevel but objects still fall through the landscape, so just calling “RecreateCollisionComponents” does not seem to help.
Or is there another commit which is added to 4.9 to fix this?

The ticket for this has been re-opened and is being investigated further. I’ll post an update once a resolution has been found.

Thank you!

Any update? I will try to see whether it’s fixed in 4.9 later, there is so much to test in the preview, if you could just say it has been fixed (with another commit) in 4.9 that would be great :slight_smile:

I’ve confirmed that Collision Thickness gets correctly propagated to physx heightfield objects when it’s changed. But it seems like it does not have any effect. Boxes still falling through heightfield. So it seems like bug in PhysX library. I would recommend to enable CCD while we talking with nVidia about this issue.

Hi John,

I’ve sent a PhysX visual debugger trace of your scene to Nvidia for their opinion as to whether the heightfield thickness support should be expected to cope with this situation and if they have anything we should try changing. I can see in the PhysX debugger that we are correctly setting the thickness when we send the data to PhysX.

We only have a few primitive types to choose from when creating physics objects inside PhysX. Static meshes are typically able to use convex collision type which has much better behavior than heightfield (which we use for landscape) or triangle mesh primitives because they are much easier for the physics engine to handle.


Hi John,

I got a reply from Nvidia. The problem is we have enabled Unified Heightfields in PhysX which improve general collision behavior (especially interaction with neighboring triangle meshes) but they do not support the thickness parameter so as you mention, it’s being ignored.

It’s a single line change in the engine, PhysLevel.cpp replacing PxRegisterUnifiedHeightFields with PxRegisterHeightFields and thickness works as expected

I will add a flag to make the choice of which PhysX heightfield system to use an ini file option for version 4.9.


That’s awesome, thanks a lot! :slight_smile:

Hi John,

For 4.9 I added a new p.bUseUnifiedHeightfield console variable to enable disabling of unified heightfields.

Setting p.bUseUnifiedHeightfield=0 in your ConsoleVariables.ini will allow the thickness parameter to work.

The fix is here if you want to apply it sooner:

  • Jack