lunkhound wrote:
No, I'm not talking about dynamics, I'm talking specifically about the use-case you have described where you are using the collision world to detect intersections between a group of perception spheres and potentially visible objects.
The reason I say they "don't need to be there" is because they don't -- a more efficient way of doing things would be to have the collision world contain just the objects, and then for each perception sphere, do a broadphase query to generate a list of the objects it intersects. That would directly generate the results you are after -- for each perception sphere, a list of potentially visible objects -- without having Bullet do all that extra work you don't need.
You shouldn't be having Bullet generate manifolds -- the manifolds are there for supporting dynamics -- if all you care about is whether the perception sphere intersects with an object or not, then having bullet calculate all of that stuff (like deepest penetration, contact points, normals, etc) is all wasted effort.
I completely agree that Bullet is computing things I don't need. That's why I'm saying Bullet Collision is torn between its "collision" library and its "dynamics" library. Collision library is in fact already a bit of a dynamics library.
But I just don't have a better option.
1. Broadphase vs narrowphase : I need narrowphase.
The broadphase collision yields me AABB detection.
The narrowphase yields me physically accurate collisions.
So your suggestion isn't enough. I need to perform narrowphase collision. I cannot use only a broadphase query. And the narrowphase algorithms do generate contact points, normals, etc... I'm not gonna write them, so I'll use the ones from bullet. So again what alternative do I have to computing manifolds ?
2. What you suggest is to brute-force recompute everything each frame. But I need persistence. So your solution would have to include coding a kind of persistence for contacts. That means recoding large parts of what bullet already does, again.
How do you propose a simple solution for persistent contacts ?
One option is writing my own custom broadphase, using the persistent contacts Bullet already has, but it doesn't solve your criticism about computing unneeded physical specifics in the narrowphase.
3. Given that I need persistence, I trust Bullet is much more intelligent than me to efficiently recompute collisions when something in the world has moved / changed.
Recoding everything myself will have an overhead compared to my present solution, because I'm not experienced in this kind of optimization.
So on one hand, I have the solution of using bullet system as-is, it works great, performs well, and has a slight overhead that you mention. And on the other hand, I have the option of doing a lot of stuff manually, not even being sure that the system I'll come up with will be that more efficient than bullet's broadphase / narrowphase is already doing.
So the bottom line for me, you've probably heard that saying about premature optimization. I'm not gonna rewrite all this stuff until it proves to be a serious bottleneck of my game.
N0vember wrote:
The broadphase is really just an acceleration structure to quickly find all possible pairs of overlapping bounding-boxes. The collision masks are only checked AFTER the broadphase has detected an overlap. The collision masks are there to filter out interactions between objects before they enter the narrowphase (which tends to be much more expensive). So collision masks won't save you any work in the broadphase, but they are totally worth it for all of the narrowphase work they can save.
I don't see any conflict here. Bullet collision is perfectly capable of handling all sorts of collision queries efficiently. However, it is easy to use the collision in a suboptimal way, causing lots of unwanted dynamics oriented work (like the creation of manifolds and such) to take place.
Okay. I thought collision masks played a role in the broadphase.
Nonetheless, your point seems to be that, having hundreds of spheres, and about as many hundreds of objects colliding with these spheres.
-Doing one broadphase query per sphere each frame, and then computing the narrowphase "manually" on the results.
vs.
-Have bullet handle all these collisions in the broadphase itself, handle persistence, and notify me of new / removed collisions.
You are saying that the second option is gonna be substantially worse in terms of performances.
As far as I can tell, I may do better than the broadphase because I'll do only one AABB query where Bullet is doing maybe 5-10 useless ones (between the spheres).
But that means the overhead of my current solution is not at all in the narrowphase and the manifolds, but only in the broadphase.