Java port of Bullet Physics Library

This is the coolest thing since javax.home.SlicedBread !
I will probably use this in my game (If I ever get around to starting!)

New version available on JBullet homepage.

Changes in release 20080303:

  • Refactored enums
  • Fixed bug that caused occasional jitter
  • Added ConvexConcaveCollisionAlgorithm
  • Memory optimalizations
  • Implemented quantized BVH nodes
  • Made ConcaveDemo working

It took some time for me to understand
the general concepts of Bullet but it works fine
with Jogl, too.

It would be nice if you would decoupled the lwjgl demos from the bullet library. Are you working on supporting the multithreaded portion of the library?

I will enhance the package by generating multiple JARs and actually include them in distribution package.

[quote=“GKW,post:44,topic:31221”]
No, and it’s low priority for me, at least for now. The ongoing work from my side is towards complete support of base features and synchronizing with newer releases of Bullet.

I’ve created applet version of JBullet demos that uses software rendering.

You can see it in action here:
http://jbullet.advel.cz/applet

Really great work, the vehicle demo is excellent. How did you do 3d in software? Did you use jpct?

It would be cool if you showed performance by displaying the FPS.

Thanks :slight_smile: I’ve created my own OpenGL-like software renderer. I’ve found jPCT unusable for that task, because it doesn’t use the same projection and lighting as OpenGL, and the rasterizer alone is not publicly available (documented) through API, also I couldn’t extract it as it’s not opensource library.

[quote=“CommanderKeith,post:47,topic:31221”]
I will add it.

New version available on JBullet homepage.

Changes in release 20080311:

  • Added some JavaDoc documentation
  • Added RaycastVehicle and VehicleDemo
  • Refactored accessing of vertex data
  • Added CylinderShape
  • Implemented ray/trimesh hit detection
  • Added applet demo
  • Added binaries and dependant libraries into package

May I ask how far are you long in having a full port of Bullet?

DP :slight_smile:

About base features, not that much, most visible missing things are:
AxisSweep3 (much better broadphase collision detection), moving trimeshes, some misc. shapes, ContinuousDynamicsWorld.

I’ll leave extras (like multithreaded version, COLLADA support, etc.) to others to develop if someone wants them. It’s simply not priority for me.

Hi

I’ve just register to JGO because I’m searching a physic library in java and I’ve discover your porting effort.
I’ve played a bit with JBullet, and you have done a very good work so far.

Your last post answer partially my current question : have you a comparison between Bullet and JBullet for features ported or not ?

For my project I’ll need motors, so I think I’ll port DynamicControlDemo if you have not started with it ?

Thanks :slight_smile:

I might create one later, currently the best is to compare which classes are or are not implemented.

No I didn’t, there are many demos which are not particular priority for me, would be nice if you help me port some of them, like this one :slight_smile:

Ok, I’ll start with DynamicControlDemo :wink:

It almost works, but I’ve a small bug : my joints are not correctly positionned.

As I discover the vecmath api, I don’t know if my port is correct for the following line :

localB = m_bodies[1+2*i]->getWorldTransform().inverse() * m_bodies[0]->getWorldTransform() * localA; 

in this :

tmpTrans.inverse(bodies[1+2*i].getWorldTransform());
tmpTrans.mul(tmpTrans, bodies[0].getWorldTransform());
localB.mul(tmpTrans, localA);

Seems fine to me. The second line can use one-parameter mul() but it doesn’t hurt either.

The bug will be probably elsewhere, as a hint I can provide list of common bugs I encountered when porting:

  • accidentally changed reference of Vector3f/etc field, instead of value by calling set(), that’s the reason for finals everywhere :slight_smile:
  • when removing the “m_” prefix of C++ members, I sometimes aliased it with parameter and it wasn’t working (obviously)
  • subconsciously treated order of operands for multiply freely changeable, but that doesn’t work for matrices/transforms (that’s one of hidden consequences of operator overloading)

If you don’t catch the error, you can send me the files, and I can look into it. It can be also bug in JBullet itself, not all code is covered by demos or tested.

I’ve check for these common bugs but I don’t find what happens
I send you the files on your email.

I just tested it, and it looks really good, both demo and source code :slight_smile:

Now I must just find the bug… :wink:

Found the bug, it’s on line 123 of TestRig.java, where QuaternionUtil.setRotation must be used instead of direct assign to quaternion fields. This fixed the position problem. There is another bug though, the simulation exhibits some jerkiness, I’ll be investigating it further.

OK, thank you very much.
I’ve just found that the rotation matrix wasn’t good, but i didn’t go further.