TreeCollision optimization bug

[Cannos]

I think there may be a bug in tree collision optimization. I have a mesh that, when optimized, is coming out with a hole in it. See this screenshot: https://www.dropbox.com/s/1q89qet6oo93rv7/Capture.PNG

When I turn off optimization in the NewtonTreeCollisionEndBuild call, it come out fine, without the hole.

Here are the serialized files for both the optimized and unoptimized case, if you're able to take a look at the issue:
https://www.dropbox.com/s/xdjk90oxky1iy ... 5.bin?dl=0
https://www.dropbox.com/s/lf2yx3mzcw4ox ... 2.bin?dl=0

NOTE - I'm running on an older version of Newton from September 2016.

[Julio Jerez]

I can download file from were I am now, but the first thing is to try the new version and see if the bug goes away.
There has been a lot of work on that part of the code, with special focus on adaptive arithmetic to reduce numerical errors.
also September 2016 is old enough that chances are the serialization does not work.

[Cannos]

Looks like I get the exact same results with the latest code. And yes, it appears that serialize didn't work. In fact, the latest demosSandbox doesn't implement serialize/deserialize, it just asserts.

So I saved out my track mesh in a simple file and manually loaded it and created the mesh. Here's the file: https://www.dropbox.com/s/gdh8x7o73jbj8 ... k.bin?dl=0

And here's code to load the file and create the tree collision body. Just replace the <path> part for wherever you drop the file and call LoadAndCreateMesh().

Code: Select all

void LoadAndCreateMesh(DemoEntityManager* const scene)
{
    FILE* f;
    f = fopen("<path>/track.txt", "rb");
    if (!f)
        return;

    NewtonCollision* pCollision = NewtonCreateTreeCollision(scene->GetNewton(), 0);
    NewtonTreeCollisionBeginBuild(pCollision);

    // Read number of triangles
    int numTris;
    fread((void*) &numTris, 4, 1, f);

    // Add face for each tri
    for (int i = 0; i < numTris; i++)
    {
        // Read 3 vertices (3 floats per vertex)
        float v[9];
        fread((void*)&(v[0]), sizeof(float), 9, f);

        NewtonTreeCollisionAddFace(pCollision, 3, &(v[0]), 3 * sizeof(float), 0);
    }

    NewtonTreeCollisionEndBuild(pCollision, 1);

    dMatrix matrix(dGetIdentityMatrix());
    NewtonCreateDynamicBody(scene->GetNewton(), pCollision, &matrix[0][0]);
    NewtonDestroyCollision(pCollision);

    fclose(f);
}


[Julio Jerez]

ok I will past that code and see what is wrong.
Thank for the repro.

[Cannos]

Have you had a chance to check this out? Thanks.

[Julio Jerez]

I pasted the test in the branch I am using to do the final tweaks to 3.14
and I realized that that I can committed just yet.
I will copy it to the current GitHub so that I can committed.
I am try to get all the final changes to 3.14 so that I can put final build before the year is out.

but I can check that but out independently, I see if I do it tonight.
sorry about that.

[Julio Jerez]

I am still working on this I am adding a visualization because I do no see the mesh.
I committed he test so that we can work together.

[Cannos]

Yes, I did not add a visual mesh because I could use the Show Collision Mesh options in the sandbox.

[Julio Jerez]

Ha, stupid me, I was adding a entity for the display forgetting that there is already debug display.
I now see were the bug it, there are some missing faces that do not close the mesh, and is not there when not optimizing. I can debug now and delete the display stuff

the demo is in UsingNewtonMeshTool.cpp

[Cannos]

Hey Julio, just wanted to follow up again to see if you'd had a chance to debug this. Let me know if you need anything else from me.

[Julio Jerez]

collsionbug.png (42.44 KiB) Viewed 10410 times

I have it narrowed to the exact face that cause the problem.
But for some reason I did no see why that face can no be collapsed to a single one.
There are several stages and they all checked out, I just have to gotten to the last one.
as you can that should be a single face, and it show up at the point in the stage I have debug so far.
I just has not gotten time to do the rest.

I am going to have some time off this week, so I should be able to fix, the reason I do no what to make drastic change is because it seem odd that the bug should there, and no on other meshes, so
I was thing that there was probably a double face or something like that.
but I see now there seem to be a bug in fining the interior edges, seem it clearly show there show be four but the function returns 6. therefore it delete the some of the outline edge.

[Julio Jerez]

alright I believe is fixed now. please think sync,

if you are final final product, and you only want the changes that fix that bug,
you can get the current version and only copy files :
../sdk\dgCore\dgPolyhedra.h
../sdk\dgCore\dgPolyhedra.cpp

there has been some important changes that make the engine better by that cause different behavior.
else you can just get the current version.

[Cannos]

Thanks Julio, I integrated the new dgPolyhedra.* into my version and that fixed the issue.

[Julio Jerez]

Oh nice,

can you make me a favor? can you make a separate copy of your project and try to integrate the latest 3.14.
No particular reason, just to see if the latest changes cause any bad side effect.
I expect side effects but they should be toward higher physic fidelity and in generate better performers.
The new change are all focus on having a exact block joint solver at all time, no more interactive mumbo-jumbo for newton.

The good thing of a numerically exact solve is that if the physics is plausible and fishable there the solve is faster that anything.
I am not longer going to chase high speed at all cost from 3.14 on, like I was trying to do before in 3.13 and the beginning 3.14.
The engine is suffucnetlly fast for people it make any decent project without the support of some expect in voodoo magic. if people nee to make 5000, 1nd 10000 thousand stacks of boxes all jittering and unstable then there are other engines that can do that.

so if you can try that when you have time to spare, it will be good for me to know.

[Cannos]

Hi Julio,

Looks like a variation of the same track as before has holes and other problems in it, similar to before. Here's the new track file, if you have a chance to try it out:
https://www.dropbox.com/s/2d0t219t5mnol ... 2.bin?dl=0

Thanks for the help!

PS. - I haven't had a chance to try the latest 3.14 on my game in a while. We're in the last couple months of our project and don't have a lot of spare time right now, but I'll let you know if I get a chance. The last time I tried the latest version (last January), the dynamics behaved much differently than before, and our game was tuned to work with the previous dynamics, so I had to stop updating at that point. Around that time is when I was posted this:
viewtopic.php?f=9&t=9036