Ok I took that into account and I set so that it runs the demo.
Please check it out when you have some time.
Tel me something, in this function.
void ndShapeConvexPolygon::GenerateConvexCap(const ndShapeInstance* const parentMesh)
by line 328
- Code: Select all
//TODO:
//this could be a big problem, the edge shared by two faces should be perpendicular to the two normal
//and it is not, I need to debug this with a repro, but for now just ignore it.
//ndAssert(edge.DotProduct(adjacentNormal).GetScalar() < ndFloat32(5.0e-2f));
ndAssert(edge.DotProduct(adjacentNormal).GetScalar() < ndFloat32(2.0e-1f));
I get the assert, but is not a terminal bug, it is a reminder to myself that they there can be bad contact generated at some edges.
basically, this is the problems.
the mesh patch that collides with a convex object is assumed to be a continue surface (a continue manifold). The exception is if the mesh has an open border, which should never happen in reality, since the physics assume a world where surfaces had thickness, but since this is digital world, the engine consider those cases by flagging the open edges.
Since the collision system process one face at a time. Each time the collision happens at an edge, it will generate a contact, but since we are dealing with a manifold, there will also be another face the shared the same edge and will produced another contact.
Unless those the two faces have the same plane equation, those two contacts will have different normal, and because of numerical error they will also have slightly different positions.
this is the cause of discontinue reaction forces by the solver.
I have tried many different solutions to this problem. most of the previous newton versions where base on generating the contacts, them in a postprocessing pass remove the redundant ones.
This is a very error prompt approach, that is full of numerical errors and tolerance tunning problems.
for Newton 4 the new approach is taking the assumption that the surface is continue, Therefore the contact generation itself should not generate more than one contact at the edge.
to do that, the mesh patch is authored with the edge information about the adjacent face.
then it generates a cap, that will extend the face by some skirt coplanar to the adjacent face.
for this the patch generator, determine if the two faced form a convex or concave edge.
when the edge in concave, the cap is zero length, because the should be not contacts over the edge.
if the two adjacent fasce are coplanar or convex, the face is extended, and it turns out that the contact in one face will be convex but for the other will be concave, therefore only one contact should be produced.
at least that's the general idea, the implementation is more involved, and that's why I put the comment there. I know that if I got there and I get a normal that is not perpendicular to the edge, it means that the other face will also generate a contact with a different normal.
I did not have a reproducible test at the time, so this one is very nice for debugging.
if you build in release or if you comment out the assert, it should run, so please try that, until I debug this,
also related to the second bug where you say the contacts set are reduce to zero after pruning,
that must certainly a different bug, so we check that later.