@oxplay2 I’ve rebuilt the Linux native libraries on Ubuntu 14.04 (Trusty Tahr) using GCC version 4.8.4
If you have the time, please test again on Centos 7:
git clone https://github.com/stephengold/Minie.git
cd Minie
git checkout -b latest 8509bca9
./gradlew build
I’ve belatedly added a 3rd variant: 1.5.0+debugfor33
This variant is identical to 1.5.0for33, except that its native libraries were compiled with the -g3 and -D_DEBUG flags (or their Visual C++ equivalents). In other words: include C++ assertions and symbol tables.
These features enlarge the JAR by about 3x. They also cause applications to run somewhat slower. However, I’ve found them very helpful for catching software bugs.
Centos 7 still don’t work(same issue):
$ ./gradlew build
Starting a Gradle Daemon (subsequent builds will be faster)
Task :MinieAssets:models FAILED
Exception in thread "main" java.lang.UnsatisfiedLinkError: /######/_TEST/Minie/MinieAssets/libbulletjme.so: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /######/_TEST/Minie/MinieAssets/libbulletjme.so)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1946)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1828)
at java.lang.Runtime.load0(Runtime.java:810)
at java.lang.System.load(System.java:1088)
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:685)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:159)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:442)
at jme3utilities.minie.test.models.ImportCgms.main(ImportCgms.java:104)
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':MinieAssets:models'.
Process 'command '/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/bin/java'' finished with non-zero exit value 1
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org/Regarding Centos 7 support, I’m currently stuck.
I was hoping to build with G++ 4.7 and Gradle at Travis. I can install the g++-4.7-multilib package and configure update-alternatives so that Gradle actually utilizes it. But then the build fails with:
/usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory
For now, Minie requires CXXABI_1.3.8 in order to run on LInux.
like i said, Many users still use Centos 7, because Centos 8 is like month ago release(Very Fresh).
and even later there might be.
Centos 7 use very stable and very old libs, thats main problem.
We can skip Centos 7 support, but i dont know what to feel about it. Hope at least other distributions will work well (not just Ubuntu/Centos 8)
If you really cant fix it, ok, i will understand it.
Anyway this is very little % of users. So what is really required, is Windows 7/8/10 issues related with Java versions. Windows is really required here. (i hope Windows will work now, will let you know when verify)
The top priority for the next Minie release is portability, so I’m very glad to finally have a fix for the Windows issue committed to Minie’s master branch.
Currently every push to master gets tested in 9 environments:
@oxplay2 After getting some rest, I worked around the errno.h fatal error. Now I have another commit for you to test on Centos7, when you have an opportunity:
git clone https://github.com/stephengold/Minie.git
cd Minie
git checkout -b latest 7bf80914
./gradlew build
Great awesome work!
BTW.
The Windows issue was caused by a typo in the C++ glue code:
JNIEXPORT jlong JNICALL Java_com_jme3_bullet_objects_PhysicsSoftBody_getMaterialId(
[…]
return reinterpret_cast<long> (pMaterial);
jlong is always 64 bits, but on Windows long is 32 bits. So the upper 32 bits of the material ID were set to 0 (by sign extension).
Reproducing the issue took months, mainly because it only occurs on Windows and I work mostly in Linux now. I didn’t see it on my Windows system because I had Java 8 installed there. (In Java 8, pMaterial had zeroes in its upper 33 bits.) In the end, I reproduced it by writing a (headless) JUnit test and running it on a GitHub Actions runner.
After reproducing the issue, I debugged it by adding printf()s. A search of the source code revealed a couple other places where someone accidentally typed long instead of jlong.
The Centos 7 issue was easily diagnosed. The challenge was compiling (and linking) the Linux native libraries with a sufficiently ancient version of GCC—one that doesn’t use CXXABI_1.3.8.
The oldest Linux environment at Travis is Ubuntu Precise 12.04, but that hit an SSLException while trying to install Gradle. The 2nd-oldest Linux environment is Ubuntu Trusty 14.04, which includes GCC 4.8—not old enough. Installing GCC 4.7 on Trusty was easy, but convincing Gradle to actually use it (instead of 4.8) was tricky. An update-alternatives command should’ve been sufficient, but it wasn’t. In the end, I added a symbolic link:
sudo ln -s /usr/include/x86_64-linux-gnu/asm /usr/include/asm
jlongis always 64 bits, but on Windowslongis 32 bits
crazy… lol. im glad i were doing JNI only for linux and was no need to do for windows, would probably have same issue.
BTW, i seen there are better APIs than JNI now, maybe worth look at when doing new libs support.
Also a question:
Even after 30 years of standardization efforts, writing portable code in C++ is surprisingly difficult. In C++, a long can be implemented as 32 or 64 bits and an int can be 16, 32, or even 64 bits. So any code that declares an int or long variable is potentially non-portable.
Working in C++ increases my appreciation of Java.
The Bullet Physics Library.
It has included soft bodies since version 2.68:
Bullet 2.68 Physics SDK released: Soft Bodies and iPhone support | Bullet Real-Time Physics Simulation
Just a thought, would you ever consider basing Minie off jBullet? And then you won’t have to go through the effort of platform compiling with C++ bullet.
Right now it kinda sounds tough to keep up with Minie.
Minie is 100% committed to using native Bullet.
Well I continually applaud the effort you put into managing Native C++ 
So @sgold, had a question regarding jME4 and a new physics engine.
So as you know there are a lot of monkeys here hoping to work on jME4 project. And I was curious about how the physics would be handled for jME4. So as you know, on Trevor’s roadmap is adding Vulkan support, as well as a new physics engine. Lately when I’ve done research on Bullet, they seem to bring up “OpenGL” a lot, leading me to think that physics engines might be exclusive to render API exclusive. So please inform me, is Minie renderer agnostic? If its not, about how much work would be needed to support Vulkan?
Let’s try to keep this digression brief. (I wish you’d started a new Forum topic for it.)
Bullet’s example browser uses OpenGL extensively. However, Minie doesn’t have anything to do with that browser, so there’s no dependency there. The parts of Bullet that Minie uses are all renderer-agnostic.
Nor does Minie invoke OpenGL directly. Minie’s only use of graphics is for debug rendering and examples. Those functions go through jme3-core’s graphics API, using meshes, materials, scene-graph nodes, cameras, and viewports.
To the extent that the graphics API changes between JME 3.3 and JME 4, Minie might need to be ported. Since I haven’t seen any API specs for JME 4 (nor a working prototype of its support for Vulcan) I can’t scope out that port.
By the way, Minie also depends on jme3-core’s cloning and serialization APIs. If those change in JME 4, the porting effort could be substantial. (The serialization API is closely intertwined with the J3O file format.)
I look forward to seeing either
I’ll make sure I start new topic for major changes.
I think everyone here agrees to keep jME4 to the greatest extent possible, very similar to the current jME.
That’s a while away, not much has been done yet, mostly testing.
Thanks for informing me.
Hi @sgold
A question, why a new collection is instantiated in these getters instead of just wrapping it inside an unmodifiable collection Collections.unmodifiableCollection() ?
And a suggestion, it will be useful to add a method PhysicsSpace.getNumCollisionObjects() to get the number of all objects in the physics space.
Any thought?
Regards
Because the idea hadn’t previously occurred to me.
Much as I’d like to re-implement those methods using unmodifiableCollection(), I worry that doing so might break someone else’s code. I’ll add this to my TODO list for Minie v2.0.
Why not use countCollisionObjects()?
Oh, my bad, I did not notice that method. Thanks