Physics - objects slowly sinking into one another

Development World Creation
,
1

I’m currently trying to see how objects react when they’re being centrifuged. I have a 500 cm radius wheel spinning at an angular velocity such that centripetal acceleration at its radius is about 1g.
The attached screenshot illustrates the setup: the checkered solid is the ground, the camera is looking down from above. The colored lines are debug only, and the black lines represent the normals of all contacts for the boxes.

In this scenario, there are 2 boxes and 2 mannequins, one of each is affected by gravity, and thus lying on the ground, while the other is not, and gets centrifuged by the wheel. So far so good.

The issue appears when an object gets close to a resting position in the rotating frame of reference (the camera is attached to the wheel and turns with it, so the object appears to be almost static, as if resting on the ground): the object starts slowly sinking into the wheel, and either continues to do so until it passes through, or is ejected at high speed back inside.

The following video shows the issue: https://dl.dropbox.com/s/6bjm468h83vvvgf/GravAr_collision_01.mp4?dl=0
In this scenario, gravity is not applied to objects. There are also transparent solids to prevent the objects from falling off the sides of the wheel.
As you can see, the general behavior of the objects is correct, but they start sinking into the wheel (the mannequins generally jerk a little, while the cubes can sink all the way through at times).
Also notice how the contact normals (black lines) change and rotate for a few frames, then suddenly come back.

I have tried tweaking several options to fix this:

  • physics sub-stepping, with high and low max delta time and substep numbers
  • CCD, PCM, async scene (not sure what that last one is exactly, though)
  • solver iterations for position and velocity (defaults are 8 and 1 respectively, I went as high as 32 and 16 with no noticeable effect)
  • probably a few other things I can’t remember

From all this, there is an obvious result: either I’m completely missing something, or there is an issue with the way physics are computed.
The problem is not the wheel or the objects themselves, as a non-rotating wheel will allow objects to rest on it with only gravity acting on them, and they will then go to sleep; even if I manually disable sleeping, their jerking is minimal.
When the wheel is spinning and gravity is disabled, however, they will invariably sink - the issue quite clearly comes from the velocity of the objects (about 640 cm/s in this situation).

I guess a workaround would be to implement a “dynamic sleeping” system, where the objects would be attached to the wheel (or other objects, when stacking) if the relative position and velocity are small enough, but I’m pretty sure having a ball inside a spinning wheel should be stable at only 1g (the sinking behavior is also there at lower angular velocities, and is amplified at higher velocities).

If anyone has an idea, or if this can be confirmed to be an issue with Physx, I would appreciate help! Thanks and sorry for the long text.

2

Bump and a tiny update, back on the subject of normals (represented by the black lines in the video) and their strange movement: it appears the “ejection” always happens as the normal is “reset” (when it jumps to a certain direction after having moved for a bit).

Also, though this seems to vary, the sink rate is roughly 2 cm/s for a 1g acceleration.

Is anyone able to recreate this kind of behavior? Could it depend on the way I rotate the wheel?
I call AddActorLocalRotation every tick for the wheel, and I also tried changing that to instead force the angular velocity through SetPhysicsAngularVelocity (called every tick as well), giving the wheel a very high mass (10000) and locking all DoF except its rotation axis; the results are unfortunately the same.

3

I experience this all the time with organs and arms, since i break skeletal meshes all the time, or drop meshes into the world, with some vel. into physical bodies like a spinning wheel for example like yours, some of them will randomly sink into them and will either shoot forward out like your video or they shoot backwards out behind it. it doesn’t matter if its ragdoll or static geo. everything does it from time to time.

I have tried messing with the physics pos vel solver iterators but i don’t think it changes anything tbh.

4

Hm… I have low UE4 experience so don’t expect much help.
However, I’ve been using Blender Game Engine for a while(uses Bullet). It had no such a problem at all, except softbodies. There it’s a problem of softbodies that they sink into other meshes(propably spring forces beat normalforce). And in all of those problems of physics in games - always springs are guilty… I guess that the object calculates sinkage and applies spring-releated force, but it’s applied in order to prevent infinite bouncing. However, this results in the fact that the spring force applied it stoo low. Maybe I’m wrong… I just think it’s something to do with the normalforce(static collision force which cancels movement).

5

I have similar bug with ski on aerosled and some configuration of tanks in my project. Usually it boils down to two things - scale and mass/force magnitude.
Scaled physics objects are no go, keep scale 1,1,1 always. There are some algorithms that work plain wrong when you have anything but 1,1,1 scale.
With mass/force difference it’s a bit more complicated. The heavier the object and the smaller the force, the less issues like this you will have. Unfortunately there are cases when it can’t be avoided - 60 ton tank standing on 10 100kg roadwheels or 2000 kg Aerosled standing on 4 100kg ski. In these cases I have to cheat - instead of using “equal” spring to push tank chassis up and wheels down with the same but opposing force, I scale or down for wheels. This brakes consistency of simulation as if I place one tank on another it won’t be transferring all mass of the top tank, but this prevents sinking which is way more apparent and common issue.

