New btInternalEdgeUtility has been added

[sparkprime]

Thanks Erwin, I'm going to investigate this thoroughly, it seems that if the angle threshold was 0 there will never be any edge adjustment?

Wouldn't 180 degrees be a better default value?

How exactly is the angle measured? Is it 360 - A (below)?

Code: Select all

          |  
---------------------
               ( A /
                \ /
                 /
                /  
               /\
              /
             /
            /

[sparkprime]

Or is it the angle between the normals, in which case it will never exceed 180 degrees.

I also notice this code you added:

Code: Select all

+               btVector3 newNormal = tri_normal *frontFacing;
+               //if the tri_normal is pointing opposite direction as the current local contact normal, skip it
+               btScalar d = newNormal.dot(localContactNormalOnB) ;
+               if (d< 0)
+               {
+                   return;
+               }

Is this saying that the original normal of the contact (i.e. for a knife edge it will be the direction of the point, quite far from the normal of both triangles involved) is more than 90 degrees from the triangle normal, then do not adjust this contact normal? It seems quite hard to cause this, did it happen in my reproduction?

[Erwin Coumans]

It is the angle between the normals of the two triangles, shared by that edge.

It was indeed colliding with an internal edge on the side of the tesselated box, with the normals pointing sideways. See the picture.

internal_edges.png (18.27 KiB) Viewed 19048 times

Have you tried it already?
Thanks,
Erwin

[sparkprime]

So any value >= 180 degrees means 'always use edge adjustment' and any value <= 0 means 'never use edge adjustment'.

I did try it and it seemed to improve a bit but I also decreased m_edgeDistanceThreshold to 0.001 and that also helped, I'm not sure which it is yet. I'm going to tweak the values at runtime (by regenerating the shape) and see what I get.

[sparkprime]

With this internal edge you marked in red, presumably it was intersecting that corner, and was therefore intersecting 5 triangles.

All of the triangles were intersecting with just one of their vertexes. (I.e. just the point was sticking into the cube)

Each triangle would generate a single contact point, right?

The normal at that contact point would start off being pretty much orthogonal to the normal of the triangle that generated it, and would also point away from the triangle.

How come it was pointing against the direction of the triangle normal? There must be something I'm missing.

[sparkprime]

I see what's happening, I don't get any improvement unless I set the angle threshold to zero (which is equivalent to not using edge adjustment at all). The problem is that although the 90 degree corners are working fine, the edges like the one marked in red are considered to be smooth and are therefore adjusting the normal from 'up' to 'sideways' which knocks the block off the top of the wall / pole / whatever.

Perhaps the behaviour should be that if the contact point falls close to more than one edge of a triangle then if >0 of those edges are sharp edges then it will not adjust normals. That would at least do the right thing in this case I think.

[Erwin Coumans]

The problem is that although the 90 degree corners are working fine, the edges like the one marked in red are considered to be smooth and are therefore adjusting the normal from 'up' to 'sideways' which knocks the block off the top of the wall / pole

The new code (return if dot <0) should deal with this, your reproduction case seems to work fine. You are not using the double-sided option, right?

Can you please provide a new repro case that shows the issue?
Thanks for the help,
Erwin

[sparkprime]

Yeah I'm not sure why it shows up in the game and not in the repro case, I need to look into it further

[sparkprime]

It seems to become unstable again if you move the box so that it is offset from the centre the same amount but in the opposite direction. I.e. invert the X and Y

Code: Select all

        startTransform.setOrigin(btVector3(-0.01,hh+.15,-0.011));

instead of

Code: Select all

        startTransform.setOrigin(btVector3(0.01,hh+.15,0.011));

I may have made a couple of other changes but I think this is the important one. Attaching both cpps again.

It seems to be stable without edge adjustment but unstable with it. It also slides off sideways at quite a speed, I expect the more offset it is from the centre, the more likely there will be an incorrect lateral force applied.

[TheGameMaker]

This is going to sound really stupid: Is this btInternalEdgeUtility really needed? Seems a bit complicated. Can't you just cancel a collision if an object is moving through the back of a triangle (the opposite of the normal)? That's how other physics engine's Ive seen do it. In other words: have only singles sided triangles. I don't fully understand what this utility does (maybe that's what you're trying to do) so if I'm being ridiculously stupid feel free to tell me to go away

[Erwin Coumans]

It seems to become unstable again if you move the box so that it is offset from the centre the same amount but in the opposite direction. I.e. invert the X and Y

Hi sparkprime,

Thanks again for the repro case, there is still some work to be done to fix your case. I have some ideas and hope to get some time soon to fix it.

Is this btInternalEdgeUtility really needed? Seems a bit complicated. Can't you just cancel a collision if an object is moving through the back of a triangle (the opposite of the normal)?

It is a reasonable question. One of the main issues we try to solve is contacts with 'wrong' collision normal, when sliding over a smooth/flat triangle mesh. In most case, the object is at the front side of both triangles. Please check my presentation about contacts from GDC 2010.

Thanks,
Erwin

[TheGameMaker]

I looked at your presentation but I think it's a bit much for me to understand. I'm glad that my question was reasonable though but I wouldn't be able to help any further. My knowledge of how physics engines work is very limited.

[ink]

Hi Erwin,

I've encountered some issue with normals adjusting. When box moves towards the corner, sometimes contact normals are corrected in unusual way, which results in box "pulling into" the corner. On the picture red arrow is normal before correction, blue - after correction, yellow are mesh surface normals.



I'm not sure about why this is happening, but it seems that concave edge is somehow recognized as convex (as it executes numConvexEdgeHits increment on lines 554, 636 or 714 of btInternalEdgeUtility.cpp, I'm using btInternalEdgeUtility.cpp from this post attachment: http://bulletphysics.org/Bullet/phpBB3/ ... 478#p21478 )

I've made some reproduction case - mesh is kind of a square tube with triangle normals directed to the inside. To move the box gravity is directed towards the corner, but not vertical (it's modified ConcaveDemo).

Without adjusting box is almost still (I suppose small movement is because of huge gravity, but it's fine) - http://www.youtube.com/watch?v=wVS1Kq4bA6s
But with adjusting box is noticeably shaking - http://www.youtube.com/watch?v=XGIQjNQ1xmM

By default internal edges adjusting is turned on, use 'n' key to toggle.

Bullet version used is 2.77 with this post update: http://bulletphysics.org/Bullet/phpBB3/ ... 478#p21478

Thanks!

[JaZzBrE]

I also had problems with this. Since the distances between an edge and the contact point can be anything (not inside m_edgeDistanceThreshold in most cases, even if set at 0.1 or so, with shape margin at 0.02) - I've changed the test so that it first finds the distance to the nearest edge and use it - along with a really small m_maxEdgeAngleThreshold. Of course this only fixes the cases when moving over a tesselated flat terrain, didn't come across the other cases mentioned.

Regards,
Ales

[Erwin Coumans]

Hi ink, thanks for the repro case, I created a new issue for it here:

http://code.google.com/p/bullet/issues/detail?id=500

JaZzBrE, can you provide a patch and attach it to the same issue?
Thanks!
Erwin