Strange issue which looks like tunnelling

[Wil McV]

Hello everyone,

I have a really strange issue that I have been struggling with for 2 days now. Basically when I drop objects on top of other objects instead of them colliding and bouncing off each other like you would expect, they seem to collide, then penetrate each other and shake violently for a small period of time. Then they simply stop colliding and just pass through each other.

Here is a gif to show the issue.



I've made sure i'm using the correct collision mask and groups for the boxes.

This only seems to be an issue in release builds.

Has anyone seen this before?

Thanks in advance.

[Wil McV]

Here is another image that shows a far simpler case.



The box will collide once but then it seems to no longer collide. Because its only in release builds, it could be an uninitialised variable or something. Does anyone know anything at all?

Maybe someone could point me in the right direction of where to look in bullets source to see where it would resolve the collision?

I'm using Bullet 2.82

[Basroil]

Perhaps the scales are a bit off or the simulation rate is too slow. Using very small numbers with larger ones can cause float failure (basically adding 0.0001 to 10000.0 will give you 10000.000 rather than 10000.0001), and collision detection/penetration rejection depends on simulation rate.

If it only happens after a tiny bit of penetration, there's also a chance that your error correction parameter is too low, and not correcting penetration by an amount larger than the increase in downward motion due to velocity by gravity

Have you tested faster simulation rates?

[Wil McV]

Hey, thanks for the reply.

The large box is 10mx10mx10m and the smaller one is 1mx1mx1m so I thought that would be within the scale that bullet supports. I have tried shrinking everything and making it bigger as well and the same thing happens.

As for the time step i'm currently calling stepSimulation( time_elapsed ) but I have tried many different things and it doesn't seem to affect the problem.

I think you are right about the float failure though, I have found what might be causing the issue.

The following block of code exists inside btPersistentManifold.cpp around line 280

Code: Select all

projectedPoint = manifoldPoint.m_positionWorldOnA - manifoldPoint.m_normalWorldOnB * manifoldPoint.m_distance1;
	projectedDifference = manifoldPoint.m_positionWorldOnB - projectedPoint;
	distance2d = projectedDifference.dot(projectedDifference);

	if (distance2d  > getContactBreakingThreshold()*getContactBreakingThreshold() )
	{
		removeContactPoint(i);
	}

It seems that the distance2d value is greater than the contact breaking threshold squared so the contact point gets removed and the collision doesnt get a response generated.

In a debug build the distance2d value is around 0.0005 and below range where the threshold squared is calculated to be 0.0012 however in a release build after the box does its first bound the distance2d value goes up to 0.096.

I'm not that familiar with Bullet so i'm currently digging around the source to see what's going on.

The frustrating thing is that this used to work for me fine but I went away on holiday for 3 weeks and then I came back it was broken. I haven't changed any of the settings within Bullet.

[Wil McV]

Just another quick update on this issue if anyone is still reading this. I still haven't solved it yet but it would seem that when ever the shape has a rotation applied to its transform that this causes the issue.

When I say a rotation I don't necessarily mean that I'm rotating the shape manually. This happens when it bounces and rotates

[xexuxjy]

It might be worth doing a quick test with a sphere collision shape for your small crate and seeing if you get a similar issue. Though I can't really think of anything that should fail on a simple test. I presume your large crate is static? what mass value are you using for the small crates?

[Wil McV]

Hey thanks for the replies.

I have semi solved the issue. It would seem that it no longer happens if I disable SSE by commenting out #define BT_USE_SSE_IN_API around line 83 of btScalar.h

I had previously enabled this to try and get a bit more performance but it's not worth it if they is going to happen.

I say the issue is semi solved because I'm not exactly sure why having SSE enabled would cause it.

SSE seems to work fine on iOS

It might be worth doing a quick test with a sphere collision shape for your small crate and seeing if you get a similar issue. Though I can't really think of anything that should fail on a simple test. I presume your large crate is static? what mass value are you using for the small crates?

I tried it with a sphere, it was easiest to get to happen with a box but it would occasionally happen with spheres. I got it to happen with most shapes

[c6burns]

SSE seems to work fine on iOS

SSE instructions aren't implemented on ARM processors

[Wil McV]

SSE seems to work fine on iOS

SSE instructions aren't implemented on ARM processors

Sorry, Meant NEON

[c6burns]

I don't know what code path you've actually changed, but NEON isn't implemented for android. Only for apple.

[Wil McV]

I don't know what code path you've actually changed, but NEON isn't implemented for android. Only for apple.

I'm not using Android devices, i'm using Apple devices.

[c6burns]

I don't know what code path you've actually changed, but NEON isn't implemented for android. Only for apple.

I'm not using Android devices, i'm using Apple devices.

Hooray?