Currently only the BasicDemo is partly working, there is some problem with box/plane for ground, so spheres are simply falling down. Also it uses only SimpleBroadphase without removing overlapping pairs and it's only partly optimized, so it's pretty slow.

The remove of overlapping pairs is disabled because it touches some bug with SequentialImpulseConstraintSolver, which is accessing array out of bounds.

UPDATE 2008/02/07:
More information and latest versions can be found on JBullet homepage.

Last edited by jezek2 on Wed Feb 06, 2008 11:11 pm, edited 1 time in total.

I already posted over at JGO - but I post here again, in case you visit this board more often:
Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first post reads like size==1)

Wow, that is impressive work, how long have you been working on this? Can you describe your porting approach, did you use any automated tools, or manual find/replace?

It looks like interaction in the Java BasicDemo between spheres (sphere vs sphere and sphere vs box, a box spawned by the user) works fine, and so does picking.

SimpleBroadphase is a good start, although it is exhaustive/brute force. More parts of Bullet (like its SequentialImpulseConstraintSolver) could be split up into a 'Simple' version and Optimized/Cache friendly version. Such Bullet Simple/Light/Educational version would help porting and understanding of code.

It Would be good to figure out what is happening with the ground. In particular the btStaticPlaneShape should be fairly straightforward, as it doesn't rely on other algorithms (it doesn't need GJK, nor GJK but only the getSupportingVertex).

irrisor wrote:I already posted over at JGO - but I post here again, in case you visit this board more often:
Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first post reads like size==1)

Sorry, forgot to reply. For others, I also posted about the Java port on:

Erwin Coumans wrote:Wow, that is impressive work, how long have you been working on this? Can you describe your porting approach, did you use any automated tools, or manual find/replace?

Hi, thanks I've been working on this for a few days (or better, nights) nearly full time. I translated manually every line, maintaining the original structure as possible, only a few things are rewritten (SimpleBroadphase, OverlappingPairCache) to use Java collections such as HashMaps. The result was pretty unoptimized, there were tons of heap allocations everywhere I then converted it to use stack allocation (using own per-thread BulletStack object, as Java don't have stack allocations of objects).

Erwin Coumans wrote:

It looks like interaction in the Java BasicDemo between spheres (sphere vs sphere and sphere vs box, a box spawned by the user) works fine, and so does picking.

Yeah, although there is a little but hardly visible bug, which I already fixed in my version (will be part of the next update, after I fix the bug I mentioned in the last paragraph of first post).

Erwin Coumans wrote:

SimpleBroadphase is a good start, although it is exhaustive/brute force. More parts of Bullet (like its SequentialImpulseConstraintSolver) could be split up into a 'Simple' version and Optimized/Cache friendly version. Such Bullet Simple/Light/Educational version would help porting and understanding of code.

Actually I didn't have too much problem understanding the code, Bullet has very nice structure. The simple versions are basically there with the #ifdefs or flags, and was sufficient for my porting needs (at least so far).

Erwin Coumans wrote:

It Would be good to figure out what is happening with the ground. In particular the btStaticPlaneShape should be fairly straightforward, as it doesn't rely on other algorithms (it doesn't need GJK, nor GJK but only the getSupportingVertex).

Yeah I think too, but I'm now focused to hunting the bug I mentioned in the last paragraph of first post. I can already "fix" it by workaround, but I think that I have now fairly clear trace of origin of this bug. This bug costed me a couple of hours, but on the bright side, I learned more about Bullet internals, which is always good

Erwin Coumans wrote:Please keep us posted if you make some progress,
Erwin

Wow, you are making good progress, and the Bullet Java performance is very good.

Known issues:
- collision of boxes has some bug

Have you checked the btPersistentManifold class, or contact management? Is looks like some contact normal is wrong. Also, using the btStaticPlaneShape might help figuring out what is wrong (it doesn't reply on GJK or EPA collision detection algorithms, so it is easier to debug).

Changing the math operations throughout the entire library can be error-prone and makes maintenance a bit harder. For Bullet 2.x we probably stick with LinearMath, to keep the interface stable. More radical changes, possibly a full rewrite or change in math library might happen in a separate future project, like Bullet 3.x. We don't need to worry about that now.

Erwin Coumans wrote:Very impressive, it looks almost identical to the C++ version. It looks quite stable and fast, except for some occasional jitter, you might have noticed that?

Yes, some bug is still crawling somewhere

Erwin Coumans wrote:

jezek2 wrote:

darkprophet wrote:
If its a port, how come the webstart wants to run without permissions?

The demo uses OpenGL (LWJGL), I'll later add support for some software 3D renderer (probably jPCT or something like that).

It would be really nice to remove the security/permission issue. How much work is it to add support for a software render? So there is no 'trusted' OpenGL Java binding, without requiring permission?

No, there isn't and probably won't be. There is one possibility, to use LWJGL as a webstart extension, which can be then signed separately. This allows to run just the OpenGL binding with all permissions, but the application stays restricted. This doesn't solve the issue though.

I think that it shouldn't be that much work to add software mode, when I use some good library for it (like jPCT, but I'll look for others too).

Changing the math operations throughout the entire library can be error-prone and makes maintenance a bit harder. For Bullet 2.x we probably stick with LinearMath, to keep the interface stable. More radical changes, possibly a full rewrite or change in math library might happen in a separate future project, like Bullet 3.x. We don't need to worry about that now.

The situation is little different in Java, there is official Sun's vecmath library (using official "javax.vecmath" package). It's good for interoperability between apps and different libraries. Because the usage is a bit different from C++, I had to rewrite (port) it anyway to use it. There are still portions of LinearMath in utility classes, because Vecmath doesn't have all functionality. Transform is also from original LinearMath.

There is effort to standarize on Vecmath2, which is evolved version of the official Vecmath library, that can be extended, is truly opensource, and has more features.

To satisfy all parties, I'm leaning towards multiple builds for both Vecmath libraries, so developer can freely choose which one he prefers.

There is still some occasional boxes jumping up into the air just before they go to rest, in the BasicDemo.
And software renderer that doesn't require permission would be nice, but I suppose the abstraction is the first step.

Did you already make effort to isolate the problem, figuring out when this 'jumping' happens?
Thanks,
Erwin