BroadPhase/NarrowPhase Order
pkusilence opened this issue · comments
With PhysX 3.4.0, in PVD thread profiler, we found that collision detection is excuted as:
- queue narrow phase (narrow phase A)
- simple AABB manager stuff (Broad Phase)
- queue narrow phase (narrow phase B - second pasee)
So I am curious why it looks like this. Is narrow phase A for those persistent contacts? If so, why should it be calculated before broad phase?
AABB pairs from last frame are likely to still collide this frame (high temporal coherence there) so you can start doing narrow phase on these previous pairs immediately, in parallel with the broad phase for the new frame.
AABB pairs from last frame are likely to still collide this frame (high temporal coherence there) so you can start doing narrow phase on these previous pairs immediately, in parallel with the broad phase for the new frame.
But for AABB pairs which lost touch, the narrow phase calculations seem to be unnecessary.
Sure, but the majority of them will still touch so overall this is a win. There are also AABB pairs out of the new broad phase for which narrow phase is unnecessary, it's not that different.
Thanks a lot. Have a nice day :D
Can we choose to merge these two narrow phase (persistent and new contacts)?
In such a case: a kinematic wall moves towards another static wall, and a simulated ball is pushed by the black one.
Now physx will report contact modification for ball twice, the first one is persistent contact for black wall, the later one is new contact with the blue wall. In this situation , we hope to disable the contact with the black wall since it is moving, and keep the blue wall contact valid. However, we can only find the ball got pressed both side in the second contact modification report, and cannot change any contact properties between ball and black wall.
Thank you, we'll check and get back to you. Internal tracking PX-4764
The collision detection narrow phase makes two passes: first for existing pairs of shapes, and second for new ones. This behavior cannot be changed.
What you could try though, is to increase the contact offset of the blue shape (PxShape::setContactOffset). This way (in theory) the red-blue contact should be generated before the shapes actually start colliding. And when they do, the red-blue pair should be already in the persistent list together with the red-black pair. But it's just my guess, I didn't try it.
What you could try though, is to increase the contact offset of the blue shape (PxShape::setContactOffset). This way (in theory) the red-blue contact should be generated before the shapes actually start colliding. And when they do, the red-blue pair should be already in the persistent list together with the red-black pair. But it's just my guess, I didn't try it.
Thanks for your reply. We decided to let the ball query against the blue wall after simulation, and the recover its transform if this case happens. If this method do not work well, then we can add a callback during contact desc generation to diable red-blue contact.
Have a nice day !