Class StraightStraightTest

Two polygons with acute angle corners both resting on the ground, and their corners are colliding (there are 4 other Polygons as well).

This test resulted in bringing back CornerCornerCollision, and adding a tolerance setting to UtilEngine.linesIntersect. This was found from a probablyPointInside error on Oct 20, 2016 in UtilCollision.testCollisionVertex.

The error is caused by having two Polygons (numbers 3 and 6) with acute angle corners, they are both resting on the ground, and their corners are colliding. We can't form vertex-edge contacts because of the geometry of this particular case. Both corners are "beyond the edge". This is calculated by looking at the normal to the edge (like Edge.distanceToPoint returns infinity when the point is beyond the endpoint).

My first approach to solving this was to add collision testing between two StraightEdges, by creating the static class StraightStraight. This did result in surviving the situation, but there is never a contact force generated, and there are endless collisions happening at that corner. To fix that I brought back CornerCornerCollision, which gives a contact force there and stops the collisions.

After looking into why the probablyPointInside error occurs (when we don't have CornerCornerCollision or StraightStraight edge testing) it seems to be a case of a small floating point calculation error in finding the intersection of lines. Adding a small tolerance in UtilEngine.linesIntersect results in getting collisions instead of the probablyPointInside error (even when we don't have CornerCornerCollision or StraightStraight edge testing). This shows that the StraightStraight class is not needed, that we can assume that vertex-edge collisions are sufficient for finding collisions between StraightEdges, as long as this tolerance is large enough in UtilEngine.linesIntersect.

Two blocks start in contact and in motion, with mutual gravitation.

A square and a rectangle bounce collide together under mutual gravitation, eventually settling into rotating/sliding contact.

Two square blocks collide exactly at their corners.

Two diamond shaped blocks collide under mutual gravity and wind up in rocking contact.

A single rectangle block is very close to floor and moving quickly. This tests an unusual condition that should probably never happen, except from initial conditions like this test. See RigidBodyCollision.closeEnough which has a special allowTiny parameter which handles cases where a collision has very small distance, but we cannot backup to a time when distance was around targetGap.

A hexagon resting on the floor, with a square block balanced on one corner on top of the hexagon. The hexagon is rotated, so that the top edge is one of the side edges that has outsideIsDown. This is a rare test that exercises some code related to down-is-out for edges that are not horizontal or vertical in body position.

A 16-sided polygon rolls and slides on a rectangular block.

Note that this loses energy due to the policy of applying impact force at contact points that are colliding (normal velocity is small and negative) to get the contact point to have zero normal velocity. As the polygon rolls, each vertex of the polygon winds up in this situation as the vertex rolls to become the new contact point.

Two square blocks collide at their corners, so that the vertex enters 'sideways' into very close contact near the corner:

.            ------------- distance tolerance
       .
             =.=========== edge
             |      .
             |
             |

This is a strange case because the impulse happens well outside of the object.

Prediction: binary search turns on, and the RigidBodyCollision.closeEnough 'allowTiny' case happens, so the collision backs up to a very small contact distance.

This is a very simple test of a block falling to the floor; success is simply that the collision handling is able to cope with this unusual case.

A single rectangle block falls to hit the floor. This revealed problems in the collision handling discovered on May 17 2012 in the Chain simulation, although it had nothing to do with the Chain. The block Vertexes were reaching exactly the bottom wall (distance = 0.0 exactly at the moment of collision) and this resulted in the algorithm becoming stuck. Note that all the factors are critical to make this test happen: setup, gravity, time step, etc.

A single rectangle block in contact on the floor, but with a small distance gap and large velocity (-0.3 is large for a contact).

Two rounded corner square blocks collide exactly at their corners.

Tests scenario with six blocks on ground with one leaning; ensures that no further collisions happen, and energy is constant.

Situation that led to development of the 'near collision' feature on Aug 3 2011, where there is an imminent collision while handling another collision, which resulted in the 'stuck count' going to 3. Just increasing the stuck count limit would fix the situation, but I instead developed the idea that an imminent collision is similar to a contact for purposes of handling multiple collisions.

Situation from Aug 20 2011 in ContactTest, with six blocks resting on the floor. It caused a failure in the matrix solver, which has been repaired.

Note that the problem only occurs when we do not divide up the contacts into independent subsets of contacts. So to see this error we must set the flag ContactSim.SUBSET_COLLISIONS to false. Also, this error only occurs when the walls are added last, after the moveable blocks.

See also myphysicslab.lab.engine2D.test.UtilEngine_test.testRedundantMatrix9() which has a copy of the matrix that results from this test.

Crash Oct 9 2012: two blocks wind up overlapping with no collision, but taking out the 'throw exception' in Polygon.testCollisionVertex fixes the problem: we are able to find a collision later on and everything works out OK.

[java] java.lang.IllegalStateException: corner is inside 2: [-0.48819, -1.5, 0]
this=com.myphysicslab.lab.engine2D.Polygon@52c00025[ name=1, dragable=true,
zeroEnergyLevel=-5.5, expireTime=?, 2 attributes(
color=java.awt.Color[r=0,g=0,b=255],filled=true,), x=-2.96337, y=-4.495, angle=-0,
vx=-0.25466, vy=-0, vw=-0, cmx=0, cmy=0, width=1, height=3, mass=1,
momentAboutCM=0.83333]
other=com.myphysicslab.lab.engine2D.Polygon@4e2016b0[ name=0, dragable=true,
zeroEnergyLevel=-5.5, expireTime=?, 1 attributes(
color=java.awt.Color[r=230,g=230,b=230],), x=-3.95156, y=-4.495, angle=-0, vx=0.559,
vy=-0, vw=0, cmx=0, cmy=0, width=1, height=3, mass=1, momentAboutCM=0.83333]
Copy

Update May 27 2013: Made the tolerance tighter for finding line intersection, and put back in the 'throw exception' in Polygon.testCollisionVertex. Turns out that this test is no longer triggering that exception even with tolerance of 1E-10 in UtilEngine.linesIntersect. So, this test is of questionable usefulness.

Six blocks start in a configuration on the ground, with one block being nearly vertical and leaning and rocking on neighbors. History: previously resulted in a stuck state with many messages about "probably didn't find a dependent row, zmax=1.0" where the zmax was large (around 1 or so). This led to changes in how contact forces are solved for, specifically the UtilCollision.subsetCollisions1() method was invented so that only related groups of contacts were solved for together. This helps to avoid throwing away important contacts in the process of making the A matrix be non-singular.

Six blocks, causes a matrix solve exception.

Six blocks, causes a matrix solve exception, where the null space tolerance needs to be increased.

Package

Performance test that runs the six_blocks_settle test.

Tests scenario with six blocks falling onto ground; ensures that no further collisions happen after blocks settle on the ground.

Using 'velocity and distance extra accel calc' policy, tests scenario with six blocks falling onto ground; ensures that no further collisions happen after blocks settle on the ground; and checks that the contact distance is close to target gap at all contacts.

Same as six_blocks_settle_setup, but using 'velocity and distance' extra accel calc policy.

Six blocks fall onto the ground and settle down (mostly) after 6 seconds. One of the blocks has less mass than the others.