Unstable contact on GPU using TGS solver type

[ssmeadkv]

Library and Version

PhysX 5.6.1

Operating System

Windows 11

Steps to Trigger Behavior

1. Create 2 box colliders.
2. Have box collider 1 rest on box collider 2. Rotate box collider 2.
3. Use PxSolverType::eTGS on a GPU solve
4. Observe box collider 1 have unstable behavior.

Code Snippet to Reproduce Behavior

Using the useGPU and useTGS parameters in the snippet below, the issue can be reproduced.
useGPU = true + useTGS = true produces unstable contact behavior.
useGPU = true + useTGS = false produces stable contact behavior.
useGPU = false + useTGS = false produces stable contact behavior.
useGPU = false + useTGS = true produces stable contact behavior.

Example stable:

stable.mp4

Example unstable:

unstable.mp4

#include "PxPhysicsAPI.h"
#include "../snippetutils/SnippetUtils.h"
#include "../snippetcommon/SnippetPrint.h"
#include "../snippetcommon/SnippetPVD.h"

using namespace physx;

static PxDefaultAllocator		gAllocator;
static PxDefaultErrorCallback	gErrorCallback;
static PxFoundation*			gFoundation = NULL;
static PxPhysics*				gPhysics	= NULL;
static PxDefaultCpuDispatcher*	gDispatcher = NULL;
static PxScene*					gScene		= NULL;
static PxMaterial*				gMaterial	= NULL;
static PxPvd*					gPvd        = NULL;

PxArray<PxVec3> gContactPositions;
PxArray<PxVec3> gContactImpulses;
PxRigidDynamic* floor1;
bool useGPU = true;
bool useTGS = true;

static PxFilterFlags contactReportFilterShader(	PxFilterObjectAttributes attributes0, PxFilterData filterData0, 
												PxFilterObjectAttributes attributes1, PxFilterData filterData1,
												PxPairFlags& pairFlags, const void* constantBlock, PxU32 constantBlockSize)
{
	PX_UNUSED(attributes0);
	PX_UNUSED(attributes1);
	PX_UNUSED(filterData0);
	PX_UNUSED(filterData1);
	PX_UNUSED(constantBlockSize);
	PX_UNUSED(constantBlock);

	// all initial and persisting reports for everything, with per-point data
	pairFlags = PxPairFlag::eSOLVE_CONTACT | PxPairFlag::eDETECT_DISCRETE_CONTACT
			  |	PxPairFlag::eNOTIFY_TOUCH_FOUND 
			  | PxPairFlag::eNOTIFY_TOUCH_PERSISTS
			  | PxPairFlag::eNOTIFY_CONTACT_POINTS;
	return PxFilterFlag::eDEFAULT;
}


void initPhysics(bool /*interactive*/)
{
	gFoundation = PxCreateFoundation(PX_PHYSICS_VERSION, gAllocator, gErrorCallback);
	gPvd = PxCreatePvd(*gFoundation);
	PxPvdTransport* transport = PxDefaultPvdSocketTransportCreate(PVD_HOST, 5425, 10);
	gPvd->connect(*transport,PxPvdInstrumentationFlag::eALL);
	gPhysics = PxCreatePhysics(PX_PHYSICS_VERSION, *gFoundation, PxTolerancesScale(), true, gPvd);
	PxInitExtensions(*gPhysics,gPvd);
	PxU32 numCores = SnippetUtils::getNbPhysicalCores();
	gDispatcher = PxDefaultCpuDispatcherCreate(numCores == 0 ? 0 : numCores - 1);
	PxSceneDesc sceneDesc(PxTolerancesScale(1.0f, 10.0f));
	sceneDesc.cpuDispatcher = gDispatcher;
	sceneDesc.gravity = PxVec3(0, -9.81f, 0);
	sceneDesc.filterShader	= contactReportFilterShader;
	sceneDesc.bounceThresholdVelocity = 1e-6;
	if (useGPU) 
	{
		const PxCudaContextManagerDesc cudaContextManagerDesc;
		auto mCudaContextManager =
			PxCreateCudaContextManager(*gFoundation, cudaContextManagerDesc);
		sceneDesc.cudaContextManager = mCudaContextManager;
		sceneDesc.flags |= PxSceneFlag::eENABLE_GPU_DYNAMICS;
		sceneDesc.flags |= PxSceneFlag::eENABLE_PCM;
		sceneDesc.flags |= PxSceneFlag::eENABLE_ENHANCED_DETERMINISM;
		sceneDesc.broadPhaseType = PxBroadPhaseType::eGPU;
		sceneDesc.gpuMaxNumPartitions = 8;
	}
	if (useTGS)
	{
		sceneDesc.solverType = PxSolverType::eTGS;
	}
	else
	{
		sceneDesc.solverType = PxSolverType::ePGS;
	}
	
	gScene = gPhysics->createScene(sceneDesc);

	PxPvdSceneClient* pvdClient = gScene->getScenePvdClient();
	if(pvdClient)
	{
		pvdClient->setScenePvdFlag(PxPvdSceneFlag::eTRANSMIT_CONTACTS, true);
	}
	gMaterial = gPhysics->createMaterial(1.0f, 1.0f, 0.2f);
	gMaterial->setRestitutionCombineMode(PxCombineMode::eMAX);
	gMaterial->setFrictionCombineMode(PxCombineMode::eMAX);

	// box collider 1
	PxShape* shape = gPhysics->createShape(PxBoxGeometry(0.05967678129673004 / 2, 0.17804302275180817 / 2, 0.03580000251531601 / 2), *gMaterial);
	PxTransform localTm(PxVec3(-0.4f, 0.17804302275180817 / 2 + 0.0002 + 0.005, 0));
	PxRigidDynamic* body = gPhysics->createRigidDynamic(localTm);
	body->attachShape(*shape);
	body->setSolverIterationCounts(16, 3);
	PxRigidBodyExt::setMassAndUpdateInertia(*body, 0.0189f);
	gScene->addActor(*body);
	shape->release();

	// box collider 2
	PxShape* floorShape = gPhysics->createShape(PxBoxGeometry(0.5, 0.005, 0.1), *gMaterial);
	floor1 = gPhysics->createRigidDynamic(PxTransform(PxVec3(0.0f, 0.0f, 0.0f)));
	floor1->attachShape(*floorShape);
	floor1->setRigidBodyFlag(PxRigidBodyFlag::eKINEMATIC, true);
	floor1->setSolverIterationCounts(16, 3);
	PxRigidBodyExt::setMassAndUpdateInertia(*floor1, 15.0f);
	gScene->addActor(*floor1);
	floorShape->release();
}

