New btInternalEdgeUtility has been added

[sparkprime]

Since artists are used to defining hard/sharp graphical edges by splitting vertexes (sometimes with modeller concepts like smoothing groups), that would be a good way to contain this information.

[sparkprime]

I tried using 0.01 in the full engine and didn't notice much difference. I made the reproduction case a more faithful reproduction of one of the more obvious cases, and managed to make the problem surface again, and it still does even with 0.001. The triangles are now 8cm vs 20cm which is not that degenerate although it is fairly small generally.

One of the things I changed is going from 1000hz to 100hz which is what the actual game engine uses. That seems to put a bit more pressure on it.

zip of new patch (revert first) attached:

[sparkprime]

If you think it's the detection of edges needing special treatment that is at fault, maybe we can try manually specifying it. Since all of the edges are 90 degrees or zero degrees, this should not be hard, no? The edges diagonally through the middle of the quads are the only ones that should be considered internal in this case. However a falling box will penetrate 13 of the 17 edges so this is actually quite an extreme case. I have only noticed problems around 90 degree edges like this. Not always posts, sometimes fences and curbs are enough. But the effect is most pronounced with post-like shapes so that's what I put in the reproduction case.

[sparkprime]

Is it the case that the implementation works like this:

1) Identification of which edges are 'internal', which should mean they have the property that they are between two triangles and that the normals of these triangles are fairly well aligned.

2) When a body penetrates a triangle, the edge which is 'digging in' (no idea how that would be worked out in the case of a triangle that is completely inside a body) is checked to see if it is an internal edge. If it is not an internal edge then the collision is resolved as if no edge adjustment was done. If it is an internal edge then the collision is resolved in the same way except the normal is constrained to be 'between' the normals of the two triangles joined by the edge.

[vturchenko]

It looks like this utility fixed lots of problem but one problem still remains - sphere bounces sideways off the flat triangle mesh if it hits edge of triangle. Normal (thanks to this utility) is perfectly vertical but sphere gains angular velocity because contact point is on the edge but should be on another triangle's plane.

[sparkprime]

I still have my original problem too - infact the artifacts introduced by using edge info are worse than the artifacts it is trying to fix. Basically it has traded broken behaviour on smooth surfaces for broken behaviour on 90 degree corners.

[Erwin Coumans]

It looks like this utility fixed lots of problem but one problem still remains - sphere bounces sideways off the flat triangle mesh if it hits edge of triangle. Normal (thanks to this utility) is perfectly vertical but sphere gains angular velocity because contact point is on the edge but should be on another triangle's plane.

I still have my original problem too - infact the artifacts introduced by using edge info are worse than the artifacts it is trying to fix. Basically it has traded broken behaviour on smooth surfaces for broken behaviour on 90 degree corners.

I have not seen this behaviour, unless you triangles with opposite normals are very close to eachother. This degenerate case could be avoided in artwork

Can you both provide a reproduction case using bullet\Demos\InternalEdgeDemo\InternalEdgeDemo.cpp (not a diff but the full .cpp file)?
Thanks!
Erwin

[Dirk Gregorius]

@vturchenko:
I would say that for a sphere against several triangles one contact point is engough iff the triangles are in the same plane. Maybe you can collect all contact points with the same normal (cluster) and only keep the one which is exactly below the center of mass. This is just an idea though. I haven't tested this...

[sparkprime]

I have not seen this behaviour, unless you triangles with opposite normals are very close to eachother. This degenerate case could be avoided in artwork

if you mean something like a thin double sided wall then yes this is not the case I am worried about.

Can you both provide a reproduction case using bullet\Demos\InternalEdgeDemo\InternalEdgeDemo.cpp (not a diff but the full .cpp file)?

I gave an example some months ago, you said that it was degenerate so I adjusted it and attached a new zip, this time with no response from you.

thanks

[sparkprime]

Ah it's a diff, i'll upload the whole file, 1 sec

[sparkprime]

Here we go, change enable to 'false' to see the correct behaviour.

This is not the actual problem I have, rather it is a difference between the two modes that cannot be justified, which I hope is an example of the same bug which is causing my real problems.

My real problems are that cars (convex hulls) react unrealistically when they hit 90 degree corners.

[vturchenko]

The Internal Edge Utility Demo has "return 0.0f;" at the top of the function that calculates friction. But if friction is not 0 it does what I said. I'll compile together a sample soon that would show it. Maybe tomorrow.

[vturchenko]

Ok, today. Here it is. I've increased number of triangles and dropping sphere onto it. It bounces sideways. And if I move starting point slightly it bounces different way.
I've hardcoded combined friction and restitution to 0.5 and 0.3 respectively.

[Erwin Coumans]

Thanks a lot for the reproduction cases, it is good to make sure we are fixing the right issues. It looks like we are discussing 3 different issues.

First the 2 issues with sparkprime. Attached is an attempt to fix the two issues of sparkprime. There is a new threshold, that allows you to ignore edges angles above a certain threshold.

Code: Select all

	btTriangleInfoMap* triangleInfoMap = new btTriangleInfoMap();
	triangleInfoMap->m_maxEdgeAngleThreshold = SIMD_HALF_PI*0.25;//edge angles above this value are ignored
	btGenerateInternalEdgeInfo(trimeshShape,triangleInfoMap);

Secondly, it ignores certain concave edge cases that causes the issue in the reproduction case. This fix doesn't work when using the BT_TRIANGLE_CONCAVE_DOUBLE_SIDED flag.
Sparkprime, can you please test attached patch? Either patch in the Bullet/src/BulletCollision folder, or manually copy the 2 files in the appropriate folder.

The sphere-contact issue requires some more work. Dirk's suggestion sounds good, but is a bit hard to implement in Bullet. Another solution would be to write a tool that converts a btBvhTriangleMeshShape into a btCompoundShape with convex hulls, consisting of convex patches of merged triangles. This is also non-trivial.

Thanks,
Erwin

[vturchenko]

I know it's not trivial with Bullet. I used to solve this problem by sorting collisions. Collisions with planes should be resolved first, edges second and vertices last. Usually after resolving planes there is nothing else to resolve. That's how it was handled in my own old collision system several years ago. It makes perfect physics reaction but Bullet structured a little differently, as I understand. Moving object back out of collision until penetration is minimal will help in this case IMHO.