Different jitter on different shape types?

[AlexSilverman]

I don't know why this didn't occur to me before now, but I think that the reason that altering the contact normal within the ContactAddedCallback is the same reason that the friction and restitution changes were not being taken into account. To see if this is the case, download the most recent patch from Issue 53 in the Google Code database, or from [url=http://www.bulletphysics.com/Bullet/php ... f=9&t=2097]this thread] and apply it then test the ContactAddedCallback method again. If you aren't hooked into the SVN, you can download the attached file and overwrite the files you are currently compiling Bullet with. I only included the files that are changed in the patch.

Hope this helps.

- Alex

[pico]

I don't know why this didn't occur to me before now, but I think that the reason that altering the contact normal within the ContactAddedCallback is the same reason that the friction and restitution changes were not being taken into account. To see if this is the case, download the most recent patch from Issue 53 in the Google Code database, or from [url=http://www.bulletphysics.com/Bullet/php ... f=9&t=2097]this thread] and apply it then test the ContactAddedCallback method again. If you aren't hooked into the SVN, you can download the attached file and overwrite the files you are currently compiling Bullet with. I only included the files that are changed in the patch.

Hope this helps.

- Alex

Hi Alex,

thanks for the files, but it seems a file is missing.

I'm using Bullet 2.66 and get all over compile errors for "undefined identifier m_appliedImpulse" which seems to be used in the m_pointChache.

[AlexSilverman]

pico,

Ah. I probably should have mentioned that the files I posted are from Bullet 2.68. I'm willing to bet that's the problem. My mistake. In any case, I don't have a copy of 2.66 anymore, and it appears that Google Code doesn't support downloading all old versions the way SourceForge used to, but if you'd like to try and reproduce the changes I made, there's really only three things that need to be done. The contact point that is passed to the user defined ContactAddedCallback is currently not the same object as is cached in the contact manifold. To counter this, I replaced the line

Code: Select all

(*gContactAddedCallback)(newPt,obj0,m_partId0,m_index0,obj1,m_partId1,m_index1);

with

Code: Select all

(*gContactAddedCallback)(m_manifoldPtr->getContactPoint(insertIndex),obj0,m_partId0,m_index0,obj1,m_partId1,m_index1);

in the method btManifoldResult::addContactPoint.

Additionally, the insertIndex is incorrect at this stage if the contact point is not already in the manifold, so the method btPersistentManifold::AddManifoldPoint must be made to return the index at which the contact point was inserted. This value should be caught inside btManifoldResult::addContactPoint, when the contact point is added.

Finally, Ryan Juckett pointed out the necessity of adding the last two lines after the callback

Code: Select all

// recache body transforms incase they were modified in the callback
m_rootTransA = m_body0->getWorldTransform();
m_rootTransB = m_body1->getWorldTransform();

If you do this in your version of Bullet, it should work fine. That said, allow me the small disclaimer that I haven't tried this in BUllet 2.66, and I don't know what has been changed in the subsequent two versions from then till now.

Hope this helps.

- Alex

[Peter Tchernev]

The general solution to this problem is to ignore contacts whose normals are outside the voronoi region of the triangle feature that they are located on.
It is possible to do it without explicitly computing the voronoi regions by keeping a list of "voided" edges and vertices for each collision pair / detector.
For each contact we need to know the closes feature on the the triangle of the mesh.
We do this using information from GJK.
If a face is the closest feature of the triangle all it's edges and vertices are added to the "voided" sets.
If an edge is the closest feature of the triangle all other of the triangle edges are and vertices are added to the "voided" sets.
If a vertex is the closest feature of the triangle all other of the triangle edges are and vertices are added to the "voided" sets.
Then a pass is made to validate all the contacts.
Any face contacts are passed.
Any edge contacts that do not appear in the voided edges set are passed and their vertices are added to the voided vertices set.
Any vertex contacts that do not appear in the voided vertices set are passed.
The tricky bit is to recognize common edges and vertices.
Can be done (correctly) using indices if available or (somewhat ad-hoc) using a hash code based on coordinates.

[pico]

pico,

Ah. I probably should have mentioned that the files I posted are from Bullet 2.68. I'm willing to bet that's the problem. My mistake. In any case, I don't have a copy of 2.66 anymore, and it appears that Google Code doesn't support downloading all old versions the way SourceForge used to, but if you'd like to try and reproduce the changes I made, there's really only three things that need to be done. The contact point that is passed to the user defined ContactAddedCallback is currently not the same object as is cached in the contact manifold. To counter this, I replaced the line
- Alex

Hi Alex,

i updated to 2.68 and included your patch.

The problem is not fixed.

My test: I let rest a sphere on a subdivided flat triangle mesh. The sphere has a gravity of 0,-10,0. Then i give a pulse to the sphere, only on one axis.
After some frames there sphere will leave its straight direction and will tilt a little to one side. On longer distances this makes quite a difference. E.g. a 'snooker' game would be impossible to play. The problem is seen best when no friction at all is applied.

[Erwin Coumans]

Please create a reproduction case in a Bullet demo, and we can check it out,

Thanks a lot,
Erwin

[pico]

Please create a reproduction case in a Bullet demo, and we can check it out,

Thanks a lot,
Erwin

Hi Erwin,

attached is an example based on "ConcavePhysicsDemo.cpp".

The demo features a sphere on a subdivided triangle plane. The sphere gets an impulse only on the Z axis.
When you watch the movement of the sphere you notice it will drift to the right side instead of rolling straight on the Z axis.

thanks

[AlexSilverman]

pico,

Thanks for the demo file. I looked it over and I don't see any place in that file where you are explicitly setting the collision normal. I typically apply the patch that I posted earlier (to apply the changes made to the btManifoldPoint in the ContactAddedCallback), then set the contact normal to the triangle normal in the ContactAddedCallback. This proces has produced noticable results for me in my projects. I tried this in your demo (by adding the normal setting code to the callback, and adding the CF_CUSTOM_MATERIAL_CALLBACK collision flag to the objects), and did not see any appreciable changes. I reread your posts and saw that you said the problem was best seen with no friction, so I changed the m_combinedFriction member of the btManifoldPoint to 0 inside the callback. When I did this, it completely removed any drift.

Next, I removed the code that sets the collision normal to the triangle normal, and the drift did not return. This leads me to believe that it is somehow related to the way the ground friction influences the ball, and not due to edge collisions. I seem to remember there being a post a while back about there being an irregularity in how the ground "grabs" a rolling sphere, that causes it to drift in just the way you've reproduced in this demo.

Let me know if you experience the same results.

Hope this helps.

- Alex

[pico]

Hi Alex,

currently i think its not to have friction or not to have friction but just how the sphere hits the edges. It's a matter of velocity and edge distribution.

When i prepared the demo i really needed some time to get a good test case. Changing some of the variables slightly can make everything look perfect again.
You just need to make the grid smaller or bigger and the behavior of the sphere will change because the edges will move.

[AlexSilverman]

Hi pico,

I have done some more looking at the demo, and I noticed what you're saying. I'm still curious why the removal of friction removed the drift, but I supose it's not related to this specific issue after all.

I'm not sure how else edges can influence a rolling sphere if the collision normals are always being explicitly set to the triangle normal, (0,1,0) in this case. I would think that this makes the fact that it's colliding with an edge largely transparent.

- Alex