Java port of Bullet Physics Library

[jezek2]

Hello,

I've ported Bullet Physics Library to Java. See:

http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=1827

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

[darkprophet]

Hey, thank for that. Just wondering if this is an actual port or a binding?

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

DP

[jezek2]

Hey, thank for that. Just wondering if this is an actual port or a binding?

It's actual port.

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

Games published by our own members! Go get 'em!

[irrisor]

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 posts reads like size==1)

[jezek2]

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 posts reads like size==1)

I'm working on it alone. No dates are set, but I would like to have it usable for my project in this month, but that's not fixed date either.

[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

[Herko_ter_Horst]

I'm afraid I am unable at this point to offer more than moral support, but I just wanted to say: keep up the good work!

[jezek2]

I'm afraid I am unable at this point to offer more than moral support, but I just wanted to say: keep up the good work!

Thanks, it's nice to see it useful for other people

[Marvin Fröhlich]

hi

I've just tried your webstart demo above. Does it do anything else than changing the spheres' colors? I can rotate the scene with the arrow keys, toggle wireframe mode with w and change the color with space. Is there anything else? (No offense of course)

It's very cool, that you're porting bullet to Java. Even if I like JOODE, it isn't currently developed anymore. So we need other options.

I saw, that you're using Sun's crappy vecmath lib. You shouldn't. It's extremely GC expensive. May I kindly suggest to use OpenMaLi? A current build can be optained here. OpenMaLi contains a package called org.openmali.vecmath2. It provides about the same (float-based) classes as Sun's vecmath but without the GC issues plus soe additional ones. And these classes are more feature-rich. The main difference is, that no public instance fields are used, but only getters/setters (which are inlined by the JIT-compiler). This gives you the opportunity to check for modifications through the isDirty() getter. There are built-in instance-pools for all the classes, that you can use to avoid insance-creation related GC issues. Well, there are a lot of other additional features in OpenMaLi. Maybe you even want to contribute some additional physical math to OpenMaLi . You'd be welcome.

Marvin

[jezek2]

hi

I've just tried your webstart demo above. Does it do anything else than changing the spheres' colors? I can rotate the scene with the arrow keys, toggle wireframe mode with w and change the color with space. Is there anything else? (No offense of course)

You can grab spheres by mouse and throw them, shoot boxes with '.' or right mouse, or apply impulse with middle button. I'll add text overlay with help in next version

It's very cool, that you're porting bullet to Java. Even if I like JOODE, it isn't currently developed anymore. So we need other options.

I saw, that you're using Sun's crappy vecmath lib. You shouldn't. It's extremely GC expensive. May I kindly suggest to use OpenMaLi? A current build can be optained here. OpenMaLi contains a package called org.openmali.vecmath2. It provides about the same (float-based) classes as Sun's vecmath but without the GC issues plus soe additional ones. And these classes are more feature-rich. The main difference is, that no public instance fields are used, but only getters/setters (which are inlined by the JIT-compiler). This gives you the opportunity to check for modifications through the isDirty() getter. There are built-in instance-pools for all the classes, that you can use to avoid insance-creation related GC issues. Well, there are a lot of other additional features in OpenMaLi. Maybe you even want to contribute some additional physical math to OpenMaLi . You'd be welcome.

I'll examine it. But I don't think the Sun's vecmath are crappy, yes sure, there are some allocations, but in somewhat rare situations, the most visible is Matrix*.invert(), which is practically not used in Bullet btw. I actually like the raw approach of fields. I don't think that vector lib should track dirty status or something, as it's extra work which is not needed in most cases. I would also need to change all my projects where I want to use Bullet, or have nasty conversions code when it meets other parts. But anyway, I might be wrong, I'll check it in detail for sure.

Games published by our own members! Go get 'em!

[Marvin Fröhlich]

You can grab spheres by mouse and throw them, shoot boxes with '.' or right mouse, or apply impulse with middle button. I'll add text overlay with help in next version

Thanks. I will run it once more.

I'll examine it. But I don't think the Sun's vecmath are crappy, yes sure, there are some allocations, but in somewhat rare situations, the most visible is Matrix*.invert(), which is practically not used in Bullet btw.

Sun's vecmath was the main reason for GC issues, that we once had in Xith3D. Replacing it with a GC-free version solved most of these nasty hick-ups. Would be a pity, if using your cool physics lib was a new reason for them.

I actually like the raw approach of fields.

I am sure, you're talking about the possibility to do things like this:

1	vec.x += 10f;

In OpenMaLi's vecmath2 this can be done like this:

1	vec.addX(10f);

There are a lot of these convenience methods to ensure, people don't start to dislike the lib just because they have longer lines of code .

And it is really hard to track, when a public field is accessed for writing or reading at design- and runtime. For getters/setters it's fairly easy.

I don't think that vector lib should track dirty status or something, as it's extra work which is not needed in most cases.

I did some deep benchmarks when I created vecmath2 and keeping these dirty bits up to date really didn't do anything at the performance. So it's purely extra feature with no loss of performance .

I would also need to change all my projects where I want to use Bullet, or have nasty conversions code when it meets other parts. But anyway, I might be wrong, I'll check it in detail for sure.

Well, that's a bit of work indeed. Though most of it can be automated through text-replaces.

I'll check it in detail for sure.

Cool .

btw. OpenMaLi was meant to become a standard math lib for all engines, etc. I hate, that everyone is creating an own math lib, which might be specialized. Sun's vecmath could be this one lib, but it is not an option because of the GC issues. OpenMali is designed to be as general as possible and is already used by Xith3D and Odejava. It was also planned for JOODE, but unfortunately the devs didn't have time to help me with the port of the more tricky parts of the simulation code.

Marvin

[Jackal von ÖRF]

Well, that's a bit of work indeed. Though most of it can be automated through text-replaces.

Or through a creative use of a couple of refactorings, such as explained here: http://blogs.jetbrains.com/idea/2006/08/switching-between-api/

(Migrating direct field access might be harder, though... might need some manual find-and-replace.)

[jezek2]

Sun's vecmath was the main reason for GC issues, that we once had in Xith3D. Replacing it with a GC-free version solved most of these nasty hick-ups. Would be a pity, if using your cool physics lib was a new reason for them.

I have own BulletStack object for Vectors, Matrices, Transforms and Quats. And there is BulletPool for some other things. The invert() method is practically not used, so I think there is no problem with it

I am sure, you're talking about the possibility to do things like this:

1	vec.x += 10f;

In OpenMaLi's vecmath2 this can be done like this:

1	vec.addX(10f);

There are a lot of these convenience methods to ensure, people don't start to dislike the lib just because they have longer lines of code .

This and that it's using less memory and indirection when it's stored directly in fields. In vecmath2 you have float[] array and few others fields for each instance.

And it is really hard to track, when a public field is accessed for writing or reading at design- and runtime. For getters/setters it's fairly easy

I use code like this in objects that have Vector fields:

1   2

void getSomething(Vector3f out); void setSomething(Vector3f vec);

(both are doing a copy)

So there is no problem of tracking for me

I did some deep benchmarks when I created vecmath2 and keeping these dirty bits up to date really didn't do anything at the performance. So it's purely extra feature with no loss of performance .

Good to hear

btw. OpenMaLi was meant to become a standard math lib for all engines, etc. I hate, that everyone is creating an own math lib, which might be specialized. Sun's vecmath could be this one lib, but it is not an option because of the GC issues. OpenMali is designed to be as general as possible and is already used by Xith3D and Odejava. It was also planned for JOODE, but unfortunately the devs didn't have time to help me with the port of the more tricky parts of the simulation code.

Yeah, standard vecmath is really good thing for interoperability between apps/libraries. Sun's "javax.vecmath" is standard, but probably not sufficient.

What about automatic creation of builds (either by source modification or on bytecode level) that support either the lib? I already thought about it some time ago, to allow having version that uses doubles instead of floats.

[Marvin Fröhlich]

I have own BulletStack object for Vectors, Matrices, Transforms and Quats. And there is BulletPool for some other things.

That's what I was talking about. There should be no need to reinvent thewheel and create all this on your own, if the math-lib already provides it .

This and that it's using less memory and indirection when it's stored directly in fields. In vecmath2 you have float[] array and few others fields for each instance.

I didn't profile the memory usage. So I cannot comment this in detail. Though I guess, the overhead is not too big and should not be a problem, since it should be only a few additional bytes per instance. I would not worry about it.

I use code like this in objects that have Vector fields:

1   2

void getSomething(Vector3f out); void setSomething(Vector3f vec);

(both are doing a copy)

So there is no problem of tracking for me

I assume, you don't have those methods for all accesses to vectors, which would make the direct field approach quite useless . So in case you will have this problem .

Yeah, standard vecmath is really good thing for interoperability between apps/libraries. Sun's "javax.vecmath" is standard, but probably not sufficient.

Sun's vecmath is designed specifically for Java3D. And Sun won't care about other opinions, what should be better to be integrated into it. I always try to keep it as general as possible and the influence of JOODE (by Arne) to OpenMaLi was quite big, which made it even more general.

Plus: If you need something in the math lib, it can be added to OpenMaLi. You will never get Sun to add or modify anything in their vecmath .

What about automatic creation of builds (either by source modification or on bytecode level) that support either the lib? I already thought about it some time ago, to allow having version that uses doubles instead of floats.

Hmm... never tried that. But I guess, it should work to simply do a text-replace of "float" -> "double".

Marvin

[jezek2]

That's what I was talking about. There should be no need to reinvent thewheel and create all this on your own, if the math-lib already provides it .

Oh, I should have explained more. It's "special" pool designed to match JBullet needs, that has push() and pop() operations (called in try/finally block), so it automatically reuses objects when they leave the scope. An example:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

protected final BulletStack stack = BulletStack.get(); // per-instance, obtains it from ThreadLocal to allow having multiple distinct simulations in different threads // the instance has usually many fields, so it doesn't matter to add one :) void someFunc() {    stack.pushCommonMath();    try {       Vector3f vec = stack.vectors.get();       // etc   }    finally {       stack.popCommonMath();    } }

pushCommonMath pushes vectors, matrices and transforms. You can also push/pop individual stack pools like:

1   2   3   4   5   6   7   8   9

stack.vectors.push(); stack.quats.push(); try {    // some code } finally {    stack.vectors.pop();    stack.quats.pop(); }

I assume, you don't have those methods for all accesses to vectors, which would make the direct field approach quite useless . So in case you will have this problem .

Most accesses using public final Vector3f fields.

Sun's vecmath is designed specifically for Java3D. And Sun won't care about other opinions, what should be better to be integrated into it. I always try to keep it as general as possible and the influence of JOODE (by Arne) to OpenMaLi was quite big, which made it even more general.

Plus: If you need something in the math lib, it can be added to OpenMaLi. You will never get Sun to add or modify anything in their vecmath .

Hm yes true. Btw do you have any statistics what libraries actually developers use? vecmath, vecmath2, or do the majority use their own vecmath libs? or are there any other general purpose libs available?

[jezek2]

Ok, I looked more into it, read forums, etc. And I start to like it I'll continue to use Sun's vecmath for awhile to have more finished port, and then (if I don't change my mind of course) I'll port it to Vecmath2 (and gradually the other projects).

I really prefer the standard way (be it official or de facto) for such thing as a Vecmath library. I hoped that "javax.vecmath" is the solution to this, but seems it's missing features, and what's worse the API is set in stone, it can't evolve. I like your approach (if I'm not wrong) and I apply it too, when things needs to be fixed, it should be fixed regardles of backward compatibility (I don't mean huge rewritting but small iterative changes).

There is some stuff missing for me though. Most notably I need the double versions of (at least) Matrix3d/4d, Vector3d and Point3d.
EDIT: I don't need that now though, when I will need it I can contribute a patch.

There are some methods that seems duplicate to me, like scaleAdd() could be replaced with mul().add(), which is more universal (there are few places where I needed scaleSub() for example). Have that any reason (like performance) besides having compatible methods with Sun's vecmath? Or scale(float) vs mul(float). Also the clamp() etc methods returns TupleNf<T> instead of T (I know that would be probably problem to solve ), so you can concatenate operations only from base TupleNf.

I don't know if it's really useful, but I have an idea of XXX.asReadOnly() method, which would create a new XXX readonly instance with shared float[] array. The instances should be cached in WeakHashMap (EDIT: or better own cache that uses SoftReference, should be pretty straightforward to create), so you could simply write code like this:

1   2   3   4   5   6   7   8   9

protected final Point3f position = new Point3f(); public Point3f getPosition() {    return position.asReadOnly(); } public void setPosition(Point3f pos) {    this.position.set(pos); }

[Marvin Fröhlich]

Oh, I should have explained more. It's "special" pool designed to match JBullet needs, that has push() and pop() operations (called in try/finally block), so it automatically reuses objects when they leave the scope. An example:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

protected final BulletStack stack = BulletStack.get(); // per-instance, obtains it from ThreadLocal to allow having multiple distinct simulations in different threads // the instance has usually many fields, so it doesn't matter to add one :) void someFunc() {    stack.pushCommonMath();    try {       Vector3f vec = stack.vectors.get();       // etc   }    finally {       stack.popCommonMath();    } }

pushCommonMath pushes vectors, matrices and transforms. You can also push/pop individual stack pools like:

1   2   3   4   5   6   7   8   9

stack.vectors.push(); stack.quats.push(); try {    // some code } finally {    stack.vectors.pop();    stack.quats.pop(); }

Most accesses using public final Vector3f fields.

Hmm... don't know, if this suit your needs. But in vecmath2 there's an abstract ObjectPool class, that all concrete pools extend from. So you could implement a specialized pool for other class instances than the vecmath2 internal ones with only a few lines.
But maybe your more global pool approach has to be implemented on a higher level. Though might be useful for general use and should therefore be in OpenMaLi.

Using the vecmath2 internal pools would be like this for the above code example:

1   2   3   4   5   6   7   8   9   10   11   12

Vector3f vec = Vector3f.fromPool(); try {     ... } catch ( BlahException e ) { } finally {     Vector3f.toPool( vec ); }

It doesn't matter, how many instances currently are in the pool. Additional instances are created on demand.

Hm yes true. Btw do you have any statistics what libraries actually developers use? vecmath, vecmath2, or do the majority use their own vecmath libs? or are there any other general purpose libs available?

No, I'm afraid I have no statistics. I only know, that Java3D uses Sun'S vecmath (and will always use), jMonkeyEngine uses their own internal math. Though I will try to ask them somewhere in the future, if they maybe want to move to vecmath2, since JAGaToo uses vecmath2, which is a gaming-tools lib, that jME might find useful to base on like Xith3D does. (Just another (meant to be) standard lib to share code). Xith3D uses vecmath2, Odejava uses vecmath2, JOODE will use vecmath2.
That's all I know of.

Ok, I looked more into it, read forums, etc. And I start to like it I'll continue to use Sun's vecmath for awhile to have more finished port, and then (if I don't change my mind of course) I'll port it to Vecmath2 (and gradually the other projects).

Great to hear that .

I really prefer the standard way (be it official or de facto) for such thing as a Vecmath library. I hoped that "javax.vecmath" is the solution to this, but seems it's missing features, and what's worse the API is set in stone, it can't evolve. I like your approach (if I'm not wrong) and I apply it too, when things needs to be fixed, it should be fixed regardles of backward compatibility (I don't mean huge rewritting but small iterative changes).

Exactly my opinion .

There is some stuff missing for me though. Most notably I need the double versions of (at least) Matrix3d/4d, Vector3d and Point3d.
EDIT: I don't need that now though, when I will need it I can contribute a patch.

I didn't implement the double versions, since I didn't see a need for them. If there someone (like you ), who has a need for them, you would give a really great contribution to the project .

There are some methods that seems duplicate to me, like scaleAdd() could be replaced with mul().add(), which is more universal (there are few places where I needed scaleSub() for example). Have that any reason (like performance) besides having compatible methods with Sun's vecmath?

It is relatively new, that most of the methods return the instance back again. And the scaleAdd() method was there from the beginning on. So if this isn't slower because of the two method calls and therefore two for-loops, the scaleAdd() method couldbe removed. Otherwise we should add a scaleSub() method for you.

Or scale(float) vs mul(float).

Well, the basic reason for keeping both methods is the logic of the code when you read/write it. It is the same reason, why I kept both PointXf and VectorXf classes even, if they only differ in a handful of methods and of course the way they are transformed by a Matrix4f. A point is a point and a vector is a vector. They might be very similar and even related, but they are not the same from a mathematical point of view.
Sometimes you might find it more logical to multiply a point's values, that to scale it.

Also the clamp() etc methods returns TupleNf<T> instead of T (I know that would be probably problem to solve ), so you can concatenate operations only from base TupleNf.

That simply wouldn't compile. Otherwise I would have done it. If you see a way to make this working, we can happily change it.

I don't know if it's really useful, but I have an idea of XXX.asReadOnly() method, which would create a new XXX readonly instance with shared float[] array. The instances should be cached in WeakHashMap (EDIT: or better own cache that uses SoftReference, should be pretty straightforward to create), so you could simply write code like this:

1   2   3   4   5   6   7   8   9

protected final Point3f position = new Point3f(); public Point3f getPosition() {    return position.asReadOnly(); } public void setPosition(Point3f pos) {    this.position.set(pos); }

I really like this idea. I think, I will add this feature soon .

Thanks for the feedback. And thanks for deciding to (maybe) use OpenMaLi.

Marvin

[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

[Marvin Fröhlich]

This is truly impressive. Great work, man.

It's a lot of fun to toss the poor guy around grabbing his head . What's the gravity setting? It looks like it's lower then 1g.

Marvin

[darkprophet]

I am building a game engine that uses vecmath and profiling with both yourkit and the netbeans profiler shows that with correct usages, the GC is fine with it since most allocations are in the young generation.

Im afraid you might constrict the people who use your API if you got down the route of supporting one rendering library with its own customised math lib.

DP

[jezek2]

This is truly impressive. Great work, man.

It's a lot of fun to toss the poor guy around grabbing his head . What's the gravity setting? It looks like it's lower then 1g.

Thanks, it's just a simple testing scene (from original Bullet), you can check the sources for details and play with adjustments

Im afraid you might constrict the people who use your API if you got down the route of supporting one rendering library with its own customised math lib.

I'm leaning towards the idea of automatic Ant-based source translation to vecmath2 (the original would be still using Sun's vecmath), so I could support both of libraries at once to satisfy all parties There might be also builds with doubles instead of floats in future.

Though I think you're not quite fair to the Vecmath2 effort, it's really independent of Xith3D, and have interesting features, and could be extended more, whereas with Sun's vecmath we're stuck in time

[bienator]

Though I think you're not quite fair to the Vecmath2 effort, it's really independent of Xith3D, and have interesting features, and could be extended more, whereas with Sun's vecmath we're stuck in time

anyone tried to contribute changes back? In best case the vecmath2 lib could be a extension of Sun's improved vecmath package instead of a fork.

EDIT: added improved before vecmath to make it clearer

[kevglass]

Where are you getting that vecmath is closed source, or not accepting contributions - looks pretty open to me?

https://vecmath.dev.java.net/

It's a sub-project of:

https://java3d.dev.java.net/

Where most of the mangement get's handled. I'm sure they'd be excited about a whole bunch of contributions that reduce GC and improve performance!

EDIT: Infact:

The API specification will continue to evolve as part of the Java Community Process (JCP). We welcome community participation, and encourage developers to contribute both bug fixes and new implementation code to the API.

Kev

[darkprophet]

Why not have method that take floats and you translate them into whatever libs you want?

so maybe: position(float x, float y, float z); It might break the API, but then atleast your math lib neutral, much like ODE.

DP

[CommanderKeith]

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

GenericJointDemo
Enjoy

Holy cow, that's amazing!! 

pressing e for more people and . for bombs loads of times doesn't ware it out - it's still stable, nice job with the port.

[jezek2]

Why not have method that take floats and you translate them into whatever libs you want?

so maybe: position(float x, float y, float z); It might break the API, but then atleast your math lib neutral, much like ODE.

That's not an option, Bullet doesn't have clearly seperation between public API and "internal" things. In fact, Bullet is pretty modular and you can happily use any internal stuff when you need just that. ODE on the other hand has C frontend API that hides all internal stuff.

[jezek2]

Where are you getting that vecmath is closed source, or not accepting contributions - looks pretty open to me?

JDL is not classic opensource license, for example it requires that modified versions passes TCK. To obtain it I must do some paperwork, which I don't want. To change things I must become member of JCP, another thing that is barrier for me.

With truly opensource I have much lower barrier to contribute or even make own changes for my own usage (none barrier).

I'll provide builds of JBullet for both vecmath libs and let decide developer what he likes/needs. This issue is pretty closed for me by this.

[Marvin Fröhlich]

OpenMaLi is certainly not specialized especially the vecmath2 package. There may be some packages or classes, that would not be there, if I wouldn't use it in Xith3D as well as there are some changes or additional classes, that came from influences from the JOODE project. But these specific classes are all written in a way, that make them usable for other purposes, too. And this is, what should be applied to everything committed to the project.

So it is perfectly independent from Xith3D or any other project.

Marvin

[jezek2]

I've been thinking a lot about Vecmath libraries lately. I've come to the conclusion that it simply can't be done "nicely" in Java. For example, supporting read-only Vector3f would need "const" support in Java, but that's horrible thing as it pollutes entire code bases. It can be done somewhat by interfaces, but that's not good for performance and is not ideal either.

I've come to similar conclusion with properties in Java (instead using getters and setters). I thinked and tried few approaches (and searched web for ideas), all had major drawbacks, I then realized that getter/setters are simply the best option, their only drawback is that you have to type more, but that's not much issue because we have powerful IDEs.

Also, with physics library, you have to already somewhat translate between graphics and physics layers, so wrapping between different Vecmath libraries is not much problem. Maybe I can add "float x,y,z" versions to some "public" and supposedly to be widely used methods to ease this, as darkprophet suggested.

So my conclusion is, that I will stick with official "javax.vecmath" library, and everything that is not included can be added through utility static methods, we as Java developers are using them a lot already, so no issue

Marvin I'm sorry about it, but I think that Vecmath2 don't add much value (at least in current version) to switch from official Vecmath (or developers' own implementations).

[bienator]

JDL is not classic opensource license, for example it requires that modified versions passes TCK. To obtain it I must do some paperwork, which I don't want. To change things I must become member of JCP, another thing that is barrier for me.

With truly opensource I have much lower barrier to contribute or even make own changes for my own usage (none barrier).

just for a note: the next version of Java3d (and vecmath) will also have GPLv2+CP ex as license (1.5.2). The 1.6 release is planed to be the "big changes" release but I am pretty sure that this release won't happen this year.
1.6 is probably the release with the best chance to get a contribution approved.