Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Physics Engines  (Read 5919 times)
0 Members and 1 Guest are viewing this topic.
Offline ShannonSmith
« Posted 2011-02-03 19:25:18 »

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.

Any other Open Sources engines I am unaware of?
Offline Mike

JGO Wizard


Medals: 83
Projects: 1
Exp: 6 years


Java guru wanabee


« Reply #1 - Posted 2011-02-03 19:28:51 »

Is it 2D or 3D? If the former, did you have a look at Phys2D?

My current game, Minecraft meets Farmville and goes online Smiley
State of Fortune | Discussion thread @ JGO
Offline ShannonSmith
« Reply #2 - Posted 2011-02-03 19:37:08 »

3D unfortunately, physics in 2D is much much easier. Damn quaternions and inertia tensors.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DzzD
« Reply #3 - Posted 2011-02-04 10:35:38 »

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.

I ve used such engine in the following demo/game and it give good satisfaction for now :
http://demo.dzzd.net/SIMCA1000/
http://vor-2.com/

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

[size=8pt]I would have happily OS the lastest refactored version of this engine but I am unfortunatly not allowed to do that [/size]

Offline ShannonSmith
« Reply #4 - Posted 2011-02-04 17:17:54 »

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.

Offline DzzD
« Reply #5 - Posted 2011-02-04 17:59:05 »

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.

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 Smiley )

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

Offline jezek2
« Reply #6 - Posted 2011-02-04 19:23:59 »

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.
Offline ShannonSmith
« Reply #7 - Posted 2011-02-04 19:43:55 »

Hey jezek2 are you still working on JBullet, I really wanted to use it but there were a few things that stopped me:

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?

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.

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.


Offline DzzD
« Reply #8 - Posted 2011-02-04 19:59:22 »

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...
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

Offline DzzD
« Reply #9 - Posted 2011-02-04 20:01:17 »

thanks for the link :  "newtonian particles with distance constraints" sounds a lot better than "Verlet Integration" ...

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jezek2
« Reply #10 - Posted 2011-02-04 20:27:46 »

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...
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 Smiley

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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!