Feature Request: Query for Colliders

Apr 28, 2009 at 4:38 PM
I have a feature request for I*Collider, which it to be able to query for collisions against an AABB or Geom not inserted into the world.  This would help with doing things like pathing around physical objects or for AI queries for near by obsicles to avoid.  Although you can do this with Rays, it would be nicer if I could actually get some granularity.

Any possability of this being implemented?
Apr 28, 2009 at 7:31 PM
Im not sure what you meenn but cant you jus set the IsSensor bool in th egeom class to true or something?
It will become static and it wont apply impulses on collisions but it will be able to read collisions.
Apr 28, 2009 at 7:40 PM
Not sure that would work.  That would tell me when something collided with the sensor, but not the current state of the simulation.  I don't want to add sensor Geoms all over the world to create my pathing grid, then remove them.  Why can't I just query the current state?
Coordinator
Apr 28, 2009 at 9:17 PM
Edited Apr 28, 2009 at 9:19 PM
Physics engines are not really the tool for AI in the first place. But beside of that, I'm wondering why you would not add the geometry to be checked, into the world.

All the colliders (broad phase colliders) check against the physicssimulator geometry list. It is possible to add a second list that contains all the geometries not inserted into the physicssimulator, but then again, you might aswell just use the physicssimulator list.
If it is for performance reasons, you could just set the geometry to be a sensor. That would disable all the physics, but still include the geometry in the collision detection. Essentially the same as having it outside the physics world, but still include it in the colliders.

Edit: Just some info for those who might read this thread. You can create geometries and check if they collide with each other, without adding them to the physics simulator. They can work without the physics simulator, but they will not be included in the broad phase. This can hurt performance if you have a lot of geometries.
Apr 28, 2009 at 9:34 PM
Example from Angel, which uses Box2D  to query for objects in the physics engine to create it's path grid.  It first queries the AABB system to figure out how many objects it could possibly collide with in the broad phase, then queries only those for a narrow phase collision.  It uses this information to create blocked and unblocked nodes for its pathing system.
   
    b2AABB physBounds;
    physBounds.lowerBound = b2Vec2( bbox.Min.X, bbox.Min.Y );
    physBounds.upperBound = b2Vec2( bbox.Max.X, bbox.Max.Y );
    static b2Shape* tempShapes[maxShapeCount];

    int numBroadphase = box2D.Query( physBounds, tempShapes, maxShapeCount );

    //No bodies here
    if( numBroadphase == 0 )
        return false;

    // Code removed, Set up the shape's bounds which is determined by the size of the grid and the
   // current granularity we're looking at.

    b2BodyDef fakeBodyDef;
    fakeBodyDef.position.Set(0.0f, 0.0f );
    b2Body* fakeBody = box2DWirkd.CreateBody(&fakeBodyDef);
    b2Shape* shapeBounds = fakeBody->CreateShape( &shapeBoundsDef );

    for( int i = 0; i < numBroadphase; i++ )
    {
        b2Shape* pSh = tempShapes[i];
        b2PolygonShape* pPolyShape = (b2PolygonShape*)pSh;

        b2Manifold m0;
        b2CollidePolygons(&m0, (b2PolygonShape*)shapeBounds, fakeBody->GetXForm(), pPolyShape, pPolyShape->GetBody()->GetXForm());

        if( m0.pointCount > 0 )
        {
            return true;    
        }
    }

In Farseer, you have multiple possible colliders, which are optimized to do collision in different ways.  So being able to use an optimized collision system to do something like this:

    AABB bounds = new AABB(/* set up bounds */);
    Geom gridGeom = /* Create and set up a fake geom which is the size and granularity of my pathing grid */

    Geom[] possibleCollisions = PhysicsSimulator.BroadPhaseCollider.Query(bounds);
    foreach(Geom possible in possibleCollisions)
    {
        if(gridGeom.Collide(possible)
            return true;  
    }

Would be rediculously helpful.
Nov 18, 2009 at 8:16 PM

Not to resurrect the dead or anything, but I've been working on implementing geometry-aware path finding nodes via FarSeer, and agree with fuzzybinary: having a Query() method would be significantly nicer than needing to drop all of the nodes into the simulator and then deal with the overhead they introduce to the collision code. While the situation is somewhat mitigated by setting IsSensor=true on those nodes and then overriding OnBroadphaseCollision() when dealing with static navigation grids, it would be really nice to have a way to query for broad phase collisions on objects not within the physics simulator list. 

I realize it's on the edge of the "physics sim" part of the use case for FS, but I'm not sure that I can see an elegant alternative that would somehow allow for the efficient functionality of checking for blocked nodes outside of the FS classes themselves. I suspect that's why the Box2D guys went with the Query() method, and it's important enough that it seems like a natural fit within FarSeer.

Coordinator
Nov 19, 2009 at 2:59 PM

Farseer Physics Engine 3.0 includes the broad phase from Box2D and thus you will have the Query() functionality once it is released. The reason we don't have the Query functionality in the current version of FPE is that we have several broad phase algorithms and they all work in their own way. To implement something like a query would make the implementation a lot more complex (we strive for simplicity in 2.x) and I simple don't have the time to implement query in all the algorithms.

FPE 3.0 only have a single broad phase and thus it can be a lot more optimized (specialized) and I don't have to maintain 4-5 different implementations. If someone wants to take up the challenge of implementing query in the broad phase algorithms, I would be more than happy to take a look at it and include it in the 2.x source tree.