Native Bullet versus JBullet

in theory, java’s physics libraries can give the same result in all environments by strictfp. On a well-tuned physics stage of a one-person offline game, it helps creator to reproduce the expected results in any environment.
C ++ physics libraries can not do that.

For me, the binary level cross-platform is the strength of jmonkey.

However, jbullet does not seem to use strictfp. But using strictfp is easy.

If jbullet and bullet native implement the same API, and if jmonkey chooses a library to use depending on whether the native-bullet supports the runtime environment, it will improve cross platform. However, it does not have the exact same API, and jbullet seems too old.

P.S. I’m sorry for disturb veteran chat.

1 Like

The “downside” would be that you’re losing some precision for more capable platforms. Would that matter if you’re only simulating physics locally? I don’t know, but if I’m only targeting desktops, I don’t want someone’s crappy phone limiting my design. Well I’m sure it already does due to JME support, but it’s not something I’m jumping at a chance to expand on.

Dang kids with all that modern technolergy… and get off my lawn too.


Dang kids with all that modern technolergy… and get off my lawn too.

:rofl: they need your lawn to catch that pokemon in game! then phone app say them to share photo when they are on your lawn on FB to get more points! and they even dont know GPS send their location into metadata.


Okay, we’ll see where I go with this if anywhere, but maybe I can lend a hand. First finding…

With all these apparent “bugs” turning up in the NB 11 Gradle maybe I’ll have to revert to 10 at some point, but that one looks workaround-able.


For the examples listed above, did you mean for jme3-examples in Git, or “wiki examples”?

1 Like

I was thinking of jme3-examples when I wrote that.

1 Like

PR for one out. Let me know if you’ve got any specific ideas and I’ll see what I can do.

1 Like

@lifeinwild Just noticed this - no disturbance! It’s great to see knowledgeable new users show up! (Love the kitty photo btw.)

1 Like

Since we keep 2 physics libraries around, we can make one of them the default.

Currently the SDK uses jme3-bullet in its BasicGame and JmeTests project templates, but the Engine’s jme3-examples sub-project defaults to jme3-jbullet.

Unless there are prompt objections, I’d like to make jme3-bullet the default for jme3-examples.


In my opinion nowadays native bullet is a better choice. Being actively mantained is a big plus. Also I found it to be more consistent across devices than jbullet, specially from desktop to android (which is my focal point) and also a little quicker

I though someone already did after my last manual compilation… I may help with that :wink:

1 Like

I may help with that

That would be great!

As a side note… is there any reason why openCL is not being used at all for both desktop and android bullet native? I don’t know the inners of the library but if that may improve performance it could be something interesting to look at while minie is not default in jme

Ook I see. What a pity… :frowning:


Effective today, jme3-bullet is the default for jme3-examples:

It’s not difficult to switch back to jme3-jbullet, if you need to.


The only downside is getting bullet-native to run on arm linux (raspberry pi), for example, where jbullet would just work.
If we had the manpower and wouldnt be years behind, we should have our own jbullet fork maintained. And if it’s only to spot bugs in either implementation

1 Like

I tried and was unable to reproduce this bug. Has anyone seen it recently?

1 Like

I had it too. Without that line of code bullet just start acting up after some time. Forces are ignored, collisions don’t happen. It just renders it unworkable.

See and following comments: Questions about character movement/physics engine in multiplayer game - #8 by remy_vd

1 Like

We had it in Monake as well: Fix Physics, ez-pz · MeFisto94/Monake@f562ad1 · GitHub
Unfortunately it’s not a good test application as you are missing the assets (licensing) and I don’t remember what kind of problems we had, it was either: Walking speed was capped, you couldn’t get any faster for some reason, ghost collisions not happening or falling through random planes.

The last one is also an interesting “bug” in Bullet: before Remove roll and pitch angles, so that the character behaves like a re… · MeFisto94/Monake@d271260 · GitHub one could move the capsule in two rotation axis (x and y), and when looking down you would typically fall through the ground.

Don’t ask me if that is expectable or maybe related to precision, CCD or whatever, but this could be experimented with a test as well (a capsule whose physics rotation is basically camera.getLookAt())

1 Like

Thanks for the links.

I really want to investigate these issues—or at least document them properly. However, I’d want to start with simple, self-contained examples.

PS: Note there are 2 ways to achieve a fixed time-step in JME physics:

  1. By passing a positive maxSteps to PhysicsSpace.update(float time, int maxSteps) (how BulletAppState does it)
  2. By passing a fixed time to PhysicsSpace.update(float time, int maxSteps) (the solution discussed above)
1 Like