Newton 2.0x Archemedia Open Beta

[Julio Jerez]

I was starting to suspect that you were passing double faces like too.
I can problem handle that in the collision tree, but It will not work at all in the physic side.

Plane and simple a body hitting tow fact will produce unpredictable result.
The only way to go around that will be with heuristic and it is no clear what heuristic will usefully discriminate the wrong face.
can you do the same thong I suggested to rvangaar, displace the face by some distance to make a solid fence?

To sumarized 2.23 did solve some problems bu no all, in particular the it fail to optimize the Ramp?
I like to fix the Ramp, the algorism does not make assumption about normal orientation, so there must be a bug still somewhere.
can you post another demo without the double faces so that I can see where the remainder problems still are and fix those.

then after that, I can help you to implement a routine to make the solid face out of a flat strip using a NewtonMesh and a collision tree as auxiliary data structures.

[JernejL]

I was starting to suspect that you were passing double faces like too.
I can problem handle that in the collision tree, but It will not work at all in the physic side.

Plane and simple a body hitting tow fact will produce unpredictable result.
The only way to go around that will be with heuristic and it is no clear what heuristic will usefully discriminate the wrong face.
can you do the same thong I suggested to rvangaar, displace the face by some distance to make a solid fence?

To sumarized 2.23 did solve some problems bu no all, in particular the it fail to optimize the Ramp?
I like to fix the Ramp, the algorism does not make assumption about normal orientation, so there must be a bug still somewhere.
can you post another demo without the double faces so that I can see where the remainder problems still are and fix those.

then after that, I can help you to implement a routine to make the solid face out of a flat strip using a NewtonMesh and a collision tree as auxiliary data structures.

I will just separate the vertices apart and build convex hulls instead, it will add some thickness, and it should work ok i think.

the ramp still didn't optimize, i can make a simplier map, which would make just a simple ramp if that is ok.

[JernejL]

Ok i got you a example with just a simple ramp: http://mathpudding.com/tdc/juliotest%20TDC%20DEMO.rar

When you run it first it will generate all collisions, but only one should have any geometry.

Then you can delete the tstd_X1Y3T0.ngd again to have it re-generated.

You can see it ingame with debug rendering, but the game doesn't clear rendered pictures in old frames so it may look fuzzy when you move around.

[Julio Jerez]

execent that exactly what I need to debug that bug. Let us hope this is the last of this old time bug.

about making the faces convex hulls, that is a good idea.
conside making convex hulls array and places them all into one compound collision.
it will increase the performance way more than adding then each with thior own rigid body.

[Julio Jerez]

Delphi I found the problem, but this is not a bug, the mess is no flat.
If you consider the ramp made for a series of parallel slaps, the normal of each slap should be equal,
Hwoever in this mesh they are far apart by about one degree.

{m_x=-0.064863177942409908 m_y=0.00000000000000000 m_z=0.99789416680688714 ...}
{m_x=-0.059892233815093274 m_y=0.00000000000000000 m_z=0.99820484888054817 ...}
{m_x=-0.064863177942409908 m_y=0.00000000000000000 m_z=0.99789416680688714 ...}
{m_x=-0.059892233815093274 m_y=0.00000000000000000 m_z=0.99820484888054817 ...}


The test I made to determine co planarity has two parts:
first is if the dot product of tow adjacent faces normal is larger that’s 0.9999
that about 0.81 degree apart.

However that test is no enough, because consider a large circle, each adjacent face deviates less that 0.81 degree from its neighbor, as you combined faces, each subsequence face is and increasingly larger deviation, so the test fail.
To prevent that I do a second test which is verify that the point farther away from the new face is with close to the face the first face. And this is the test you mess fail to pass.
I was using a test distance of 0.0039 of a using, if double the distance to distance 0.0071 then It combine two slap, so the mesh is divine into two coplanar,
That tells me that the ramp is part of a curve with very small curvature.

I can no keep make the distance larger because as you can see 0.007 is more tha half a centimeters already and that
means that as face get bigger the collision will interpenetrate the visual mesh in some places and will float in the air in other places.

Can you verify that that mesh is made from tessellation and flat plane, and that the in-between point where not moved after that fact?
For now I will let the distance be at 0.0071 and see how it works. Maybe it is not a big problem.

Please try sdk 2.23 again

[JernejL]

This is impossible, the internal numbers i use for the slope parts (from left to right) are like this:

Code: Select all

0.00, -1.00, 0.50
1.00, -1.00, 0.56
1.00, 0.00, 0.56
0.00, 0.00, 0.50

0.00, -1.00, 0.56
1.00, -1.00, 0.63
1.00, 0.00, 0.63
0.00, 0.00, 0.56
 
