Java port of Bullet Physics Library

Hi Jezek,

Any news on jbullet porting ?
Is still there issues for 2.66 or you have started on 2.68 sync ?

Hi, sorry for late reply. Currently I’m not doing any development on JBullet, I’m working on other things. But soon I will work again on physics related code which implies more porting :slight_smile:

I think I’ll look on AxisSweep3 and then convert everything already ported to 2.68, so the gap is not opening that much.

I have been playing with the port, and it looks great. I ported the HelloWorld.cpp application, since I’m interested in a non-interactive simulation for some of my work. The port was trivial as I basically did the same change as in BasicDemo. I can email it to anyone who wants it but it only takes about 5 minutes.

Running time is about the same for them, but it ends so quickly that it is not a good measure. The good news is that the numerical results are exactly the same for the first 100 steps between Bullet and JBullet (100 steps is the default). My question would be whether this in general would be true? After 110 steps, they seem to diverge, with an X value creeping in with JBullet. I didn’t know if that was a numerical stability issue with this particular simulation, or a more general issue.

Thanks for JBullet in any case!

Nice to hear :slight_smile: If you wish you can contribute it, just remember to put your real name in the copyright and use the ZLIB license header like other files. You can send me it to my e-mail (with subject that contains “JBullet”).

I think there is no such guarantee, JBullet uses little different math functions, uses Java’s HashMap, Java vs C++ can have little different float behaviour, not to count that different machines can have slightly different results, etc. There can also be some bug in JBullet :slight_smile:

Just tried the demo on Mac OS X with Java 6 and LWJGL fails to link:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1281)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1219)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1066)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.UnsatisfiedLinkError: /Users/scott/Library/Caches/Java/cache/6.0/22/77006f16-51bef9e4-n/liblwjgl.jnilib:
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1822)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1715)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.lwjgl.Sys$1.run(Sys.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:68)
at org.lwjgl.Sys.loadLibrary(Sys.java:84)
at org.lwjgl.Sys.(Sys.java:101)
at org.lwjgl.opengl.Display.(Display.java:111)
at javabullet.demos.opengl.LWJGL.main(LWJGL.java:51)
at javabullet.demos.basic.BasicDemo.main(BasicDemo.java:230)
… 9 more

I’m guessing that it’s because there isn’t a 64-bit image in the jnilib. Java 6 on Mac is only 64-bit so all JNI must be 64-bit as well.

So , is JBullet physic deterministic?

New version available on JBullet homepage.

Changes in release 20080716:

  • Fixed bug in conversion between planes and point cloud
  • Added DynamicControlDemo (contributed by Olivier OUDIN)
  • Changed package from “javabullet” to “com.bulletphysics”
  • Bug fix for constructor with pivots and axis in HingeConstraint (contributed by Olivier OUDIN)
  • Converted to use JStackAlloc
  • Converted to use output parameter when returning vectors, etc.
  • Updated existing code to match Bullet 2.70-beta1
  • Added ShapeHull
  • Ported original version of HashedOverlappingPairCache
  • Removed optional dependency on GNU Trove
  • Added AxisSweep3
  • Added profiling support
  • Changed to make single thread build by default
  • Changed to use nanoTime
  • Added HelloWorld demo (contributed by Clark Dorman)

New version available on JBullet homepage.

Changes in release 20080803:

  • Upgraded LWJGL to 2.0rc1
  • Added UniformScalingShape
  • Improved JavaDoc generation
  • Removed dependency on JStackAlloc in demos
  • Added support for moving triangle meshes
  • Added MovingConcaveDemo
  • Optimized allocation of collision algorithms

The rabbits that you shoot out are pretty cool in the new Concave demo. But I was wondering, are the walls meant to do anything?

When I launch the vehicle demo, I get this:

org.lwjgl.LWJGLException: Could not choose visual
at org.lwjgl.opengl.LinuxDisplayPeerInfo.initDefaultPeerInfo(Native Method)
at org.lwjgl.opengl.LinuxDisplayPeerInfo.(LinuxDisplayPeerInfo.java:52)
at org.lwjgl.opengl.LinuxDisplay.createPeerInfo(LinuxDisplay.java:702)
at org.lwjgl.opengl.Display.create(Display.java:779)
at org.lwjgl.opengl.Display.create(Display.java:733)
at com.bulletphysics.demos.opengl.LWJGL.main(LWJGL.java:53)
at com.bulletphysics.demos.vehicle.VehicleDemo.main(VehicleDemo.java:609)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1272)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1218)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1065)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Thread.java:619)

Is it possible to use JBullet with JOGL?

Odd, what graphics card/drivers/platform did you test on? Does other LWJGL based apps work for you? I’m using LWJGL 2.0rc1.

JBullet as physics engine is independent of any graphics API. The demo framework uses OpenGL through LWJGL. The drawing and input is already abstracted so it can support software renderer for applet demo, so it should be pretty easy to add JOGL support. If you’re interested you can contribute the code :slight_smile:

They should be there just for something to block falling out. Or did you test the applet demo? The software renderer is currently very simple and there is only linear non-perspective interpolation, so they sometimes occlude geometry in front of them.

Hi Jezek2!

May I ask, for what projects do you use JBullet (curious :)) ?
For how long do you believe you’ll continue developing JBullet?

Best wishes with future development,
Magnus

I’m working on few projects using it, two are major for me.

