Change in GIMPACT support?

[peltonen]

Hi,
I have been using Bullet with Gimpact for collision detection. Up until recently, things have worked really well. But now the version of Bullet in the repository (1422) no longer builds the GIMPACT library (i.e. libGIMPACT.lib or libGIMPACT.a). I tried this on two different machines under both Windows and Linux.
On my project, without the Gimpact library, collision detection of trimeshes doesn't work very well. The code still compiles and runs just fine, but the collision detection isn't all that solid (e.g. objects interpenetrate quite frequently).
Did something change with how Gimpact is built when it was upgraded to 0.3? I know the directory was moved, but is there a reason why it is not being built?
Is there a parameter to set to make sure that libGimpact is built?
Thanks,
Brian

[Erwin Coumans]

There should be no change in Gimpact support. The library has been merged with BulletCollision, so there is no separate Gimpact library anymore.

Have you tried using the Gimpact as part of BulletCollision in the latest trunk? What is the problem with the trunk exactly?

Thanks for the feedback,
Erwin

[peltonen]

Ah... OK. That makes sense. In my project, I removed libGIMPACT from the libs folder and the link to it in the makefile.

[Update]
When I run it now, I'm getting the collision detection errors I mentioned in my first post. Trimesh objects are really interpenetrating each other. It reminds me of the behavior I saw before switching over to Gimpact.

With Gimpact 0.2, trimesh interactions looked great.

Is there something, like a flag maybe, that needs to be set to make sure that Gimpact is being used for collision?

Thanks!

[Erwin Coumans]

Which version of Bullet did you use, with a working Gimpact (I'm not familiar with Gimpact numbering, please stick with Bullet version numbers). Can you reproduce it in a Bullet demo?

Can you try to enable the define BULLET_TRIANGLE_COLLISION in src\BulletCollision\Gimpact\btGImpactCollisionAlgorithm.h, and/or increase collision margin (setMargin) and see if that helps?

Latest trunk of Bullet has the same Gimpact as Bullet 2.72. Did the Extras/Gimpact from Bullet 2.72 work for you?
Thanks,
Erwin

[peltonen]

I found the source of the problem. The instabilities I'm seeing are caused by splitImpulse.

If I set m_dynamicsWorld->getSolverInfo().m_splitImpulse to "true", that causes objects to interpenetrate and act "mushy". As a demonstration, I modified GimpactTestDemo so that it now has a large tower of boxes. When splitImpulse is set to "false", the tower bounces a little bit, then settles into its resting position and all boxes are deactivated. If it is set to "true", the boxes start to squish down into one another and the ground, causing the tower to topple.

The code I am working off of is revision 1507 in the repository. I included a demo that I built by modifying GimpactTestDemo.

Thanks for looking at this! Apologies for the slow response.

p.s. According to the ChangeLog, Bullet upgraded to Gimpact version 0.3 (from 0.2) on September 28th (which would be somewhere around revision 1430).

[sparkprime]

If I set m_dynamicsWorld->getSolverInfo().m_splitImpulse to "true", that causes objects to interpenetrate and act "mushy". As a demonstration, I modified GimpactTestDemo so that it now has a large tower of boxes. When splitImpulse is set to "false", the tower bounces a little bit, then settles into its resting position and all boxes are deactivated. If it is set to "true", the boxes start to squish down into one another and the ground, causing the tower to topple.

I've seen that behaviour with stacks of boxes and split impulse too. Nothing to do with gimpact I think. I actually don't know what split impulse does but the simulation has always been less accurate with it turned on

"mushy" is a good word to describe it

[peltonen]

Split impulse is a great feature. If you have two objects that overlap, without split impulse, the objects can fly off in different directions (due to the force of the spring used to separate them). With split impulse, once the objects are separated, they don't carry any of the momentum caused by the spring.

[sparkprime]

It's good to finally know what it is, maybe you could write something for the wiki?

[mirat]

I have the same problem: I've updated to bullet 2.73 and GIMPACT meshes won't collide now. Extras/Gimpact from Bullet 2.72 worked fine.

Setting splitImpulse to true or false has no effect. trimesh objects just penetrate each other. I'll try to change BULLET_TRIANGLE_COLLISION or margin now.

[mirat]

oops, it's my trouble. I've been linking my project with libGIMPACT

But I have another problem. When collision occurs (missle with spaceship), I destroythe missle by removing it from the world and using "delete" operator on rigidbody. But then I get a segmentation fault in btGImpactCollisionAlgoritm::gimpact_vs_shape() while next world simulation step. It seems that some manifold points pointing to missle are not erased from proxies and updating causes attempting to access missle (deleted). Has anybody met with such problem?

[added]
gContactAddedCallback is bad, use btGhostObject instead.