PxReal simTime = 0;
void stepPhysics(bool /*interactive*/)
{
	const PxReal dt = 1e-3f;
	gContactPositions.clear();
	gContactImpulses.clear();

	const PxReal speed = 2.0f * PxPi / 180.0;

	PxTransform pose = floor1->getGlobalPose();
	floor1->setKinematicTarget(PxTransform(pose.p, PxQuat(PxSin(simTime * speed), PxVec3(0, 0, -1))));

	gScene->simulate(dt);
	gScene->fetchResults(true);
	simTime += dt;
}
	
void cleanupPhysics(bool /*interactive*/)
{
	gContactPositions.reset();
	gContactImpulses.reset();
    
	PX_RELEASE(gScene);
	PX_RELEASE(gDispatcher);
	PxCloseExtensions();
	PX_RELEASE(gPhysics);
	if(gPvd)
	{
		PxPvdTransport* transport = gPvd->getTransport();
		PX_RELEASE(gPvd);
		PX_RELEASE(transport);
	}
	PX_RELEASE(gFoundation);
	
	printf("SnippetContactReport done.\n");
}

int snippetMain(int, const char*const*)
{
	initPhysics(false);
	for (PxU32 i = 0; i < 10000; i++)
		stepPhysics(false);
	cleanupPhysics(false);

	return 0;
}

Expected Behavior

Stable contact

Actual Behavior

Unstable contact

[amoravanszky]

The CPU and GPU implementations of TGS (and all other relevant algorithms) are completely different pieces of code, so in general there is no expectation that they must behave identically. It is a known issue that behavior can be significantly different. In the above case you tip the cube into an unstable pose, where during a number of frames both tipping and not tipping is plausible. It is hard to see from the video but unless there is a situation where you completely lose contacts and get significant interpenetration, one could argue that this behavior is within tolerance of acceptable. I am wondering what the higher level issue is that this behavioral divergence causes you?

[ssmeadkv]

Thanks for your response. To clarify, I am not expecting the cubes to necessarily tip over at the exact angle because of the differences between CPU, GPU, etc. I just was expecting to not see the jittering.

Here is another example where the plate is just moving upwards and there is a loss of contact.

unstable3.mp4

Again, changing the solver to PGS (still GPU) produces what I would expect.

stable3.mp4

Our current use-case is modeling a stack of products on a pallet and trying to assess the stability of the during accelerations, decelerations, turns, etc. With many boxes stacked up these small jitters compound and the pallet jitters itself apart even when no movement is applied. We also eventually would want to use custom meshes for contact using SDF because not all boxes are perfectly orthogonal. My understanding is that SDF is only available on the GPU (please correct me if I am wrong.)

[amoravanszky]

Ok this is a better example. I am curious, does this still happen when you make the plate significantly thicker? It would be useful in diagnosing this to know if the artifact is a consequence of either relative (aspect ratio) or absolute thickness of the plate possibly in relation to time step size. Right now my best guess is that the GPU implementation is likely less robust in its floating point math than the CPU implementation which could potentially explain this.

[ssmeadkv]

Apologies for the delayed response, was out for the holidays. I tested with a much thicker plate and the issue still happens, though the block doesn't fully fall through it anymore.

[amoravanszky]

Thanks. What happens if you make both the little cube and the big cube 10x bigger?

Also, it would be helpful if you could again post side by side videos of CPU vs GPU behavior.

[ssmeadkv]

Below are videos with the boxes 10x larger (0.1 and 1.0 original size, 1.0 and 10.0 current size) The velocity was also increased 10x to keep everything consistent.

GPU, TGS:

gpu_tgs_10x_bigger.mp4

CPU, TGS:

cpu_tgs_10x_bigger.mp4

[vreutskyy]

@amoravanszky FYI, we have internal ticket for this issue for someone to have a closer look at it.

[msauter-nvidia]

Hi ssmeadkv,

Thank you for the nice second repro. We will work on a fix.
If you do not really need your materials to have restitution, then you could set it to 0 as a temporary workaround. The problem seems to disappear with restitution equal 0.

[msauter-nvidia]

note: a fix has been submitted for release 5.8.0 / 110.x (targeted timeframe March/April, no guarantee)