I stated that there were some opensource applications that would do all of the collision for him, I suppose I got into the details too much and that went unnoticed. Some people are building an engine for a portfolio, in which case I don't see how plugging in some opensource middleware shows that you understand how engines work at their core.

Yes, I understand your position, but I think it was worth stressing this more. Maybe it's just me but I think the message completely got lost.
Yes, I understand this position very well. I still think it's not worth spending 6+ months on physics... because after 2 months, one will still be scratching the surface, I can tell for experience, and there's at least another few dudes around here that will agree.
Problem with physics is: unless you use it in creative ways, it's assumed to be there. Let's do the city-major comparison: who do you think will get more preference?

1. The mayor which spent $ on fixing and maintaining the sewers, ensuring no one gets flooded.
2. The mayor which spent $ on a new stadium.

Although many companies claim to "have interest in acquiring complete know-how in developing internal technologies to leverage our customer's potential" the truth I had to learn in the hard way is they don't even have the means to evaluate this property. Therefore, the more you bring them, the better.

You state that having multiple BV's will be hard for the compiler to optimize, could you please give more detail about this? I'm assuming you are thinking of a game in c++, but even for my javascript engine im curious.

Yes, it's C++ related. The idea is that stronger assumptions give faster code. For JS, all bets are off as this is implementation dependent at best but in case of JS in Unity, they claim not messing up with type can produce faster code. I look forward to your JS-based project!

If you are trying to make a fps where picking has to be 100% accurate then OBB's may not be enough.

Probably need to elaborate on this. A thing is the broadphase, a thing is the narrowphase. AABB based broadphase has proven to be good enough. The goal of the broadphase is to be a fast rejection test, and AABB has demonstrated to be the fastest test around.
The narrowphase later takes all the potential collisions and resolves them in detail by computing "collision distances", this data is also used to improve stability as far as I've understood. The narrowphase uses solid's effective "shape". Most of the time, this is already a rough approximation. Personally I think convex hulls are the real deal, but Bullet also allows to resolve narrowphase collisions using generic meshes. Their performance seems to be really bad but that's what we get for accurate per-triangle collision.

There's nothing really wrong about what you're doing as far as I know, it's just pre-2003 collision detection, it worked well and can still work; I am surprised you pulled this out in 2 months but if it works for you, that's just great.

I have read Real-Time Rendering's chapters on collision detection, I have Ericson's Real Time Collision Detection, and I have Eberly's 3D Game Engine Architecture. Either I missed something or I am using outdated resources. Some of the techniques you are talking about are the first I've heard of them.

I thought it went

Sphere -> AABB -> K-DOP -> OBB -> Triangle

I don't know about the 3rd edition of RTR but the 1st edition definitely cuts short on CD&R... it's only 20 pages (+ the chapters dealing with intersection methods). I've only skimmed through Eberly's by means of inter-library sharing and I don't remember much. Those tests are incrementally more accurate but I never intended them as being "nested", I always considered those to be one or another. AFAIK Unreal Tech decided to go with AABB or K-DOP. I suppose they're using one or the other, I don't think they "nest" the tests (although as I previously wrote, using a very gross grained test with a more accurate convex hull might eventually make sense in some situations).

Problem is, CD&R is really overlooked. Problems such as stability, tunneling, pre-emptive contact point generation, internal-edge issues, restitution, convex decomposition, framerate independant determinism... Don't even get me started on rigid body dynamics or destruction. I didn't know, or grossly overlooked them as well. That's why I embarked in trying to make it work by myself. If I knew that from beginning, I would have just used middleware.
On the pro side, it is possible to do CD without considering those issues... as long as the world is kept simple and the framerate is high enough. But let's make this clear: it's far from being a "complete" CD system as there are nowadays. This does not imply it will be insufficient, but I feel the need to make sure everybody has a clear understanding of the limitations.

You said that AABB are proven to be the fastest. Having to update AABB's under rotation was the factor that drove me away from them, but if you say they are best then I will add more support for them in my engine. You are actually the first person I've ever seen claim that a certain BV is best, do you have any resources or data on this?

I have googled a while for the 'academical' papers, but didin't find them. They were too many years ago. Anyway, if you just download Bullet, you'll see [font="Courier New"]btDbvtBroadphase [/font]is AABB based. Furthermore, [font="Courier New"]btGhostObject [/font]reports potential collisions by AABB. Check out Bullet Broadphase, it will probably help you!
It is my understanding all broadphase algorithms used in bullet resolve potential collision pairs in the broadphase by the means of AABB only... perhaps they don't even rotate (what's going on isn't quite crystal clear to me, I've just searched the forums). This however is for broadphase.
Narrowphase must go by using a more accurate test. In case of bullet that's the actual shape used. By application's point of view, that's already an approximation: in narrowphase, AABB is just way too gross-grained to be useful at all. I actually allow only spheres, OBB and convex hulls.

Are you sure there are no physics libraries ready to go for JS? It seems box2d has a port even to flash... but in case you need to do that, just don't even think about fetching to the physics the same assets you mangle for graphics, if 3D that's probably going to take you to performance hell in no time.

Dark, what you said is correct. I think you're just trying to be accurate, which is good. But getting stuff done faster is better!