Has anyone had much experience using the various physics engines available? I am after something rather specific and looking at various options. I want a rigid body simulation of very few objects (probably just 1) very stable and high precision, especially rotational motion. I’ve tried a few engines but not in depth and I thought I would canvas for opinions.
bullet - Rotational motion looks unrealistic and collisions seem a bit chaotic but I haven’t played with it too much so it may just need the right settings. Good Java port available.
ode - Rotational motion looks a bit better but seems quite unstable and hasn’t been updated in a long time. Java binding using jni available.
Has anyone tried Tokamak, it’s c++ but looks like a nice clean small API and I would consider a port if it works well.
I usually build my own when needing a physic engine (so it can fit my requierement without unnecessary things) and find that “sphere” linked by “spring”, sometime called “Verlet Integration” ( wich is IMHO a little abusive call for this ) work well in most cases ( and enable more things like going from one fluid to another with different density air/water with pretty realistic physic reaction ) .
This is not really hard to implement even from scratch and respect a lot of physic laws, it precision can be adjusted just by adding more entity to the system.
the principle is simple, apply a Force/Impulse on each sphere then displace it in a 3D environment performing collision, rebound, fluid deceleration, or anything you like to in the 3D environment then apply constraints based on length between linked sphere
this requiere only three classes to be implemented :
physic entity: defined by a 3d location, a mass & a current 3d velocity
physic link : defined by a default distance between two sphere and a strengh constant
physic system : defined by a cupple of those previous physic entities & physic links
I would have happily OS the lastest refactored version of this engine but I am unfortunatly not allowed to do that
Verlet physics works great for many cases and is super simple and stable but it tends (in my experience) to do very poorly at correct rotational motion in 3D. It is very hard to approximate the mass distribution of complex shapes using just spheres and in order to get the system stable you need to heavily dampen everything killing realistic rotational motion.
I found a new port for ODE (ode4j) that seems quite good if a little painful to use (very 1:1 mapping of a C api). The best thing is it doesn’t depend on anything else which is something that really bugs me about many libraries. If you want your library to be popular you need to impose an absolute minimum set of integration requirements. Pulpcore for example is a great library but imposing your own build/deployment system just kills the uptake.
[quote]Verlet physics works great for many cases and is super simple and stable but it tends (in my experience) to do very poorly at correct rotational motion in 3D. It is very hard to approximate the mass distribution of complex shapes using just spheres and in order to get the system stable you need to heavily dampen everything killing realistic rotational motion.
[/quote]
Verlet physics is usually quite precise ( for example according to wikipedia and other internet ressource (may be wrong inded) it seems to also be used to compute molecular trajectory) that why I say sphere linked by spring is not necessarily/really “Verlet physic”, but I would say that the way you compute how the sphere move is. for example : in the engine I built I am using Newton forces / Impulse / Moment etc… wich is not necessary in common Verlet physic engine. but to be true I dont really know )
anyway using spheres+links (Verlet or not ?), the rotations have always working fine for me, strange that you encounter trouble, are you sure problems was really comming from “Verlet” itself ? (not that in my case I keep trace of the moment (mass & velocity))
for stability here is what I do : recompute the frame of reference (local axis) for the whole system and replace each sphere to its original location in this local space (but keep trace of moment for each sphere), doing that for each physic simulation step make the system absolutly stable / unbreakable
Verlet physics is nice and simple idea and I recommend to experiment with that to anyone wishing working with physics. It can also do things such as ragdolls pretty cheaply, though with different means. And cool cloths simulations. Nice article about it at Wolfire: http://legacy.wolfire.com/rotationconstraintpaper/paper.html
However sometimes you need real rigid body simulation with full collision detection based on shapes and various constraints attached to arbitrary attachment frames, both areas that are quite weak/impossible in verlet physics. 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.
Hey jezek2 are you still working on JBullet, I really wanted to use it but there were a few things that stopped me:
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?
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.
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.
[quote]…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…
[/quote]
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).
ps : I ve started to thing of an extension of such system (sphere+link) based on a dynamic generation of the system at each physic simulation step rather than a fixed system at startup : each physic step will use different system (regenerate a better fiting sphere+link system) (at each contacts/colision points for example), not sure is is easily doable but it maybe an interresting way to explore
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).
[/quote]
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).
Yes, working on it from time to time. JBullet is in “stable” stage, that means we’re happily using it in production
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.
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.
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.
)