[SOLVED] Development on Raspberry Pi 4

Pavl_G · January 6, 2021, 7:14pm

Pavl_G:

/usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so exists:
  /usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is a normal file of 3670564 bytes.
  /usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is readable

Warning , it’s a side effect from cp command

sgold · January 6, 2021, 7:17pm

Thanks. An incompatibility between the native library and your system seems like the best remaining explanation.

I’ll let you know when I have “hf” native libraries ready for testing.

sgold · January 7, 2021, 12:42am

It’s ready:

    implementation 'com.github.stephengold:Minie:3.1.0-test4'

Before testing, please make sure to delete the “libbulletjme.so” in the working directory. Just to be safe, remove the ones in “/usr/lib/arm-linux-gnueabihf” and “/lib” and “/usr/lib” also.

The new native library has the following properties, which you should verify using the “file” command (assuming it extracts properly):

libbulletjme.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=92d47f169386810517158f7c6b6616935557f103, not stripped

Note particularly that the BuildID has changed. The non-hf binary from “Minie-test3” had BuildID[sha1]=a65fb57f30b28696d3242c9173698b122d2ba7db

Pavl_G · January 7, 2021, 8:21am

Report

os.arch = arm
os.name = Linux
user.dir = /home/pi/IdeaProjects/RPI4B

original java.library.path = /usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib
modified java.library.path = .:/usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib

/home/pi/IdeaProjects/RPI4B/./libbulletjme.so exists:
  /home/pi/IdeaProjects/RPI4B/./libbulletjme.so is a normal file of 3670564 bytes.
  /home/pi/IdeaProjects/RPI4B/./libbulletjme.so is readable.
/usr/java/packages/lib/libbulletjme.so doesn't exist.
/usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so exists:
  /usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is a normal file of 3670564 bytes.
  /usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is readable.
/lib/arm-linux-gnueabihf/libbulletjme.so doesn't exist.
/usr/lib/arm-linux-gnueabihf/libbulletjme.so doesn't exist.
/usr/lib/jni/libbulletjme.so doesn't exist.
/lib/libbulletjme.so exists:
  /lib/libbulletjme.so is a normal file of 3670564 bytes.
  /lib/libbulletjme.so is readable.
/usr/lib/libbulletjme.so exists:
  /usr/lib/libbulletjme.so is a normal file of 3670564 bytes.
  /usr/lib/libbulletjme.so is readable.

Deleted a stale image.

Success!

BUILD SUCCESSFUL in 17s
2 actionable tasks: 2 executed
8:17:

without deleting files in java.library.path , but the one in the ./ dir or local dir of the app file are deleted & reloaded normally by the test case command app , so its a good impression , i will continue to test & after deleting other libs & with jme

Pavl_G · January 7, 2021, 8:23am

sgold:

The new native library has the following properties, which you should verify using the “file” command (assuming it extracts properly):
libbulletjme.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically 

pi@raspberrypi:~ $ file /home/pi/IdeaProjects/RPI4B/libbulletjme.so 
/home/pi/IdeaProjects/RPI4B/libbulletjme.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=92d47f169386810517158f7c6b6616935557f103, not stripped

Congratulations ! i think we are done & the build is successful as they have the same fingerprint sha1 , & jme can load the native library now , but i need to test this inside a game to be sure that all bullet physics functionalities work there

Thanks @sgold for this great work

Pavl_G · January 7, 2021, 8:40am

First Test Case is a successor
FPS is good , collision is good , gravity works

TestCase 2 :

Please feel free to ask for a specific test you want to try

PostScript: I have overclocked the cpu upto 800MHZ within a safe & official side :

TestCase 3 :

A Game with Physics,PBRLighting shaders , pointLights, AmbientLight , DLSR(DirectionalLightShadowRenderer) , DirectionalLights , Lighting Shaders :

with Unshaded.j3md , no DirectionalLight or DLSR , it’s good my device is 2GB , but if we have 8GB ,or a litter system than RaspiOS it would be better , i will see if i can overclock the gpu & the ram if possible in the safe side we could make a script to run besides jme for those who need a fully functioning game …>

EDIT: I have tried to overclock the GPU to below it’s max through Raspiberry pi configuration gui tool , but system kernal has been crashed so I will need time to figure out how to overclock in a safe way just not to broke my pi or the Raspibian & to benefit jme developers

sgold · January 7, 2021, 2:59pm

I’m convinced that we have Minie working on your Raspberry Pi. I’m glad our efforts are paying off.

One thing I’m curious about: in order to load the native library, did your app need to modify the “java.library.path” property, or does the default value (without “.”) work?

Pavl_G · January 7, 2021, 5:04pm

You are talking about this , donot you ? , I did not understand how you want to generally modify a jvm folder path from a local app ? Or what was the purpose generally

Anyway , it works without modifying or deleting any .so or folder

Just implementation as any normal app & everything works

I have taken this test from Android studio to intellij on my laptop & configured it for PCs then transferred the project file onto a flash drive & into the PI intellij just changed Minie from Minie:3.1.0-test2 to test4 & added the LwJGL native binaries .

Edit : shortly I will upload a TestCase on git

sgold · January 7, 2021, 7:12pm

Thank you for helping me test Minie.

Pavl_G · January 8, 2021, 6:11am

Pleasure , if you would like to make a build for jbullet or bullet-native compatible with RpIs, I could test as well

sgold · January 8, 2021, 6:20am

jme3-jbullet is pure Java. It doesn’t involve any native code. It should work equally well on any platform. In any case, I’m too busy to spend time on physics libraries other than Minie.

I might, however, be interested in modifying JMonkeyEngine to distinguish between a 32-bit ARM Linux platform with HF and one without. Does anyone have a non-HF system handy? Any ideas on how to recognize them from Java?

Pavl_G · January 8, 2021, 7:05am

So,This would involve changes in the build.gradle ?

EDIT : I think if someone insisted to use jme3-jbullet , he may implement Minie besides jme3-jbullet as Minie provides the libbulletjme.so file that’s missing so I think it may work like implementation of LwJGL natives fix the liblwjgl.so for jme

sgold · January 8, 2021, 7:07am

Not sure. It would definitely involve changes to JmeSystemDelegate and Platform.

sgold · January 8, 2021, 7:25am

Again: jme3-jbullet does not require any native libraries.

jme3-bullet does require native libraries. However (since July 2019) it uses a different native API than Minie does. So jme3-bullet can’t use Minie’s “libbulletjme.so”.

Pavl_G · January 29, 2021, 8:12pm

Hi there !

As promised , the jme test cases for arm32 devices(Raspiberrys) , full test cases including physics , shaders , materials.

NB:
-these tests work both on arm32 & amd64 systems , but you will need to delete libbulletjme.so object file with each subsequent run.

-there is a GPIO testcase using Pi4J & MCP3008 Analog digital converter(just ignore if you arenot interested).

Thank you !