I like the sound of this. I also hope it weighs in at less than the 1.5mb that ammo.js does. It's about 1/3 the size of my entire project.
However, one decision really limits it's usefulness and that is .... "no possibility of any support for concave meshes without dividing objects into multiple convex shapes"
I have built levels before, both out of BSP (only convex shapes) and using traditional mesh-based, and I can tell you which is easier to use: mesh-based. Take for instance the room around you. It's concave because it's a room. To make a cube room from convex geometry takes six cubes instead of one. And most game levels are interior, or at least have interior parts.
Also consider this level:
It took two hours for a friend of mine to whip up this mesh. It would take another four to do BSP/convex-only geometry to match it.
From a technical standpoint, yes, convex only is simpler to implement, but the level designers and users will kill you. I don't mind if it doesn't support mesh-to-mesh collisions, but it should at least support sphere to mesh. In theory you only need one to be a primitive to resolve the direction of 'out' to resolve penetration.
All the other choices (speed over accuracy) I think is fine. Fun and performance over accuracy any day in my mind.
How do you use physics in games?
To make it real enough the player can associate with it. A player expects that if you drop an object, it will hit the floor. A player expects they will not be able to walk through walls.
In most games, there are maybe 4 types of physics 'objects.' The first is the player. Often a cylinder in FPS's, a sphere in my game, sometimes ragdolls etc. Next is the level. I often represent this is a single physics mesh at relatively low poly count Somtimes multiple if moving parts (eg doors) are required. Third are enemies. Normally the same representation as a player. Finally there are pickups. These are often modeled as spheres.
And that is how I use physics in-game. To make the interactions between these four classes of objects believable enough for players to be able to figure out the environment they are in.
How do you want to move your entities in the physics world? Forces? Kinematics
Both. Some things have set velocities, like bullets. Simulating that with forces would be a right pain. Other things you need to apply forces, such as the modion of a space-ship, or torques on wheels. TBH, the difference is very minor, one simply has mass and is applied iteratively.
The way I would implement is is two methods :
(actually four, repeated again for angular).
To fully constrain a system you need to be able to control position, velocity and acceleration. Position is self explanitory as is velocity. Acceleration is linked to mass and often applying force is more intuitive to a user who understands physics. Forces are real, accelerations are mathermatical artefacts.
Sorry, I'm not up to date on physics engines, but I know my way around math, linear algebra, calculas and control theory. It's been a couple years since I last wrote any heavy math programs though. If you want to bounce ideas at me, I can listen and offer advice, but I don't have the time or inclination at the moment to actually write a physics engine.
I know how useful it is to explain issues to another guy while you're working, and I'm happy to be the other guy.
Developing Test cases
This I can do.
Help in coding and debugging
Once the engine reaches a state which it can be tested, if it supports concave meshes, and it it is smaller/lighter/faster than ammo, I will leap on board and be happy to file bug-reports, find problems and maybe write a few lines. Or at least I'll give it a shot every month or two and give feedback.
Hmm. I suspect I'll be helping out in another physics engine in a year or two, so it probably isn't a bad idea to get my feet wet....