Building jme-bullet based on native Java bindings


i’m running into a few issues i’d like to ask about:

Issue1: i’d like to know how to run a jmonkey-engine gradle build using my natively built java bindings. No matter what i try the build gets outdated native binaries online and bases the jmonkey build on it. Basically i’d like to run the demos and half of them won’t run due to the jbullet deps. Is there another way to build this ?

I’m currently having some code with a scene and nifty-gui running but it’s really hard to understand what to do without proper documentation (Issue2) and a broken examples build / broken monkeyzone build.

More detail on Issue 1:

  • built jmonkeyengine from github with jme-bullet trying to find a shared lib .so build against glibc 2.7 (which won’t work as is outdated (2014 or so)). Got jbullet java binding from gitlab and built it against my native os libbullet which gives me a working shared lib. The gradle build however does not know about this lib and uses it’s own native version pulled from an online archive. (The archive contains cross-platform binaries of jbullet for all kinds or archs.)

Same thing applies to the SDK. Outdated jbullet crashes examples.

Issue 2: Documentation

Half of the documentation seems to be offline w/ dead links, is this intended ? Can i get documentation somewhere or build it myself ?

Best and thanks a lot for any insights,

Welcome to the community!

I can’t help you with what you want specifically, but I might be able to help somewhat.

I think the minie library uses a more recent bullet version than the standard bullet dependency. It’s just a standard drop-in replacement, so other than changing dependencies, it should all “just work” the same as usual.

The docs are linked here:
We have updated the docs over the years and unfortunately there are broken links here and there and from old topics. Not a lot I can do about that :man_shrugging:

If the minie library doesnt help - I’m sure someone will chime in on how to build them manually.

@jayfella: Thanks !!

i’ll check out minnie tonight. Basically i just wanted to run some examples to get started on advanced topics as they are a great way of learning how to implement things the ‘jmonkey’ way.

Keep in mind that things like MonkeyZone are ancient by internet standards. Coming up on a decade old or something. Definitely more than 5 years old.

The JME examples should run, though… and if you switch them to use jbullet instead of bullet native then they will run out of the box without any native code compilation requirements. It’s just one switch in the gradle build file.

@pspeed: Thanks a lot ! That’s better than trying to make a native lib work at this point ! Thought there was some way to configure this but i could not figure out how to mess with gradle config.

As a note: I did see that last commit on monkeyzone was about 4 years ago, but when looking over the code the way client/server synchronization is implemented (via PhysicsSyncManager and its different Message-types) was of particular interest to me.

You may want to check out SimEthereal which is a library I put together for real-time synchronization of objects. Overview here:

Basic example here:

Example that uses an ES (entity component system) here:

Thank you both & sorry for the necropost !

I was able to get things to work. Main issue was to switch to native libs in gradle.conf which i didn’t look at originally. It would be very helpful if this could be documented as an option in the ‘getting started’ as i think people with an OS w/ libc out of sync (libbullet) will be always struggling (f.e. CentOS) to get the demo code to work without knowing they can flip a ‘low performance but working code’-switch. Was coming back to java/gradle/maven after a few years of hiatus (switched to clojure/lein few years ago) and the amount of libs + choices + build tools was just too overwhelming to see through :slight_smile:

That said, i’ll be using the Ethereal code as it seems more in sync and much more performant w/ the current codebase. Still have to look into minnie but at this point i actually don’t need performant physics.


Great! Now maybe we can help others. Even me because I am slow to grasp some things sometimes.

Lets start here.

I haven’t commented yet because I am not sure exactly what documentation you refer to. In order to fix broken documentation, I have to know what you are referencing.

Do you mean here?

Can you pinpoint where the break down for you was in the documentation?

What is a gradle.conf? I think you mean

The reason I am asking is terminology may be different for different OS and I am on windows so I am unsure.

Maybe this is where it should be made clearer?

The jME3- natives .jar bundles contain the native libraries, those are necessary .dll , .jnilib , files. You do not need to manually include native libraries on the java.library.path! jME3 handles the extraction of natives automatically via the JAR bundles.

I am unsure what your fix was since it sounds like you were trying to build your own bullet and make the engine choose it but in the end you just un-commented the native libraries lines in the (gradle.conf?)?

1 Like

I don’t know of anything that’s part of gradle called gradle.conf… but nor, either. So I assume you meant build.gradle.

Yes, what gets me is how I could write that backwards and it didn’t register.

I swear it was build.gradle when I wrote it, :grimacing:

1 Like

Sorry it was build.grade of course. I was writing off the top of my head after not looking at stuff for a few weeks and not being a gradle user.

I’ll reply w/ (the proper) details tonight or tomorrow once i have some time to sit down and go through the process used to get things to work.

@mitm At the time of writing (Dec 19) there were missing links in the wiki, esp. in the advanced section (f.e. It seems all broken links have been fixed in the meantime. Thanks !

On how to build jmonkeyengine examples from git w/o, using gradle and native bullet:

Making gradle build was simple once Paul nudged me in the right direction. There is also a comment about this in the jme3-example/build.gradle file.
I had to tweak both build.gradle and settings.gradle, see following diff:

diff --git a/jme3-examples/build.gradle b/jme3-examples/build.gradle
index 7989235c4..79a6c34ac 100644
--- a/jme3-examples/build.gradle
+++ b/jme3-examples/build.gradle
@@ -24,9 +24,9 @@ dependencies {
     compile project(':jme3-effects')
     // EITHER use jme3-bullet + jme3-bullet-native OR ELSE jme3-jbullet
-    compile project(':jme3-bullet')
-    compile project(':jme3-bullet-native')
-//    compile project(':jme3-jbullet')
+//    compile project(':jme3-bullet')
+//    compile project(':jme3-bullet-native')
+    compile project(':jme3-jbullet')
     compile project(':jme3-jogg')
     compile project(':jme3-jogl')
@@ -129,4 +129,4 @@ task dist (dependsOn: ['build', ':jme3-jogl:jar', ':jme3-bullet:jar', ':jme3-and
             rename {project(':jme3-bullet-native-android').name+".jar"}
\ No newline at end of file
diff --git a/settings.gradle b/settings.gradle
index e6298b482..2fd8f7185 100644
--- a/settings.gradle
+++ b/settings.gradle
@@ -28,10 +28,10 @@ include 'jme3-android'
 include 'jme3-ios'
 //native builds
-include 'jme3-bullet' //java
-include 'jme3-bullet-native' //cpp
-include 'jme3-bullet-native-android' //cpp
-include 'jme3-android-native' //cpp
+//include 'jme3-bullet' //java^M
+//include 'jme3-bullet-native' //cpp^M
+//include 'jme3-bullet-native-android' //cpp^M
+//include 'jme3-android-native' //cpp^M
 // Test Data project
 include 'jme3-testdata'

I guess this is best mentioned here:

As to the original problem: From what i see making the build work with native libs is more a question of an up-to-date linux. Once performance matters i’ll migrate to a more recent version and i bet the build will work without problems.

Thanks everyone for the help !

I didn’t read the whole thread, but we had issues with with building jme3-bullet-native without -PbuildNativeProjects=true, one specifically needed the build target, not the assemble target.
That way you don’t have to compile from scratch.