As long as there will be features interesting for my applications I will port them. Some features I do not use, but are usually not that complex and creates completness of library. In latest development version I’m focusing on writing descriptive JavaDocs and better method names and encapsulation. Goal is to transform it to a normal Java library without much signs of C++ origin. There is possibility that development will stagnate, but it’s open source and I think there won’t be problem supporting at least contributors in future.

Thanks :slight_smile:

To all: any ideas how to make JBullet more visible? It has some (small) popularity, but when I try googling it, not many sites are mentioning it.

First, great work jezek! Keep it up!

May I make some modest suggestions on how to increase visibilty?
(If not then please disregard the following :slight_smile:

  1. Start a project for jBullet on sourceforge.net (or equivalent). It doesn’t mean you should use their tools. Just get a space and forward traffic to your home page. In the future it might also be a very good platform for incorporating contributors etc. It’s also a nice way of making sure that the project never “disappears”, and that makes people more confident and willing to use the library. (Of course that would require committing the code every once in a while to the sf code repository.)

  2. Get more people involved in the project. Try to get people who write game engines, games and other stuff to contribute, test and use the library. They will write about it on their websites and so on. This might not be an option, depending on how “personal” this project is to you. You know best. Follow your heart. (Hehe gee that sounded corny…) The theory is, more people on the project, more activity and exposure.

  3. Put up a minimal Wordpress website with a simple design. Utilize the blog-feature and post regular news. (Make sure people can subscribe to that RSS-feed.) I strongly suggest Wordpress as it’s efficient, simple and a SEO-winner.

  4. Make YouTube videos and screenshots and put up on the blog/website.

  5. Create a jBullet logo that people can put in their games/websites to show that they use it.

  6. Make screenshots and videos. Did I already say that? :wink: The trick is really to make screenshots and videos that tickle people’s imagination, imho. A checkerd plane with some boxes colliding is not very fun, apart from the occasional academic left-brain kick. A nicely lit basement with some crates moving around and being destroyed when shot at, tells the story.

I believe, that if you got all this going, Google rank will happend by itself. (Although a nice proper domain, like jbullet.org, wouldn’t hurt.)

I’m kinda a layman-hobby-learning-game-deving-in-my-spare-time-guy, and I’d love to play around with jBullet, and I will a some point :slight_smile: Anyway, if any of the suggestions above sound good and you wanna give them a try, but you feel pressed on time, then I’d be happy to help out. I’m a web designer and could help out with 1), 3) and 5). In the future I might be able to do videos and screenshots too. Just let me know somehow if I can help out!

ciao!
/soul8o8

Hi, thanks for your suggestions. I will be thinking about them more. You’re right that more core developers would be really nice, but the problem is, that I feel that not much developers are interested in doing this kind of work. I somewhat always do the hard things that others don’t have energy to put on, like this task of porting huge amount of C++ code to Java, it also requires quite good knowledge of both languages. I’ve been there before on another open source project: MetaTheme which provides unified look and feel of major Linux GUI toolkits (including Swing). It had some nice exposure, and even few contributors, but no one touched core :slight_smile: Again you would need to master three different GUI toolkits to touch it… I use it everyday, it’s not perfect but usable for me, and I still have future plans, just I had to abandon it for few years because of other projects (and partially also for regaining energy and rethinking architecture).

So JBullet is not that ordinary project. Also creating some news is problematic, since most work is about porting existing library and “only” fiddling with details on top of that. Even the original Bullet doesn’t have news too often :slight_smile:

I think that more real demo could be done as a part of my “main” project (for which JBullet was partly created). I plan to add some testing physics scene, could be used also for promoting JBullet, by both screenshots/videos and actual demo application. As a side effect I would gather some stats how it run on more HW (I’m especially curious about ATI ;)).

Cool jezek!
I understand your concerns and you have my respect :smiley:
My offer still stands, just let me know at any time if you think I could help!

Anyway, I was really blown away by the webstart demos of jBullet—it’s really looking good!
Btw, are you by any chance thinking about implementing the continious-step-thing?

Take care!
br
/soul8o8

Thanks for offer. I want to do the website myself (hosting/code-wise), but if you’re in a creative mood you can try to look how it could be improved (content, design, logo, etc.). Your contribution is welcome, though as this is subjective thing, also count that I might not like some idea.

Yeah, they amazes me too ;D

Currently it’s only partially supported in original Bullet, and interaction between rigid bodies is non-existent. But it seems it will be improved in upcoming new versions. This is definitely thing that I want to port when it’s ready :slight_smile:

[quote]You’re right that more core developers would be really nice, but the problem is, that I feel that not much developers are interested in doing this kind of work. I somewhat always do the hard things that others don’t have energy to put on, like this task of porting huge amount of C++ code to Java, it also requires quite good knowledge of both languages.
[/quote]
Well I had to do the exact same thing porting ODE for JOODE.

Your attempt seems to be taking off pretty well. Can you tell me the features of JBullet?

What is the integrator?
What is the constraint satisfaction technique? And how does it cope with redundant constraints like a door with two hinges?

Can you retrieve the actual forces used to enforce constraints?

Tom

Thanks :slight_smile:

You should rather post these questions to original Bullet forum, I’m not a physics guy :slight_smile: I’m more an user, but willing to see what is behind to better understand whole problem and it’s specifics as every abstraction is leaking implementation details. Bullet is nice in it’s object hierarchy, allowing using just stuff that you need and it even doesn’t have to be for physics. As a nice side effect of porting I have much better whole image of internals, something that’s very useful when implementing it for my purposes or possibly extending it.