Find the colliding plane

I'm a bit confused, about what exactly you're trying to do. With the wall sliding stuff, it sounds like you have an FPS-like setting. This kind of games normally uses cylinder vs. plane/polygon tests to do wall collisions. Using OBBs as walls would waste a quite bit of performance when a simple plane check could achieve the same thing, and the other way around, using an OBB for the player, might cause him to get stuck in tight rooms :)

Anyway, assuming you're testing sphere or cylinder against an OBB, I'd say you could simply check the sphere's or cylinder's center against the 6 planes formed by the OBB's faces, maybe using a closest-point-on-plane method to find out which OBB face is the most relevant in case the you're not directly above one of the faces of the OBB.

There is a lot of good code for checking all kinds of geometric shapes against each other to be found here:
Geometric Tools: Intersection Algorithms
The author of that library, Dave Eberly, also frequents the gamedev.net forums :)

I am looking for something that would be like first person or third person collisions, i was going to use OOB vs OOB to find the collisions. If i was to go with a Cylinder vs plane or OBB vs Plane, I'm not quite sure how I'm not quite sure how I'm supposed to be producing planes for things such as rocks. I only need box or sphere collisions but the character will need to collide and slide on them right? This is the stuff I'm a little confused about because I don't quite understand how the collision is with a plane if the object has a fixed size and is not infinite.

Any insight would be awesome
thanks

If the rocks are models, you would either need a mesh <-> cylinder/obb query for those or use a simplified representation or the model for collision detection.

There are probably quite a few methods to approach this problem, but this is how I know it from the games I've worked on:

Any actor's (players, monsters and npcs) collision shape for movement is essentially a cylinder or several cylinders stacked on top of each other (to allow for a smaller head and feet radius, for example). As has been said, this has the advantage that you don't need to do any collision checks when the player turns (which might irritate most fps players -- when was the last time you couldn't turn around in DooM3 because your weapon clanged against a wall?).

Indoor levels are basically made out of large, flat walls that a decorated with static meshes such as pipes, lamps, machinery or whatever). For the editor-built flat walls, plane checks are sufficient. The static meshes require a special mesh intersection check (meshes are often called polyhedron in collision detection terminology), typically done only when the player enters a meshes bounding box.

Outdoor levels (aka terrain) are normally based on a heightmap or TIN, both of which lend themselfes to the same plane checks since there are a lot of flat, simple faces. Objects on the terrain such as rocks or trees again are static meshes (static in the sense of not moving around) that require a seperate mesh intersection check.

In C++, popular choices for all these intersection checks were Opcode and Bullet. I don't know of any good equivalent for XNA yet, but I'm hoping that Visual Architect 3D or Blade 3D will alleviate this situation as their functionality require such a feature. Until then, it's all pretty much do-it-yourself-land :o)

Maybe I'm misunderstanding or not being clear enough. I have intersection checks which are sufficient enough for the purposes of my game. The problem is after i perform the intersection, how do I resolve the collision through sliding. If i just collide with planes will i not potentially have multiple collisions with planes that i do not want to collide with because a plane extends to infinity?

I'm just saying planes all along because that's the basic test you'd be doing for the walls and floors in a simple FPS game. Of course, when a collision against a plane is reported, you still need to see whether the point of impact lies within the area the wall is located at.

Just like triangle intersection tests are also usually based on a plane <> something test that calculates the point of first contact against the triangle's plane and then looks whether this point is inside the triangle.

Oh I see, thats cool thanks. Was a little lost there.
Cheers