I have read that we will be moving to native bullet (the c++ one? ) in the near future.
What does this mean for existing abstract controls like GhostControl, CharacterControl and VehicleControl? Will they be gone? If yes, are there alternative “high” enough abstractions in native bullet?
Nothing will change for the user.
1 Like
Thx. Will that have better performance instead of using jbullet? Or do you want eliminate the dependency to jbullet?
Performance might be a little higher due to c++ beiing a little faster(and bullet being a bit better optmized, jbullet uses as far as i know still some outdated algrithms), the huge kick comes as soon as native bullets goes completly to gpu ( they have some really impressive demos so far)
1 Like
The performance of the available CPU code is the same in jbullet and bullet. But bullet will be using GPU acceleration for softbodys and other things soon. Since not even softbodys are in jbullet yet I strongly doubt we’ll ever see these advancements in jbullet. And yes, I want to remove the jbullet dependency and benefit from the bullet development directly.
1 Like
@nego new features like, constraining applied force on a certain direction will be available on that time too. 
@normen will the OpenCl acceleration be available?
1 Like
Thats what I mean by GPU acceleration yes ^^
1 Like
yeepii 
Thx all for infos!
Has anyone bench-marked the native bullet library vs jbullet? From my experience, the JNI overhead is pretty severe. Occasional native calls might be negligible, but I would think having many JNI calls per frame would crush the framerate. If you’re seeing similar or better performance, I’d love to know how you’re achieving it. (I’m really curious to know how LWJGL overcomes this too, as it seems pretty speedy)
Uhm, java itself uses JNI, I cant quite follow you here…? JNI isn’t slow.
From very primitive tests … native bullet seems to be twice as fast as java bullet
Momoko_Fan said:
From very primitive tests ... native bullet seems to be twice as fast as java bullet
Note thats through the updates in the native bullet as opposed to java bullet (=bullet 2.76), the performance difference of jbullet vs its counterpart native version was just about 1-3%
normen said:
Uhm, java itself uses JNI, I cant quite follow you here..? JNI isn't slow.
There's absolutely overhead with invoking native methods. Depending on your use-pattern, the overhead may or may not be excessive. The issue with what I'm working on is that the JVM uses a mechanism similar to reflection for calling Java methods from C/C++ (which I was unaware of until recently). I (wrongly) assumed that
env->CallVoidMethod type calls were just as fast as calling the method in java if the class and methodIDs were cached. I wrote a JNI layer to the V8 javascript engine. I intended to use this to build a scripting engine in jme3. The performance I'm getting is not what I expected. Executing javascript code is lightnight fast, but when you push Java objects into Javascript and have accessor or java method invocation callbacks from Javascript, it slows down dramatically. This is considered the "Call-Invoke" pattern, described more here: http://java.sun.com/docs/books/performance/1st_edition/html/JPNativeCode.fm.htmlIt's rather disappointing as I implemented a fairly large portion of the V8 api and I've got working proof-of-concept code. It's not exactly slow, but I was hoping to achieve high frame rates while executing Javascript with lots of Java callbacks into java.
What you are explaining (env->CallVoidMethod) is not “invoking a native method” but its the exact opposite. Again, java uses the exact same JNI interface to do all its native operations. Accessing java fields from native (which is done in the jme3 native bullet api to apply values to java objects) is also not very expensive given you cache the created native references.
Let’s bring some scince in the guesses:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109.5174&rep=rep1&type=pdf
As this shows jni needs time, yes however you can kinda decrease it (like exception handeling overhead)
After all, if you have a native function that takes no time to use, then there is the question why to use a native at all and not use plain java.
(Also a script engine could be written completly in java , since you can dynamically compile new code at runtime and load it.)
normen said:
What you are explaining (env->CallVoidMethod) is not "invoking a native method" but its the exact opposite. Again, java uses the exact same JNI interface to do all its native operations. Accessing java fields from native (which is done in the jme3 native bullet api to apply values to java objects) is also not very expensive given you cache the created native references.
That's not what I said. Please read it again: "for calling Java methods from C/C++".
I'm already creating global references for caching the class and methodIDs. I didn't claim accessing fields was expensive. I stated that invoking Java methods from C++ was expensive.
aaron said:
There's absolutely overhead with invoking native methods.
I was assuming you mean "native native" not "java native" ^^
Us jme3 native bullet implentation doing a lot of C+±>Java calls? If not, then there is no point in discussing their speed at the moment. In ‘normal’ direction (Java->C++), bullet JNI access is hardly going to be visible on the radar compared to amount of JNI calls needed for opengl rendering.
I still think jbullet had it’s strenghts (debuggability), but given the maintenance overhead, native bullet is probably only sane way to go forward.
And yes, JNI is slower compared to normal java calls - not only because of argument preparation overhead, but also because hotspot is not able to inline/do constant propagation, gc interactions become complicated etc. Still, it is probably fast enough for APIs like opengl, where you should work with huge batches of data, processed by GPU.
Calling a method from native is, so one only needs to avoid doing that excessively. And as I indicated thats how the native bullet library of jme3 is done.