New user with a problem & two questions

[stevenLD]

Our problem, which we've not yet reproduced in the demos (maybe tomorrow), is that we have two RigidBody objects with CompoundShape collision. One is non-moving, and the other is dropped from 10-meters directly above it. The moving object (either a sphere or cube) collides with the non-moving objects (also a sphere or cube), and appears that one vertex is colliding, but then it continues to push through (causing the system to really chug), and fall through the lower object.

1) Is there a global value somewhere that defines the collision penetration push-out distance (sorry for lack of a better term)?

2) What was the last most-stable build? Some of these versions are obviously more well-tested than others, and since we're working on a commercial game, we'd like to find a solid build to work from.

Any other general advice would be greatly appreciated.

PS: Last I checked (friday?) the doxygen documentation links on the Wiki page were invalid. "Error 404: file not found ./physics/bullet-docs.zip was not found on this server." I searched the FTP and found some older docs, but either way, just FYI.

[Erwin Coumans]

Our problem, which we've not yet reproduced in the demos (maybe tomorrow), is that we have two RigidBody objects with CompoundShape collision. One is non-moving, and the other is dropped from 10-meters directly above it. The moving object (either a sphere or cube) collides with the non-moving objects (also a sphere or cube), and appears that one vertex is colliding, but then it continues to push through (causing the system to really chug), and fall through the lower object.

If you can reproduce this, I can look at it. What timestep are you using, can you provide all arguments you pass into 'stepSimulation'?

1) Is there a global value somewhere that defines the collision penetration push-out distance (sorry for lack of a better term)?

I would not recommend starting tuning those internal settings. It would be best to read the Bullet_User_Manual.pdf, and if there are more questions/problems, just post them on the forum here.

2) What was the last most-stable build? Some of these versions are obviously more well-tested than others, and since we're working on a commercial game, we'd like to find a solid build to work from.
PS: Last I checked (friday?) the doxygen documentation links on the Wiki page were invalid. "Error 404: file not found ./physics/bullet-docs.zip was not found on this server." I searched the FTP and found some older docs, but either way, just FYI.

I would recommend using the latest Bullet 2.61, or if this gives problems Bullet 2.54.
Thanks for reporting the broken link, it has been fixed. Note you can also generate the documentation by downloading doxygen and graphviz, and running doxygen in the Bullet root folder.

Thanks,
Erwin

[stevenLD]

Thanks for the response. At the time, Bullet_User_Manual.pdf was the only documentation I had, so I've read it a few times. Whether I retained it all or not, thats another issue. Further testing today has led to further understanding:

It seems that creating a RigidBody actor with a non-zero mass and then setting the CF_STATIC_OBJECT flag (as it is a Collidable object, but not a Physics object) causes it process collision responses improperly. If, instead, we create the Collidable object with a mass of zero and don't set the STATIC flag then collision response works fine.

My question is, what is the proper use of the static flag? Should we use it at all or just create zero mass objects? Are zero mass objects as efficient in terms of spatial partitioning as static objects? What is the appropriate way to change an object from Physics to Collision-only, and vice versa?

Also, do you think the errored collisions with static, non-zero mass RigidBody objects with normal RigidBody objects is a result of something I did wrong, or is the system not designed to handle this situation?

Thanks again for your quick feedback; it's appreciated.


PS: I am just a junior programmer, but I wanted to mention something just to further my own understanding.
(using 2.61) btRigidBody.cpp
I noticed a bit of code that caught my eye. EXPERIMENTAL_JITTER_REMOVAL is enabled by default, which may or may not be intentional, but the first line of its code:
if (wantsSleeping())
is commented out. This gave rise to an error in our simulation; the quarter-speed timestep we were using for fine-tune debugging ended up triggering this code, and our objects were unaffected by gravity due to the anti-jitter dampening. Is the code, as it is, as it should be?