The source code contains the JNI files that I have modified (just a little), you can delete those if you just want to play with the native library.
The native is not working for collision detection (JNI callback fails and I did not have time to look at it, I improvised using the other collision detection in Java, works and it slows down just a little)
Ragdoll is not working properly.
Vehicle crash the system so far (I did not have time to look at it)
Usage
1.The native library (libbulletjme.so) should be included in a folder called libs
2.To load the native library, You need to include:
[java] static {
System.loadLibrary("bulletjme");
}[/java]
in the class that extends AndroidHarness.
If you ever get Unsatisfactory Link error, likely wise is that Android fails to load the libaray
Everything else should work as it is in native bullet.
To run the sample remember to include the following library:
JMonkeyEngine3.jar (Andriod version, located in /dist/opt)
jME3-bullet.jar (the jar containing class that binds with native bullet, located in /dist/native)
jME3-test.jar and jME3-testdata.jar for testing purpose
Compiling Native Source
I have compiled the native binary for armeabi and armeabi-v7a.
And for me the .apk is corrupted - the phone won’t load it and WinRAR (as it is a zip file) says “Unexpected end of archive”. The file size for me 27,052,771 bytes, if that helps.
Once I get a chance to work these libs into this application I’ll do so - but we can’t expect too much if ragdoll isn’t working fully for us yet!
Also, does it matter which library I use? I’d assume I use the latest v7a unless I need both - or the latest has bugs.
And checking the timestamps on these files shows us that einnor was working on this at midnight!! So thanks again for this
Sadly as expected it doesn’t work with ragdoll. The app closes once the model is loaded. I can’t get a logcat as Huawei cripple their OS and prevent that feature (perhaps in a vain attempt to stop us from rooting it - and yet I rooted mine…) and as there isn’t a custom ROM for U8650 I’m blocked from helping further here
But hey, Android is Viable
einnor’s app runs at 2 FPS for me, but it seems a lot faster. Oh and for me the shadows are solid and big and seem to be in the wrong places! I can pitch in again once the smarter guys have bullet running fully!
Final question, any reason why you’ve set the min SDK to 9 and not 8? (2.3 not 2.2)
No particular reason, the JMonkey need OpenGL2.0 ES to run which means that it is suited for Android 2.2 or later. But given the fact that 3D Game engine itself is pretty resource intensive, I just want to play safe.
Oh, shadow are not working properly in Android version, I turn them on just to load test the system.
einnor said:
A Sample of Native Bullet on Android JMonkey
Just something that I want to give back to the community.
Very cool, do you think you can somehow work the build process for this into the current ant build script for the native binary? Otherwise I guess you will have to compile the arm binary for us on each change ;) The issues you mention are known issues of the native bullet implementation not specific to android and will be fixed when the native library goes for release.
I am not familiar with ant when it come to Android because all the compilation script is done in Android.mk and Application.mk.
As I will be away from mid of this month and would be working on another project on IOS, I may not be able to commit the time to explore into this area.
einnor, I downloaded the source, but did not see the JNI folder inside the source. Could you post those as well or did I miss them? I’d like to see how you modified the JNI files. I was just starting to try to compile the JNI files provided with JME but was having some compile errors with ndk-build.
I will try to pick up the set of files that I have modified and do a post. The changes are very minor. If my memory serves the modification affects 2-3 files with just a few statements.
I’m getting 70-80 fps on Android 2.2 Samsung Galaxy S on the Brick Wall and shooting balls demo which far surpasses the 10 or so fps using the non native jbullet.
This is definitely worth getting out as a proof of concept.
@einnor - I noticed the apk is 30 meg in size which is pretty large for an android deployment. This is mostly the jme3-testdata.jar file containing assets and textures which probably aren’t even used for the Test Wall so it wouldn’t be difficult to cull this right down to the barebones.
Hey I didn’t read the entire thread, just a few posts. But here’s my two cents: JME is excellent for PC, really I haven’t found anything more straight forward. But when it comes to android I had to completely scrap jBullet and use only JME’s basic collision detection. Ray casting to put characters on terrain for example.
If you want to develop a 3D world in that sense, I found another engine to run much better (75-80fps vs JME @ 55-60fps) it’s include size is <~500kb.
the frame per second state is the same program more or less ported between the two engines. Not much of a load bearing in either instance.
So as it sits I think JME for the overhead is very impressive. Considering how much easier development is, especially GUI.
My point was if you wanted to create a game as basic as it gets (ie controlling collisions with basic ray casting, building basic GUI implementation, basic shading, basic terrain, all systems your must implement yourself) then yes there are alternatives. But I created a program that ran as close to identical in both engines. (obviously they rendered a little different because of JME advanced graphic standards) The result was a a slower compile (duh) and a few less frames. Impressive. JME with all of it’s convenience was not far off that very basic engine.
I haven’t tested JME on android with native bullet, sorry for using that as a comparison. 30 frames on a ragdoll is very impressive,