0.00, -1.00, 0.63
1.00, -1.00, 0.69
1.00, 0.00, 0.69
0.00, 0.00, 0.63
 
0.00, -1.00, 0.69
1.00, -1.00, 0.75
1.00, 0.00, 0.75
0.00, 0.00, 0.69
 
0.00, -1.00, 0.75
1.00, -1.00, 0.81
1.00, 0.00, 0.81
0.00, 0.00, 0.75
 
0.00, -1.00, 0.81
1.00, -1.00, 0.88
1.00, 0.00, 0.88
0.00, 0.00, 0.81
 
0.00, -1.00, 0.88
1.00, -1.00, 0.94
1.00, 0.00, 0.94
0.00, 0.00, 0.88

I just translate this per block as needed, and send it to newton, but i guess the internal floating math imprecision might be a big factor in making these numbers go off?

Question: could we get that distance parameter as a extra to NewtonTreeCollisionEndBuild ? this way each app could set tollerances for these values, and perhaps improve the generation of trimeshes depending on what kind of geometry it uses.

[Julio Jerez]

That could be possible but the idea of a face do not let to provide an extra parameter, because if you set the parameter to something too big,
the optimized will make face out of set of points that are no real flat, thes will give miss information to the contact solver. the distance is already too large as it is.

Maybe for a not collision usage of the collision tree, but not for collision tree that are used as collision mess.

the engine use a technique called hill climbing to find the pointer farthest away in one direction

that technique only works for convex set, it basically works like this, in a cove set if you are searching for target you can consider the target the point in a mountain. so if you are and any points on the skirt you can always take the step along the largest slope that move you closer to the ape. you can stop the search when all the slope at each neighbor point from when you are can only take you down.
in two d you can see this as being in a ramp, in the ramp you can only move up or down, so if you are looking for the top point you can stop when you find a point how front and back are lower than the point that you are.
Now assume that the hill has nodulations as you go up the, it is possible the in your way up you find a point that is not the top, but the imitated neighbor are lower, so the search stop which the wrong answer.

I take a set of point and make a face and say these faces make a convex face, and I use the same algorithm to find extreme points, the algorithm will work in most cases but the will be those in which a face is colliding at an edge and the normal is almost coplanar to an edge.
it will find two a point in which the previous is lower, and the next is also lower that the one is at, however neither of the three is the most extreme and the collision will stop with a contact that is several meters away from the real collision point.

The technique to avoid that is call Annualizing, but that is something I do not want to do because is too expensive.

Let us see how this tweak works,

[Julio Jerez]

To make the story short, I do not like the idea of exposing a parameter that will change the meaning of what they are supose to do.
for example in the convex hull, the tolerance make sence because it will away make a conve hull, a smal tolerenace will make a conev hull tha match closelly teh orinional set of point, a large tolerance will make a convex hull that does no match teh original set of peoint very well.

In the collision tree a large distance does not make large faces that are convex, and the is where the problems is,
in make a set of points who's convex hull is has a non zero volume.

[JernejL]

The new build works very good and builds far more optimized trimeshes, but if this is a problem with my vertices i can try and correct that myself, if you think that this new building tollerance variable could have other side effects i can try to correct the geometry to be totally flat properly.

[Julio Jerez]

No let us see what happens, leave it alone, I beleive it is fine like it is now.

[shybovycha]

Bug found: most of prebuilt demos in Newton 2.23 fail... Both on x32 and x64... And there's no car demo nor CC... That's bad...

[Julio Jerez]

They fail because I am in the proccess of changing the file format,
I released it because there were peopel who had bug tha coudl not continue wroking with oy the new library.
It will be until I put teh new editro tha the demos (with the car) will be back working and much, much eassier to use than it is now.

Be patient, let me move the editor on, and all those thing will be over.

[shybovycha]

got it =)
lot of thanks to you, Julio, for your hard work! =)

[rvangaal]

What I did for the collision tree files (since they indeed crash when you change Newton versions) is to wrap them and add a header which contains the specific Newton version.
You do have to take care that newton.h is only sometimes updated to define the real version number:

#define NEWTON_MAJOR_VERSION 2
#define NEWTON_MINOR_VERSION 22

While loading, I check the version nr stored in the tree collision file. If it doesn't match, the load fails. A check within Newton would be nice, but I worked around it this way (automatically generating an updated file if needed).

[Julio Jerez]

A check within Newton would be nice, but I worked around it this way (automatically generating an updated file if needed).

hopefully all that will go away when I put is the library that will allow saving and loading a database with the assets.
the database will handle all the revision stuff, all the client application have to do is link to the database, and save the world in using the data base,
then it can add or retrieve anything from it.
I hope that take care of that problem.