This project has moved and is read-only. For the latest updates, please go here.

Queries or best alternative

Topics: User Forum
Jul 3, 2009 at 4:00 PM

I seem to remember some discussion about FP v3.0 including support for queries. I imagine this as a way to ask the engine for all geometries intersecting with another geometry or AABB. Also I'd imagine it to include a way to filter the results by collision category or group or other properties. Am I on the right track here?

Since FP 3.0 is probably a while away yet, what would be the best way to achieve this with FP 2.1.1? My current ideas are

1) Iterate all geometries and call Collide(), and

2) Put all relevant geometries into a QuadTree structure and query that.

However, I think there must be a better way, perhaps utilising existing FP broadphase algorithms. Thanks in advance for your thoughts :)

Jul 3, 2009 at 11:44 PM

1) big no no. Calling Collide() on all geometries is an expensive operation. You would have to compare each geometry to the next (O(n^2)) and that is not good for performance.

2) Well, it is a possibility.


But, as you mentioned yourself, using the existing broadphase algorithms are way better. They are maintained my Farseer Physics and run on each update, so you might as well use them. The easiest way to use the broadphase algorithms is to create a sensor, but even that has a narrow phase algorithm to determine the exact location of the collision. Another alternative is to create a geometry and subscribe to the OnBroadPhaseCollision event on the broadphase and simply return false. You will use the broadphase algorithm and you skip all the overhead since you return false. Returning fall means that no arbiter will be created and thus no narrow phase will be run on the collided (or potentially collided) geometry.