Thanks for the hint.
My singleRayTest() now looks like this:
// replace collision shape so that callback can determine the triangle
if (!recursive) s_lock->Lock();
btCollisionShape* saveCollisionShape = collisionObject->getCollisionShape();
if (!recursive) s_lock->Unlock();
That certainly gets rid of any crash, but it does end up in some kind of dead lock after a while, basically crawling to a halt.
Any idea what that could be about?
EDIT 1: The deadlock problem seems to be lessened by disabling the rayTestAccelerator, but generally the lock is quite bad for performance.
Not really sure yet how I will handle this. I'm reluctant to give up parallel processing of my particle systems altogether. I guess I make a thread-safe wrap around rayTest() on the application level, which I'll use from inside the particle systems.
Do you see any change coming in that area? Maybe I'm missing a detail that explains why this never will be a good idea.
Thanks for the feedback so far!
EDIT 2: In my case the easiest and fastest solution turns out to be creating a temporary collision object on the stack. No need for locking and at least 2x as fast in my test.
btCollisionObject stackObject = *collisionObject;
const btCompoundShape* compoundShape = static_cast<const btCompoundShape*>(collisionShape);
btTransform childTrans = compoundShape->getChildTransform(i);
const btCollisionShape* childCollisionShape = compoundShape->getChildShape(i);
btTransform childWorldTrans = colObjWorldTransform * childTrans;
I still think I'll end up with what I described above, though.
EDIT 3: I can only assume, that internalSetTemporaryCollisionShape is needed for the result-callback. Maybe it would help if object and shape would be separated there as well, like in singleRayTest. Or am I missing something?