Problem with User Mesh Collisions

[Fabio]

Hi,

I'm using version 1.53. I've encountered a problem using user mesh collisions with NewtonCollisionCollide function. I want Newton do not test collisions on coplanar faces shared edges, so I've marked the output collision face indices, inside the NewtonUserMeshCollisionCallback, usign the trick explained on the documentation (vertex index | 0x80000000) but nothing happens, contacts on shared edges are still passed by NewtonCollisionCollide. Why? Please help me to solve. This is important for my character system when colliding with walls.

[Julio Jerez]

That method was replaced in 2.0
Please move to 2.0 the edge is automatic

[Fabio]

That method was replaced in 2.0
Please move to 2.0 the edge is automatic

So you confirm that this particular code segment doesn't work on 1.53? i need to know it 'cause I've loved 1.53 version for its simplicity and robustness( until now all I've made works perfectly, except this particular question), and I will be very afraid to move to 2.0 only for this .
I've also tried to move to 2.0 but I've encountered some problems. With the same code written with 1.53, with 2.0 the bodies do not collide. There is something different about collisions that i've to do respect 1.53?

[Fabio]

That method was replaced in 2.0
Please move to 2.0 the edge is automatic

I've pass to 2.0 but the problem is the same: When using UserMeshCollision and CollisionCollide function it seems that the coplanar faces shared edges are taken into account even if I mark the edges index with the most significant bit (index | 0x80000000). This fact , when using cylinder as character, is a big problem with walls made by 2 triangular faces, many contacts are generated with wrong normals. It seems that Newton treats them not as a single quad face but as 2 separated triangles. Reaching to tell Newton to not consider the shared edge between the 2 tri faces I think will solve the problem. But I don't reach to do that. Help me please, How can I do it?

[Julio Jerez]

So you confirm that this particular code segment doesn't work on 1.53? i need to know it 'cause I've loved 1.53 version for its simplicity and robustness( until now all I've made works perfectly, except this particular question), and I will be very afraid to move to 2.0 only for this .
I've also tried to move to 2.0 but I've encountered some problems. With the same code written with 1.53, with 2.0 the bodies do not collide. There is something different about collisions that i've to do respect 1.53?

The code worker by I stop usin that method for edge detection.
if you liked 1.53 then you must like 2.0 better, because 2.0 is better in every aspect.

Is there any reason why you are using user collision, There are many many optimization that the tree collsion has that can not be added to the user mesh.
Edged dectection now uses a more elaborated data strusture that just those bitfield. Can you try the tree collision? and see if it is better

also what are you doing with 1.53 tha 2.0 fail to pass?

[Fabio]

So you confirm that this particular code segment doesn't work on 1.53? i need to know it 'cause I've loved 1.53 version for its simplicity and robustness( until now all I've made works perfectly, except this particular question), and I will be very afraid to move to 2.0 only for this .
I've also tried to move to 2.0 but I've encountered some problems. With the same code written with 1.53, with 2.0 the bodies do not collide. There is something different about collisions that i've to do respect 1.53?

The code worker by I stop usin that method for edge detection.
if you liked 1.53 then you must like 2.0 better, because 2.0 is better in every aspect.

Is there any reason why you are using user collision, There are many many optimization that the tree collsion has that can not be added to the user mesh.
Edged dectection now uses a more elaborated data strusture that just those bitfield. Can you try the tree collision? and see if it is better

also what are you doing with 1.53 tha 2.0 fail to pass?

I've decided to use user mesh collision 'cause I've already my broad phase collision detection method. I found very genius the method of using callback to offer developer the possibility to use his own broad phase detection, I found newton is the only physics engine that offer me this possibility. The advantage of this solution is that I do not have to modify my data structures but only make newton to 'understand' my data. This is genius, other physics engine, also commercial ones, do not make this for me . I'm sure that tree collisions are very optimized, but like other physics engine, this method forces me to use data structures that differ from ones I've integrated in my engine. For example, to build tree collision I've to do a preprocessing phase to convert the input mesh into the tree, this have a cost in time, I can serialize it to optimize the tree mesh loading during runtime, but I would to have a 'realtime' behaviour also inside edititng. I will try tree collisions but before I would to do my best with user mesh collisions to better 'integrate' newton in my vision. About 2.0, The using of threads requires a better care in callback implementation, right? I've to use critical section newton fuctions?

[Fabio]

So you confirm that this particular code segment doesn't work on 1.53? i need to know it 'cause I've loved 1.53 version for its simplicity and robustness( until now all I've made works perfectly, except this particular question), and I will be very afraid to move to 2.0 only for this .
I've also tried to move to 2.0 but I've encountered some problems. With the same code written with 1.53, with 2.0 the bodies do not collide. There is something different about collisions that i've to do respect 1.53?

The code worker by I stop usin that method for edge detection.
if you liked 1.53 then you must like 2.0 better, because 2.0 is better in every aspect.

Is there any reason why you are using user collision, There are many many optimization that the tree collsion has that can not be added to the user mesh.
Edged dectection now uses a more elaborated data strusture that just those bitfield. Can you try the tree collision? and see if it is better

also what are you doing with 1.53 tha 2.0 fail to pass?

Another information. I'm still using vc6 as compiler. Newton 2.0 sometimes crashes where 1.53 not. Maybe this is due to the fact that newton dll are compiled with vc7/vc9 while my code is compiled with vc6?

[Stucuk]

If you are using the DLL version then it will have nothing to do with what compiler you are using. Since im not a C++ programmer i don't know if vc7 lib files are compatible with vc6. In any case, if you try the DLL version (assuming your using the libs) then you will be able to see if its more stable for you.

[Fabio]

If you are using the DLL version then it will have nothing to do with what compiler you are using. Since im not a C++ programmer i don't know if vc7 lib files are compatible with vc6. In any case, if you try the DLL version (assuming your using the libs) then you will be able to see if its more stable for you.

I'm already using the dll, the lib file not compile at all with vc6. Probably there is something that I made with 1.53 that 2.0 don't like much, or make different, I've to investigate, I'm using 2.0 only a couple of hours:). About mesh collision, I've passed to tree collisions and it seems to work perfectly and the pre-compiling phase is very fast. Many thanks to Julio for opening my mind .