6

Thanks for your answers. From these, I believe SaxonRah’s case is closest to mine, as it also involves spinning “centrifuges”, but I see how, in BoredEngineer’s case, the difference in mass could be an issue (I’m pretty sure PhysX constraints (or any engine for that matter) are applied at a single point, which is the very definition of bad news IRL).

In my case, the wheel is animated, and doesn’t have physics enabled (I tried enabling physics with a very high mass, and keeping a constant angular velocity, but there was no noticeable difference), so I don’t think it plays a role in this. Also, I do have scaling, but only for the Mesh Component of the wheel, not the actor itself.

I’m still open to ideas/suggestions, but in the meanwhile, I’m trying to implement a “dynamic sleep” system: when an object’s position in the wheel’s frame of reference is stable enough, and the object is in contact with the wheel, a physics constraint actor is spawned and keeps the object still relative to the wheel. I then destroy this constraint upon a new hit.
The destroy part doesn’t seem to work though, so I’m not sure this will work as intended yet…

7

A little update: while exploring ways to implement my dynamic sleep system, I continued tweaking various physics parameters. With PCM enabled, the strange movement of the contact normals disappears, and they stay relatively still.
Also, the ejection velocity can be reduced by increasing the velocity iterations of the objects: using 8 iterations almost completely eliminates ejection, and objects are instead moved, sort of in an “inelastic collision response” way.

On the dynamic sleep front, I’m able to check when an object is relatively still inside the wheel’s frame of reference, to activate dynamic sleep.
The most stable way to have the object follow the wheel is to use an AttachToActor node with WeldSimulatedBodies checked. The issue I now have, however, is that when I detach the object to wake it up (and reenable SetSimulatePhysics), it falls right through the wheel, without even “sinking” as it usually does. It seems to completely ignore the collision, and will actually collide when it exits through the outer side of the ring.

As I said before, I’m still open to suggestions, especially since I did manage to stabilize things somewhat, while sinking still happens.

EDIT: Forgot to mention something: while the wheel’s collisions are stable when it’s not rotating, and objects fall inside of it under gravity, it turns out that stacking a cube on top of another one inside the wheel while it’s rotating will make the contact between the cubes perfectly stable (there is probably some jitter, the same kind you’d have if you turned sleeping off).
This means that while the first cube will sink into the wheel, the one of top will be stable relative to the first cube.
Also, if I attach the first cube to the wheel (and check WeldSimulatedBodies), the cube on top will NOT sink.

So, as much as this behavior is a mystery to me, it is a welcome surprise. Maybe I should cover the wheel’s surface with cubes…

8

How does collision look on your wheel?
What is PCM btw?

There are other setting you could try to tweak like updating collision volume. Higher amount of polygons on collision sometimes helps too, it will be optimized when imported but you can prevent it by using multiple collision elements.

9

PCM stands for Permanent Contact Manifold, it’s an option in the Project Settings, under Physics. While I don’t know the specifics, the doc states that it makes the simulation more accurate overall, but can cause stacking stability issues. The main difference, from what I see, is that the contact normals don’t go crazy when it’s on.

As for the wheel, it is a 32-side hollow cylinder, and I have one trapezoid-shaped convex hull per side (each of these is named UCX_Wheel_xx in Blender). When the wheel is static, objects interact with it properly, but it’s only when it is spinning that the sinking happens.
As I mentioned in my previous post, a stack of 2 boxes is stable, in that the contact between the boxes doesn’t lead to the top box sinking into the bottom one. As a test, I decided to replace the collision meshes of the wheel with 32 static mesh components, with a box collision shape. This completely eliminates the sinking behavior, which will probably remove the need for me to implement a workaround. I guess the only issue is that I have to place static mesh components instead of using convex hulls from Blender.

There is still some jitter in the simulation, but I think it is now pretty reasonable, and at least the overall behavior is correct. See the attached screenshot for a test scenario with a few spheres and boxes lying around, after waiting a minute or so (yes, the yellow lines are the contact normals).

I’ll call this one solved for now, thanks again for your help and suggestions!

10

Sorry for the necro, but I came across a similar issue and found this thread very helpful! Thanks to all involved :slight_smile:

Disabling PCM does indeed improve things, but I have also found another physics bool :

[/Script/Engine.PhysicsSettings]
bEnableStabilization=True

^ this one REALLY improves the stability of objects , particularly when they are stacked on top of one another and you don’t want them to interpenetrate. The only downside I’ve noticed so far is that it makes things appear somewhat “floaty”, but there may be another var you can tweak somewhere to adjust the stabilization thresholds.