I’m not trying to rain on anyone’s parade, neither am I intending to denigrate all the awesome work here, but is the sheer overhead that the jme has too much for the standard Android device?
As a test I made the class jmetest.TestBoneRagdoll as a stand-alone application.
The source is here (I use eclipse): -
http://www.egonomics.com/android/jmetbrd.zip (5.1 MB)
The libraries needed for this are: -
. “engine/dist/opt/android/jMonkeyEngine3.jar”
. “engine/dist/lib/jbullet.jar”
. “engine/dist/lib/jME3-jbullet.jar”
. “engine/dist/lib/vecmath.jar”
so unless you have the exact same path as me, you’ll have to locate them in the application properties.
And the apk is here: -
http://www.egonomics.com/android/TestBoneRagDoll.apk (5.4 MB)
Again, not trying to be awkward, but I’d guess the jme developers didn’t have portable devices in mind during its development. Perhaps its like retro-fitting a V8 motor to a push bike, even if you could do it you just can’t get out of the motor what it was designed for - the bike just can’t handle it (yet).
So I ask, is this viable or just a fun experiment? Running on my phone (Huawei Sonic U8650) the FPS is 0, that is, the screen refreshes at most every 2 seconds, so FPS is < 0.5
Also, my screen times out before its even loaded (take 75 seconds to load).
How is it for others?
Cheers Jonathan
Ps. I had a friend with a HTC EVO 4G just test it, currently that’s a high end android, and it crashed on their phone, so that’s scary, and sadly no FPS to compare to.
Galaxy S. Android 2.3.4.
Working for me but very very slow. App takes 30 seconds to load, average of 1 FPS.
Thanks for sharing.
++
dherby
The bad performance is solely due to jbullet running on android which is missing a proper jit compiler, its lots faster with native bullet (which will be used by default on Android when its done)
Isn’t jbullet just for physics? Couldn’t you make a build without physics support?
(please excuse me if I’m wrong, I’m very new to jMonkeyEngine.)
Yea that’s what I thought too normen, I know its all done via translation and interpolation, no native driver - so jME is good for all but jbullet then? Until a jit is written that is.
I’m guessing “when it is done” indicates a work-in-progress 
Yup mikehill2003, you most certainly can - only it’s jbullet that I am currently looking at for myself.
If for nothing else, I’ve provided a working solution of jME in Android for newer people!! >.<
Wait android has no jit compiler ? Why??
I mean most android phones are faster than my netbook, so it cannot be the performance of the jit O.o?
@mikehill2003: Just don’t use physics until its native…
@jawfin: Yes, the rest of the rendering engine works with great performance on android.
@EmpirePhoenix: Yeah, google really needs to get their act together to avoid further native/java fragmentation of the platform. Many libs (and some apps) are native because of this.
normen said:
Just don't use physics until its native.
Sorry to bother, but is there a time scale on this? :P
:yawn: Yeah, after the first release, e.g. 3.1… You can use native physics (minus collision callbacks and with some bugs) already tho, you’d just have to compile the android/ARM binary yourself:
http://hub.jmonkeyengine.org/2011/04/27/jme3-native-bullet-physics-is-available-for-testing/
kk, thx
I test your .apk file on my HTC sensations Phone. Below is my statics:
load time: 51 seconds (PS: since I press the Test Bone Rag Doll icon)
FPS: 1 (@@ very slow)
and when I press back button, it doesn’t work, I face same problem with this, I guess that maybe needing add some code in onDestroy() or onPause()
I was testing disabling that alert dialog in the AndroidHarness so if this was used practically, you could put your own code there instead of a dialog - so pressing back should of just terminated the application.
If Einnor releases his binaries as requested by mike griffin here, then I’ll re-release this with native libraries. Unless norman, if you have it compiled, will you share?
Its beyond my current ability to compile bullet as ARM with NDK for Android - I’m still new to Java and Ant etc etc is beyond me - that’s from over 15 years programming in Delphi !!!
Who’s Norman? Anyway I don’t have an ARM binary if that was the question.
jawfin said:If Einnor releases his binaries as requested by mike griffin here, then I'll re-release this with native libraries.
I've sent him an e-mail. Hopefully he'll get back to me shortly.
Edit: He replied. Einnor will do a more elaborate post some day very soon, stay tuned!
Doesn’t allready have Android 2.2 a JIT compiler ?
http://en.wikipedia.org/wiki/Dalvik_(software)
Edit: I saw Normen said “a proper JIT compiler”. I leave the link here for your information.
A proper JIT compiler ^^ If jbullet is slower than native bullet it obviously doesn’t work as well as the desktop ones.
Things like physics, animation, particle update, and other intensive algorithms must be implemented using native code or run on the GPU. The JIT in android will probably never be good enough to run those in real time and until recently even the desktop VMs had issues with it.
Since Android support is currently alpha we haven’t gotten to implementing those algorithms in native code yet
Thanks for all your help here guys. I feel like I’m taking more than I am giving (which at the moment is because I am). Would such a project be done? That is, implementing a physics engine in native Android code? And if I’m not being too rude, is there a timetable for this? i’d love to help, but here I feel I am out of my depth… I know a lot about 3D graphics, but I am not a C programmer - not since university which was 20 years ago 
Again, the native bullet renderer exists already, it only lacks collision callbacks at the moment. Whats needed is a proper build script for an ARM binary.
http://hub.jmonkeyengine.org/2011/04/27/jme3-native-bullet-physics-is-available-for-testing/
Pretty sure that other game engines had success porting Bullet Physics to Android. There are probably a lot of articles online about this, there might even be a build available. Still jME3 has its own binding that connects Java → C++ and that one will still need to be recompiled for ARM