Apparent tunneling in fast particles with SDF collision

[greycheeked]

It is about particle collision. Here I encountered a problem that I first attributed to tunneling:

2023-09-23.19-32-12.mp4

If we set velocity to 0 once the collision has been detected, thus freezing the state, we see that for many particles the collision is detected, but only when they are on the far side of the obstacle:

2023-09-23.19-34-09.mp4

Since the particle collision takes place in a Signed Distance Field, we can assume that the collision normal in the back half of an obstacle points in the same direction as the velocity vector. I colored all particles red where this is the case, and the result sorts the two groups quite well:

2023-09-23.19-44-53.mp4

So the problem is not collision detection but collision response. Here is the relevant section of the particle shader:

	if (COLLIDED) {
		if (length(VELOCITY) > 3.0) {
			TRANSFORM[3].xyz += COLLISION_NORMAL * COLLISION_DEPTH;
			VELOCITY -= COLLISION_NORMAL * dot(COLLISION_NORMAL, VELOCITY) * (1.0 + collision_bounce);
			VELOCITY = mix(VELOCITY,vec3(0.0),clamp(collision_friction, 0.0, 1.0));
		} else {
			VELOCITY = vec3(0.0);
		}
	}

It uses COLLISION_NORMAL, which points in the wrong direction for one group. Another parameter that plays a role is the COLLISION_DEPTH.

Each obstacle in this scene has a width of 32 pixels. The Signed Distance Field extends 16 pixels in from both sides. Let's say the particle passes through 30 pixels, almost the entire obstacle, before the collision is detected. It is in the back half, and the Signed Distance Field indicates that it has entered the obstacle 2 pixels far, when in fact it has already entered 30 pixels far.

My skills are not sufficient to take into account the circumstances mentioned here in the formulas. If it were possible to read the SDF in the particle shader (distance and normal), as is possible in the canvas shader, you could probably build a collision handler that could handle it. But maybe someone knows a solution with the currently available means.

However, you can hide the problem by simply taking out the particles that pass through the obstacle by more than half:

	if (COLLIDED) {
		if (length(VELOCITY) > 3.0) {
			
			// collision normal points in the same direction as velocity vector
			if (dot(COLLISION_NORMAL, VELOCITY) > 0.0) {
				ACTIVE = false;
			}

			TRANSFORM[3].xyz += COLLISION_NORMAL * COLLISION_DEPTH;
			VELOCITY -= COLLISION_NORMAL * dot(COLLISION_NORMAL, VELOCITY) * (1.0 + collision_bounce);
			VELOCITY = mix(VELOCITY,vec3(0.0),clamp(collision_friction, 0.0, 1.0));
			
		} else {
			VELOCITY = vec3(0.0);
		}
	}

2023-09-23.20-23-45.mp4

[907Games]

looks like it still is tunneling with your solution (you have particles going through the walls), so it would be a collision detection issue still

[greycheeked]

True, there is also tunneling going on. These are really only a few particles, and the tunneling is due to other causes, so I didn't mention them at all.
However, if you could access the SDF in the particle shader - I already made this suggestion above - it would probably be possible to get the tunneling under control as well.