Perhaps it is just me, but I think this thread has gone so wrong it's hard to believe.

I have a little terrain (maybe like 100 x 100 meters) with some trees, houses, rocks etc. The player moves around this little map and I need collistion detection against the objects and picking ... what could be a good and simple (!) approach to solve my collision detection/picking?

Simplest solution: use a collision detection library. Such as Bullet or PhysX (I'm currently using the former).
In particular, note that Bullet uses allows different kinds of broadphase tests, one of those is an AABB tree. None seem to use OBB. AABB rejection tests, simply put, is so fast it greatly compensates the loss of precision. This behavior emerged in various other papers.

Bullet can do the CD&R for you in a large array of cases. In principle, collision detection between static and dynamic objects become essentially transparent to the application. Kinematic objects however are not transparent by definition. You will need to write the glue and this glue will be application-dependent.

Picking is pretty much supported in Bullet by using ray casting and it's both fairly flexible and accurate. I haven't looked at the performance of this functionality yet, but from a 10,000ft view, it seems promising. PhysX also supports raycasting AFAIK.

In both cases you'll need to go a bit through the hoops to link bullet collision objects to your gameplay-specific entities. In some pathological cases, this can be a bit troublesome (but it's probably an unfortunate byproduct of my current design).

Some objects are rotated (for example some houses) and for these objects an AABB would be pretty bad.

In this case you would fetch the physics API with a different Collision shape. No need to mess up with different representation. In case of Bullet, you could eventually encode this as an opaque blob (although I don't suggest to do that). You have prenty of collision shapes available including heighfield and convex hull. Want to be really accurate? Gimpact trimeshes will do.

What do you think about this: All my scene objects return a polymorphic bounding volume object, which can be a sphere or AABB or OBB. For most of the objects I return an AABB and for the rotated houses I return an OBB. Good/bad idea?

Probably bad in most naive implementations. Bullet does this under the hood but in some seriously elaborated way - AFAIK it's basically doing all the "casts" in advance to select an algorithm for accurate collision, then dispatch. Broadpase is probably AABB or OBB at best.

DarkBouncer, what you write about this is correct in line of principle - this info must be stored somewhere - but devil is in the details and what you seem to suggest has the potential to make this performance critical path more difficult to optimize by the compiler. Therefore, I'd avoid it.

I also thought about a 2 pass system: All objects return an AABB and only if the player partially overlaps with the AABB, I make an OBB test.

Nonsense. If the rough collision test matches, I don't think it's worth doing another fast-rejection test which 1) is not so fast 2) it's going to likely fail. Do yourself a favour: optimize your life instead, get the job done and use a physics API!

DarkBouncer, what you said is not standard design. Standard design is to perform a fast rejection test, if that fails, work it out in detail, perhaps using some kind of data structure to accelerate the whole thing. Stacking multiple gross-grained tests is not standard at best. If the nested test would be a convex hull I could understand, but sphere to box? It's like multiplying two random numbers together and claim better randomness, or encrypting data twice using two algorithms and claim the result is more hacker-resistant.

Do you think its ok to just linearly iterate over all my scene objects and just test every object with the player? (I guess I have around 50 objects)[/quote]I suppose it could be doable for 50 objects (I guess you have a iSomething processor) but don't expect this to last long.

And who should be responsible for building the BVH? Currently I am only telling the scene manager: place this tree at this position, this stone here and so on. I guess computing a good BVH automatically by the engine is not that trivial, is it?

The physics API. And trust me, it will dispatch fairly better than you.

If you want a well done collision detection system with picking you are looking at having to implement the following...
Don't get discouraged though, it's all doable, just trying to share my experiences to give you some insight into what lies ahead.

You are sadistic. Look, I really understand you want to share the pain but seriously, I don't see any reason to not use a physics API such as Bullet. If I look back I see myself scratching my head to the brains working on CD&R. Why didn't I go for Bullet a couple of years ago? Why did I do that to myself? Why do you want to do this to someone other?

Another question: Would you recommend using the same structures for collision/detection and culling? For example is it a good idea to make collision/detection AND culling just based on bounding volumes on the objects. Or is it better to use bounding volumes for collision/picking and some other structure (cells, quadtree) for culling?

You can use the same structure, but it must be built differently (at best) as the granularity involved need to be much different. Consider that even if you have 1k unique vertices per leaf, this is still very little for anything that is at least GeForce 4 (not 400 series, 4). Regardless of the data structure you use, unless you're doing AAA+ it will start to be pretty much the same thing as a linear scan once the leafs hold thousands, if not tens of thousands primitives.

If you use a physics API then I suggest to just build your system independently, the accuracy of physics API is just way overkill for culling on modern hardware.