So,
With the latest checkin of the JBullet integration, it's kinda become clear to me that I'm in a bit of a "hurry up and wait" mode with JBullet. There's still a few bugs I know of (odd force/torque application problems, materials properties un-mapped) but there's also a bunch of features that JBullet just doesn't have at the moment, and may not for quite some time. (Joint motors, certain joint types, breakable joints, ContinuousDynamicsWorld and a few other key features that make the Bullet Physics library so nifty.)
So, I kinda forsee the pace of development on this JBullet integration slowing significantly, since it will continue to have some big gaps for the forseeable future. Don't get me wrong. You guys pipe up with bugs, questions and/or problems, I'll gladly help out, but I'm convinced that this JBullet implementation is going to be a bit ugly for a while.
That said, I'm kinda chomping at the bit to really get into another physics implementation, though it'll likely require native bindings. shudder I do better when I'm multi-tasking and can switch my attention from one set of problems to another when I need a break.
Given that situation and my short attention span, I guess my question is . . . which engine do people want to see implemented? And does anybody care if I take a stab at it while I'm cleaning up the JBullet integration?
PhysX - Looks incredibly solid and robust, but software support is questionable, and hardware support is NVidia-only.
Havok Physics - Looks good, and is likely quite solid, but with several of the features present in PhysX sharded off into other products and potentially evil licensing restrictions. (though integration into JME is free) Also, no hardware support.
Bullet Physics - Again, looks good, but still under pretty heavy development if I'm reading the forums right. OTOH, the similarities to JBullet make the idea of a native integration a bit easier to stomach.
Thoughts? Other ideas? Other libraries? Anybody wanna do a Java physics library from scratch?
-Falken
I vote for PhysX, because of the reasons you already mentioned.
It is a great thing, that NVidia is behind PhysX and perhaps there will be support for ATI-chips in the future.
I mean: ATI cards have a lot more gpu power than NVidia cards and will rock the future. They would be even better suited for expensive physics calculations than the NVidia cards.
NVidia has to change the architecture to be competitive and then perhaps both chipsets will be more similar, and a PhysX support for both chipsets will be possible. NVidia will not like to do this, but perhaps they have to because of pressure by the game developers.
But even without gpu-physics: Multi-core processors are standard today.
Have you ever heard that PhysX makes any problems without GPU-support?
I can't imagine that, because some many commercial games are using it.
I think what you're seeing is the same wall that a lot of commercial game houses have been seeing. Nvidia's the closest to having it "nailed down", but companies are wary of shutting out consumers based on their GPU vendor.
What Turborilla used for Mad Skills Motocross I thought turned out very well, and they wrote it from scratch… They based it off of this guy http://www.teknikus.dk/tj/gdc2001.htm
…I've not done much with physics programming, but have been following the technology since AGEIA popped up on the scene. You definitely aren't alone in this boat. I personally think Intel and AMD will come out on top since they're offering cross platform opportunities and in the economic climate that physics is gaining ground in, market penetration is everything with high end computers/components being sold less and underpowered netbooks coming up more. There's a shrinking market for PC physics when you factor in the rise of the consoles and global domination via netbook.
That all said, I've said it before, I'll say it again, and Momoko will come in here and yell at me }:-@, but OpenCL needs to get up and going on Java so accelerated physics isn't shut away from LWJGL, JME, and other visualization applications
What is the licensing situation like for PhysX and Havok?
Say I want to make a game with JME, and JME happens to feature an integration with PhysX. In this case, what does that actually entail? Can I as an independent developer harvest the full power of PhysX without spending a dime?
Btw guys, are you familiar with AMD supporting OpenCL Bullet? Pretty exciting stuff that Skye linked me to a couple days back 
Personally I would just feel a lot more at home sticking to the leading open source solution that is Bullet. Other major OSS like Blender has also integrated it with their game engine. It is a lot easier to connect with and collaborate with fellow OS projects, so by using Bullet, my job would be a lot easier. If I shoot the bullet guys an e-mail or drop an inquiry on their forum, I'm sure I'll hear back from them. However if I try to get in touch with someone who truly calls the shots with PhysX or Havok, I'd reckon my chances are rather slim.
Maybe the port is not the way to go though, and we would be better off going for a binding. It's a bigger hassle when you just compare the work directly to integrating JBullet, but what about the big picture? When integrating JBullet we greatly rely on a third party to keep up. Unfortunately, it seems the port was not as far ahead as I thought it was, which makes me feel bad for encouraging Falken to continue work that might have not been the right way to go in the first place.
There is a last option though; we could find someone to continue the port, either in collaboration with the current developer or more like a branch for JME if a collaboration proves difficult. Not something to bet on though I suppose.
How viable are ports anyways? They are sort of destined to always be a couple steps behind. I always felt like making headway with ever more efficient compatible hooks and bindings was the way to go, just that in this case I was of the impression that we had a fairly complete and accessible solution at hand already, which would be great as 'the first of many'.
Edit:
Falken224 said:
(...)Anybody wanna do a Java physics library from scratch?
sbook said:
What Turborilla used for Mad Skills Motocross I thought turned out very well, and they wrote it from scratch... The based it off of this guy http://www.teknikus.dk/tj/gdc2001.htm
The thought of 'our own' physics library (well in Java anways and hopefully developed in 'close vicinity' of the JME community) is certainly enticing. Thing is, with just basic collision detection and some more, you've already met the needs of many projects.
And I've been playing around with the idea for a while. I looked at a couple older abandoned projects, and I was thinking maybe some day soon I'd send out a couple mails in hopes of finding a developer actually willing to make the true "JMonkey Physics". I don't know if this is the right time though. Maybe developing it for a shiny 3.0 version would seem more inviting.
Also, PAL is just a tool for interfacing with several physics libraries right? It doesn’t actually make integrations any easier?
erlend_sh said:
Also, PAL is just a tool for interfacing with several physics libraries right? It doesn't actually make integrations any easier?
and it's certainly not bound in java :|
I just played with the demo of the Simple Physics Engine, and it was most enjoyable! I can’t imagine many indie projects that would require more physics capabilities than what this neat library has to offer.
There’s a non-commercial licensing available, however it is restricted to single thread and the Windows platform. Possibly we could work something out for this project especially though.
erlend_sh said:
Unfortunately, it seems the port was not as far ahead as I thought it was, which makes me feel bad for encouraging Falken to continue work that might have not been the right way to go in the first place.
*chuckle*
Don't even worry about it. It's good ground-breaking work and seemed like the right thing to do at the time. And it's gotten me MUCH more familiar with the concepts you have to deal with in physics engines, which I think is an INCREDIBLY important part of this whole process. You don't complicate things with JNI, or having to deal with the nitty-gritty of actual physics calculations.
That said, here's what I wanna do and why:
1) I want to do something useful. Hardware accellerated physics could REALLY step up the quality for some hardcore physics-heavy type games (racing sims or the like) Thus, I vote for PhysX, even with it's limitations. Otherwise, it's "Just another binding"
2) But, if hardware accelerated is not a big deal, I fall back to the argument that bindings are ALWAYS going to cause some interesting problems, both in development and in distribution. AAANNND . . . I'd REEEEEALLLLY want to try coding up a physics engine, despite the incredibly high learning curve.
So . . . right now, kinda leaning toward starting up a physics engine from scratch. Might as well do it right, eh? :) That way we KNOW how far along the physics implementation is, and we're not waiting for ports and we're not having to deal with various OS incompatibilities.
I think that's the right way to go, but it'll take a while, and prolly never be as powerful as one of the big libraries. But hey, it'll be pure JME. :)
-Falken
sbook said:
That all said, I've said it before, I'll say it again, and Momoko will come in here and yell at me }:-@, but OpenCL needs to get up and going on Java so accelerated physics isn't shut away from LWJGL, JME, and other visualization applications
a bit off topic so apologies but here's an opencl java binding for mac os
http://ochafik.free.fr/blog/?p=190
ncomp said:
a bit off topic so apologies but here's an opencl java binding for mac os
http://ochafik.free.fr/blog/?p=190
I started laughing out loud in class.
I did see the JNA bindings, but haven't seen anything done with them yet, so i guess that was me subconsciously saying "it ain't there yet"...
Have you played with it at all? My OldBook Pro with 32 bit Core Duo and x1600 can't do any of this new fancy stuff
haven't upgraded to snow leopard yet so haven't had the chance to check out opencl…
but it's got a whiff of shader syntax and set up so hopefully it won't be that much of a mind bender considering how brainwashed i am an all 
So . . . with all this talk of OpenCL, I went and checked it out.
I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September. Maybe that's a bit optimistic, but hell . . . that's starting to change my mind.
Forget PhysX and Havok . . . I think maybe a straight Bullet Pysics JNI binding is the way to go. Let them do all the hard OpenCL work. We'll just call their API.
Hardware (of all sorts) accelerated (eventually) AND open source . . . seems like an easy sell to me.
Sounds good and well to me At least playing more with proven systems should prove useful before we want to start anything of our own. I still really like the idea of having a native library available, which could be really lightweight, but probably now is not the best time.
Falken224 said:Where are you getting this from? Playing the wait-and-see game is risky business, so we better not be idling with our hopes up for too long.
I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September.
I wanted to pop this question earlier though: What about 2D physics? Is this something JME could benefit from? After all, we do also seem to produce some 2D games that require physics, namely Tobias' MSM. There are some nice ports around, like JBox2D. Contrary to JBullet, this one is actively developed and pretty much on par with the original. I believe there are also a couple java based 2D libraries around, like this old thing.
erlend_sh said:
Falken224 said:Where are you getting this from?
I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September.
Well, right here
and here, too
:)
And it wouldn't really be WAITING. Bullet is a perfectly fine physics library to integrate with, whether they move to openCL or not. It'd just be a SPECTACULAR benefit if they did, and since they're the only library that's looking at adopting anything even LIKE universal hardware support, I say go for it. :)
-Falken
I vote for a straight bullet integration because of the above mentioned reasons: it’s open source, a very active community (so the development of integration can have tough questions answered quickly), a free licence, and it has hardware acceleration CUDA already http://www.bulletphysics.com/wordpress/?p=50, but OpenCl is soon to come. Also because Bullet is perpetually having features added which will be easy to integrate instead of one developer who probably won’t be here forever, no offense Falken. ;) Also creating a physics engine from scratch will probably be somewhat lacking features necessary by today’s standards (like CCD, hardware acceleration, multiple broadphase, and narrowphase algorithms).
add my vote on for bullet. 
So far all free engines I've looked at, only Bullet and ODE have been used commercially in many games and proven to work. So, I would vote for either of those. Is JBullet really lacking all that much? Do people really need all these physics features? I think what most people want is to be able to load their world easily within such engine and just have rigid body physics, you don't really need all that soft body or fluid simulation stuff.
JackNeil said:
I stopped using ODE/ODEJava because of memory leaks, stack corruption and random crashes.
This bugs are not related to multithreading. They are somewere inside ODE/ODEJava and they will probably never be fixed.
I can not recommend ODEJava for any serious project, but it is ok when you want to play around a bit with physics.
I hope ODE is stable and only ODEJava is buggy...
Does ODE have CCD? If it doesn't I know Bullet definitely does, which would definitely be a almost necessary feature and better to integrate.
Awesome! :D Will you be making a new branch then?