...One of my favourite feature of (J)Bullet is convex sweep test, it allows to precisely detect collision without need to iterate. I use it in my game for FPS character controller for walking on arbitrary terrain and sliding along walls...
not sure I exacly understand the point here, I mean collision detection have nothing to do with physics in what I ve used (for example the car demo I posted above) use collision detection as you describe above without any iteration (for each sphere used in the physic system) but the physic computation (force applyed to sphere for next step) is computed separatly than the colision, I am more understanding sphere+link as a nice features / shortcut to add multiple forces to a single objet and compute easily the final motion of this object (rotation+translation).
Yeah, you're right and I realized it after posting. You can for sure retrofit rigidbody mechanics to verlet physics. On the other side the collision detection portion is a major part (and not that trivial because of many combinations problem) of existing physics engines. In (J)Bullet I like that the convex shapes collision is generalized and doesn't need collision detection routine for every combination of shapes (but it still provides them for the common combinations for optimization).
Hey jezek2 are you still working on JBullet, I really wanted to use it but there were a few things that stopped me:
Yes, working on it from time to time. JBullet is in "stable" stage, that means we're happily using it in production
1) Doesn't seem to work with small scales (I want to work with cm sized objects using metre units). I could scale everything but it would be a huge pain. It seems some of BulletGlobals could fix this but they are final, was there a good reason for this?
This is problem of approximations and things like default collision margins. You can tweak these on per rigid body basis and in other places (eg. simulation frequency, iteration count of constraint solver, etc.). In BulletGlobals I see only CONVEX_DISTANCE_MARGIN constant which is used only on two places (for specifying default margin and for some inertia computation which shouldn't affect that much and you can compute it yourself). Try searching the
Bullet forum, there are also some articles about it on
Wiki, like this:
Scaling The World.
2) vecmath.jar, ug... It would have meant 3 different vecmath libraries in my project. I say keep all math utility classes internal and allow float[] set/get.
This is mostly Sun's fault by not having standard API for vecmath directly in JRE. The Sun's vecmath API is as closest to this + I haven't seen significantly better API anyway and not for reasons for not trying. In most usages you convert between your representation and physics anyway so I don't think that such additional methods are really needed, it would bloat the API.
3) Rotational motion looks off, is it being integrated correctly? Eg, in your vehicle demo you can get it spinning corner over corner which shouldn't be possible with that shape.
Vehicle is special purpose simulation to aid computational speed and other characteristics and it doesn't use normal physics calculation. The actual shapes of wheels are not present in the world and the position/rotation of chassis is bypassing normal simulation. You can create car using ordinary rigid bodies, it should behave more consistently then. But there are also issues with highspeed motion vs wheels due to discrete collision detection.
