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.
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 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?
- The mayor which spent $ on fixing and maintaining the sewers, ensuring no one gets flooded.
- The mayor which spent $ on a new stadium.
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!
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.
If you are trying to make a fps where picking has to be 100% accurate then OBB's may not be enough.
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.