User mesh doesn't work

[PJani]

This is actually collected in NewtonUserMeshCollisionCollideCallback...directly from original arrays. I started logging directly each pass.

O and i figured Newton uses CW winding not CCW i use by default.

[Julio Jerez]

Oh ther was a bug in the demos, the class dInfinitePlane in this file
c:\tmp\newton-dynamics\applications\demosSandbox\sdkDemos\toolBox\UserPlaneCollision.cpp

Code: Select all

   // this is local per thread data
// this was the bug
   dInt32 m_faceIndices[MAX_THREAD_FACES][2];

//   dInt32 m_indexArray[MAX_THREAD_FACES][4 + 4 + 3]; // 4 indices + 1 attribute + 1 index normal + 4 adjacent edge normals + 1 face diagonal size = 11 indices
   dInt32 m_indexArray[MAX_THREAD_FACES][2 * 9]; // 2 trinagles of (3 indices + 1 attribute + 1 index normal + 3 adjacent edge normals + 1 face diagonal size) = 9 * 2indices
   dVector m_collisionVertex[MAX_THREAD_FACES][5];   // 4 vertex + 1 face normal

was overiding the m_faceIndices inde array, I foudn i whe addin the triangle option, if you made your demo form that example you probably has the same bug
I fix it, the good news is that when I fix the demo teh debug code show the two triangles,
see if you get the same result.

[PJani]

I don't think this is the problem! I didn't use demo...i wrote my code and then i went comparing my code and the demo code.

What actually happens is the first triangle exists for a few seconds(collision checks) and then gets overriden with second triangle indices.

[Julio Jerez]

can you make a test sample?

[PJani]

i will make test demo asap.

[PJani]

Ok i am a bit learning how to properly debug so i did some dirty work(bless the debugger and breaking on data change ) and i figured via IDA a memcpy gets called! I am not sure which one(VC++2008 debugger opens disassembly so... :/), but here is the code address( 0x1010B84A) in newton_d.dll of the assembly call which changes value in my original index array.

Here i am guessing a bit so...

from dgCollisionUserMesh.cpp line 168.

Code: Select all

memcpy (&indices[faceIndexCount0], indexArray, faceIndexCount * sizeof (dgInt32));


I need to dig deeper

EDIT: I think i know why this happens or when...When the first triangle is being evaluated and is "ignored" due to this part returning 0.0

Code: Select all

dgFloat32 dist = data->PolygonBoxDistance (faceNormal, indexCount, indexArray, stride, vertex);


the faceIndexCount0 is not being incremented(some design feature to minimise number of faces, bug, typo?)

Code: Select all

faceIndexCount0 += faceIndexCount;


and in second pass second triangle overwrites ignored first triangle

Code: Select all

         const dgInt32 faceIndexCount = data->GetFaceIndexCount(indexCount);
         if (dist > dgFloat32 (0.0f)) {
            hitDistance[faceCount0] = dist;
            address[faceCount0] = faceIndexCount0;
            faceIndexCountArray[faceCount0] = indexCount;
            memcpy (&indices[faceIndexCount0], indexArray, faceIndexCount * sizeof (dgInt32));
            faceCount0 ++;
            faceIndexCount0 += faceIndexCount;
         }
         faceIndexCount1 += faceIndexCount;


this are my 5 cents

The only hack fix i could think of is actually copying each call in to some temporary index values. Or just rebuild indexes each time...it would probably be better

[Julio Jerez]

Ok i am a bit learning how to properly debug so i did some dirty work(bless the debugger and breaking on data change ) and i figured via IDA a memcpy gets called! I am not sure which one(VC++2008 debugger opens disassembly so... :/), but here is the code address( 0x1010B84A) in newton_d.dll of the assembly call which changes value in my original index array.

Here i am guessing a bit so...

from dgCollisionUserMesh.cpp line 168.

Code: Select all

memcpy (&indices[faceIndexCount0], indexArray, faceIndexCount * sizeof (dgInt32));


better

woow, that's the bug. I see it now.
Basically after the faces are passes that code after that only passes teh fase that are actially hitting teh shape.
when some faces are rejected, it pack the point array, but your array is static therefore it override the source data.
that's a bug in newton side I will fix it.

[Julio Jerez]

alright try again please, that was the biggest bug all alone, but we found many more small one as well.
so that was good.

[PJani]

Ok i will check as soon I do some minor changes to algorithm for surface generation.

[PJani]

I am sorry this is taking so long, but i was forced to abandon this algorithm i was using for building terrain...it was to unpredictable. I will soon test Usermesh

[Julio Jerez]

what algorithm, the mesh reconstruction? can't you used the same one you are using to generate the visual mesh,

the mesh patch for collision is very small.

[PJani]

I was actually using the marching cubes to generate terrain but terrain features were to hard to control so i am switching to dual contouring method(where i can control soft and sharp features).

[PJani]

My algorithm is almost finished.
Julio is there any good and fast and memory efficient way to find neighboring faces?

[Julio Jerez]

if the data does not have any geometrycal property that can be exploited, the one I know is the wing edge.
the only problem with wing edge is that they do nor handle volume, and that they only sopport simpel maniforld meshes.
But even with that they are very powefull.

you are using voxels, voxel have lot of similuarity that cna be used for geting neighbor faces

[PJani]

Heh you are right i can use my grid.

Ok another question...is it possible to have one array for face normals and another for vertexes? Because vertexes are prebuild into vector in my case and they are just sitting in the RAM for most of the time. Normals are not and they need to be computed for faces.