class ndPolyhedra: public ndTree <ndEdge, ndEdgeKey>
anyway, Bird, yes still not good.
The fix I made does not really fix the problem, is fix two of problems
1- the mesh was rejecting tine and ill triangle,
2- the buffer that query the interesting faces, was too small because is was mass of the stack,
for year I have been making large ar large, it start with 32 face, the 64, 128, 256, now was 512.
with the marine rocks mesh, to collect the faces, it the code could not run a over 65 k triangles because it runs out of stack.
I loaded the mesh in max, and I see that the mesh has a very estrange scale with of lenght of 1.0e-4.
with the size of the convex I was using which is about 10 % of the entire size of the floor, a query collect tenth of thousands of faces.
I went to Max and reset the scale to be meters instead of a kilometer and save it.
now the query get around 10k faces.
this is still ridiculous, but the engine should handle it, so I made the change so that the temp data is not longer on the stack, instead they are thread local buffers kept in the scene.
that's that problem
the jitter problem we still have is related to the contact be inconsistent from frame to fame.
for that I have to implement the close approach part of eth collision that I have not gotten around
that is this part of the collision rotting that is comment out form 3,14
you will find in functions like
- Code: Select all
void GetCollidingFaces(ndPolygonMeshDesc* const data) const
....
....
if (data->m_doContinueCollisionTest)
{
ndAssert(0);
//dFastRay ray(ndVector::m_zero, data->m_boxDistanceTravelInMeshSpace);
//for (ndInt32 i = 0; i < faceCount; ++i)
//{
// const ndInt32* const indexArray = &indices[faceIndexCount1];
// const ndVector& faceNormal = vertex[indexArray[4]];
// ndFloat32 dist = data->PolygonBoxRayDistance(faceNormal, 3, indexArray, stride, &vertex[0].m_x, ray);
// if (dist < ndFloat32(1.0f))
// {
// hitDistance[faceCount0] = dist;
// address[faceCount0] = faceIndexCount0;
I thought that I could probably get away without it, but that test you show me demonstrate that it does really need it.
so after I complete the change, I will re implement the closest approach contact.
in 3.14 that was done based of the deepest penetration, when a shape collides with a ground of faces, in deep penetration, is sort the array by penetration and reject the contact the did with lower penetration,
in 4.xx I removed that in favor of a more generic contact discriminator, that detect contact by the eigen values. this work quiet well but is fail bad with contacts with such wide range of penetration.
anyway after I get this global memory buffers, I will revisit and get that part with the test repro.
mean time, can you try decimating the mesh even more, maybe 100,000 or less face, and see if it
get to a stable setting,