Java port of Bullet

[jezek2]

Hello,

I've ported Bullet 2.66 to Java. The first alpha version is available here:

http://jezek2.advel.cz/tmp/jbullet-20080111.zip

And webstart on:

http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp

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.

[irrisor]

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)

[Erwin Coumans]

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

Please keep us posted if you make some progress,
Erwin

[jezek2]

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:

http://www.javagaming.org/forums/index. ... ic=18035.0

[jezek2]

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

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

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

• 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

Please keep us posted if you make some progress,
Erwin

Sure, I will

[jezek2]

I've uploaded new version: http://jezek2.advel.cz/tmp/jbullet-20080116.zip

Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp

Changes:
- Moved all push/popProfile to try/finally blocks
- Added final for Vectors/Transforms/etc fields where applicable, and fixed some discovered bugs
- Fixed bug with non-functional removeOverlappingPair
- Enabled ground BoxShape in BasicDemo
- Implemented drawing of BoxShape
- Fixed VectorUtil.maxAxis

Known issues:
- collision of boxes has some bug

[Erwin Coumans]

I've uploaded new version: http://jezek2.advel.cz/tmp/jbullet-20080116.zip

Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp

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

Thanks for the update,
Erwin

[jfelrod1960]

This is impressive! Do you plan to have a website for jBullet?

[jezek2]

This is impressive! Do you plan to have a website for jBullet?

Thanks Yes, I'll create one in near future.

[jezek2]

New version: http://jezek2.advel.cz/tmp/jbullet-20080122.zip

Webstart demos:
BasicDemo
GenericJointDemo

Changes:
- Fixed convex/plane collision detection
- Added GLDebugDrawer and fixed some bugs
- Added CapsuleShape
- Added ConeTwistConstraint, HingeConstraint and Generic6DofConstraint
- Added GenericJointDemo
- Optimized drawing of spheres and cylinders using display lists
- Fixed collision of boxes
- Added text overlay

Enjoy

[Erwin Coumans]

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?

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?

On the math library discussion here: http://www.javagaming.org/forums/index. ... ic=18035.0
Have you considered to just port and use Bullet LinearMath classes like btVector3, btQuaternion and btTransform?

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.

Thanks again,
Erwin

[jezek2]

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

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

On the math library discussion here: http://www.javagaming.org/forums/index. ... ic=18035.0
Have you considered to just port and use Bullet LinearMath classes like btVector3, btQuaternion and btTransform?

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.

[jezek2]

New version available on JBullet homepage.

Changes in release 20080206:
- Memory optimalizations
- Added heap info
- Implemented HeapSort
- Added optional support for GNU Trove
- Added BspDemo and fixed ConvexHullShape
- Added ConcaveDemo and it's supporting classes
- Abstracted OpenGL rendering

[Erwin Coumans]

That looks good, very cool!

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

[jezek2]

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

Not yet. I'm now focusing on other things and to actually use it in my applications. I will try to look into it soon though.