I’ve noticed that android physics don’t work correctly at least for vehicle control (fancy car test) . The behaviour is the same as in jme3.1 in which the car just vibrates. In this case everyone in the forum adviced to use jbullet instead of native but that’s not an option for android or at least a performant enough option.
I’ve been having a look at jme3-bullet, jme3-bullet-native and jme3-bullet-native-android and I’ve found that last 9/aug all desktop library binaries (libbulletjme.so) where updated (commits e12261e, ec6c32e and 8f1316c) and also some code was changed to update bullet to 2.86.1 (Update bullet to v 2.86.1 by riccardobl · Pull Request #698 · jMonkeyEngine/jmonkeyengine · GitHub) but android binary libraries were not changed.
jme31 was released before these changes.
Maybe just by re-compiling the libraries with the updated code and update them in git would be enough for it to properly work.
I would do it myself but I’m not sure which would be the code to compile, if it’s the jme3-bullet-native or something else.
In adition I’ve been having a look at the jme bullet builder (https://riccardobl.github.io/jme3-bullet-builder/) which I’m not sure if it’s the way libbulletjme.so libraries are compiled nowadays, so updating it to add android ndk compilation would suffice…
I’m not on my pc right now but the problem is the suspension settings and how they work. When you alter the stiffness you also need to set the dampness and rebound because they co-depend on each other.
Rebound and dampness are calculated by
v = k * 2.0 * FastMath.sqrt(m_suspensionStiffness)
Where v is dampness/rebound and k is the effect force.
Mass also has an effect, as does maximumForce. It is un-useable with invalid settings, but when you are working in the correct ranges it becomes apparent quickly.
It does take a bit of fiddling. A debug state is… Inevitable.
The weird stuff is that default fancy car test works properly using jbullet (both android and desktop - had to modify nbproject/mobile-impl.xml to avoid jbullet to be overwritten with native android bullet) and desktop native bullet but not in android native bullet.
I’ve changed values of stiffness, compression and damping and even used Bullet Vehicle problems - #19 by Martin_Watts as a reference without any success… That’s the reason for my assumption (which could be wrong) of some update missing in the android part of jme regarding physics…
It would be great if you have some values working on android, thanks
Quick update, I finally managed to re-compile android native bullet (same release as desktop) using ndk17 and I integrated it with my testfancycar test app and it works properly with my compilation
Just as a follow up, the default settings “should” work (as defined in the test case). Having said that, I have recorded and mentioned previously that android-native does behave differently to the regular native. Maybe your findings are the reason why.
From my point of view it sounds reasonable that having different versions of bullet in desktop and in android could generate problems… So although I’ve not had enough time to test all bullet jme tests (all I’ve tried so far work flawlessly) I’ve uploaded the changes to my github fork and requested a pull request
Problem is that the Android stuff is out of my realm of understanding since I have never used it. I can make some minor tweaks as follows but anything more will require someone with a detailed understanding.
This is missing from the source structure table on physics.
As you can see, it already explains only one version of physics can be used at a time. I can add this to the table.
Later on, in this same doc, it could be mentioned here.
Forgot to mention, these changes may not be seen unless there is a top level wiki page on Android with links to the various setups, Eclipse, SDK, Netbeans, other.
Thats fine - I can do it, or at least the majority.
I dont think any of the linked pages relate closely enough since this tutorial is for Android Studio/Intellij - so should probably be in a page in its own right in my opinion.
As far as I know, there is no “bullet-common” anymore.
@joliver82, could I trouble you to recompile the binaries in your PR? The motivation would be to pick up changes to libbulletjme.so since 30 May, including fixes for issues 911, 913, 918, and 919.