Ah! This is a similar problem that I am trying to solve. Currently, the implementation of collision masks is built on top of the existing masks in Bullet. In other words, it doesn’t interface with bullet directly. Bullet works something like this:
- Bullet checks the AABB intersection of the two objects. If they intersect, it calls a “needsBroadphaseCollision” callback before adding to a cache, then moves to a different collision callback.
- During this check, Daniel and Mitchell implemented the Blender collision masks, which are separate from the Bullet masks. To check for a collision between objects, it calls CheckCollision (KX_GameObject->CheckCollision) which returns the intersection between mask and group, and it calls this for each object in the collision pair.
- The outcome of these two callbacks overrides the outcome of the bullet filters, (which are bullet’s own mask and groups).
- If the collision is deemed True, it then adds the objects to the cache.
My problem for the patch is that changing the masks doesn’t take effect if a collision already occurs. This is because by this point the objects have been added to the broadphase cache, thus the CheckCollision method is no longer checked. To solve this, I believe I need to implement another callback, nearCollision or something to that name (it’s mentioned in the Bullet API) to continue to check the intersection.
I have some idea of where to start, but I need to learn a little more (hopefully with the support of Benoit) after initially consulting with Mitchell.
The reason that this is similar to your problem is mentioned in the source;
//Note that this is called during scene
// conversion, so we can't assume the KX_GameObject instances exist. This
// may make some objects erroneously collide on the first frame, but the
// alternative is to have them erroneously miss.
Essentially, after checking the bullet filters it checks the user masks (from Blender). Yet as the GameObjects do not exist, they cannot influence the very first collision check, thus any objects with intersecting bounding boxes on startup will collide (the same problem that may be fixed by a following callback). Hence, to solve your issue, isolate the bullet from the bounding box of the two planes.
In hindsight, It may be better to deny the collision if the two objects do not have masks yet (do not exist) for the implications of that would only last one physics tick. However, in solving this true issue in a later callback, it would really make little difference, thus it would only be a temporary fix. (assuming that this is called throughout the intersection of the bounds, otherwise its the same problem in reverse)
Temporary fix based upon assumption: