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.
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 
It’s actual port.
The demo uses OpenGL (LWJGL), I’ll later add support for some software 3D renderer (probably jPCT or something like that).
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.
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
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
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
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
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.
Thanks. I will run it once more.
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 am sure, you’re talking about the possibility to do things like this:
vec.x += 10f;
In OpenMaLi’s vecmath2 this can be done like this:
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 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 :).
Well, that’s a bit of work indeed. Though most of it can be automated through text-replaces.
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
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.)
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
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 use code like this in objects that have Vector fields:
void getSomething(Vector3f out);
void setSomething(Vector3f vec);
(both are doing a copy)
So there is no problem of tracking for me
Good to hear
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.
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 ;).
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 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 ;).
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 ;).
Hmm… never tried that. But I guess, it should work to simply do a text-replace of “float” -> “double”.
Marvin
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:
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:
stack.vectors.push();
stack.quats.push();
try {
// some code
}
finally {
stack.vectors.pop();
stack.quats.pop();
}
Most accesses using public final Vector3f fields.
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?
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 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:
protected final Point3f position = new Point3f();
public Point3f getPosition() {
return position.asReadOnly();
}
public void setPosition(Point3f pos) {
this.position.set(pos);
}
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:
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.
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.
Great to hear that :).
Exactly my opinion :).
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 :).
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.
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.
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 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
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
This is truly impressive. Great work, man.
It’s a lot of fun to toss the poor guy around grabbing his head ;D. What’s the gravity setting? It looks like it’s lower then 1g.
Marvin
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