Let’s discuss why JME has 2 official physics libraries and whether this situation should continue.
Advantages of JBullet:
Advantages of native Bullet:
anyway i feel like native bullet is out of Java memory restrictions because it use JNI, so imo Advantage of native would be also “skip Java JVM memory restrictions” that follow with next “save java memory for app”
im not against jBullet, idea is nice, easier to maintain, but its totally outdated currently.
In my experience, native Bullet scales to large numbers of active physics objects in a small area much better than jBullet does.
Using jBullet serverside is definitely safer, but the extra overhead is a concern for me - server CPU usage comes at a premium, especially if you’re hosting many instances on a single server. If native bullet proved to be a stability issue serverside, I would probably opt for running physics in a separate process and syncing via a high-performance IPC mechanism (which has the potential for latency issues depending on what is used - it’s a possibility for ensuring server stability, but it’s hardly a silver bullet (no pun intended!)).
I don’t know who is using jBullet or for what purpose. Personally, I’d lean in favor of deprecating it.
What JVM memory restrictions are you thinking of? It’s easy to increase the Java heap size. Or are you worried about overhead and lag caused by JVM’s garbage collection?
JBullet supports “custom shapes” which can be implemented in Java. I believe that native does not support this. I guess to do the same with Bullet, it would need to have callbacks into Java code via JNI. The overhead of doing that for those purposes seem like it’d be pointless.
There was an old project posted here which used JBullet that “broke” once native Bullet was introduced, due to it relying on custom shapes. I’m not sure if it was fixable or not, but the author didn’t seem to think it would be easy (or possible) when I inquired.
I’m going off old memory and I’m not well versed in Bullet integration so I could be mistaken here.
Ah, found the project:
For the record though, I don’t use JBullet for anything currently, only native. I’m just not a fan of losing options, unless it’s really necessary. I’m sure there are some use cases where JBullet works out better, and some where native does…
Edit: Ha! I just fired that up in JME 3.2, after some shader config fixes, it still works. With JBullet, though.
What JVM memory restrictions are you thinking of? It’s easy to increase the Java heap size. Or are you worried about overhead and lag caused by JVM’s garbage collection?
yes, you are correct, but i seen for example that Windows 32 bit can use only 2 GB whatever you will try set. That was what i red earlier when i was learning more about JNI.
i see some topic about it, they say its trully 4 gb anyway (so seems fine)What is the maximum Heap Size of 32 bit or 64-bit JVM in Windows and Linux?
Also i belive there might be user restrictions in JVM setup over game startup setup too.
Anyway IMO its much safer to use memory out of JVM for physics(same like it is for openGL), so other memory inside JVM can be always used by game developer.
edit:
i just see other issues like:
" Why Linux or Solaris allow more maximum heap size than windows for same, 32 bit JVM?"
or
“Can we set more than 4GB as maximum heap size for 32 bit JVM running on 64 bit or x64 operating system?"”
i think there might be even more things we dont know about JVM memory manage
Also anyway, why drop jBullet? it can stay as it is, do you need change native so much to drop jBullet? i thought about just add jm3-bullet-minie lib, thats all and update jme3-bullet to have changes required for minie.
I used jbullet up until recently because it was the only thing that worked on 32 bit Windows… and I still had one or two of those.
Native bullet has a pretty killer bug, actually. I was not able to track it down in the C++ source code. The work-around is to force fixed time steps with no smoothing… else you get really random results when the real time step is very close to the physics time step resolution. It’s like applied forces go bonkers or to zero. Bad news.
Also, this is at FUD level because I cannot point to anything specific, but I feel like I got a core dump once or twice with native and obviously never got that with jbullet.
That being said, if I were to deploy a bullet-using game today, I’d probably use native bullet with a fixed time step. I have no strong reason for that as performance seems to be identical to me but I’m also a victim of all of the “native is faster” prejudice. Hard to shake.
Native bullet has a pretty killer bug, actually. I was not able to track it down in the C++ source code. The work-around is to force fixed time steps with no smoothing… else you get really random results when the real time step is very close to the physics time step resolution. It’s like applied forces go bonkers or to zero. Bad news.
@sgold fixed many things, maybe this too? what was this exactly? this NaN physics location that appeared?
edit: even when i tested Minie i remember @sgold fixed some earlier default issues.
It’s deep in the C++ code somewhere. Forces would be applied scaled strangely… whether set on pre/post physic ticks, etc… Didn’t matter. Only happened when calling physics update with a real time step close to the actual time step.
Edit: I don’t think sgold has fixed bullet C++ code. I could be wrong but I didn’t see any commits in that repository at the time.
it it possible to replicate it somehow? could test if @sgold already fixed it, if not, then if he would have time and want, he might want to look at it, because it sound serious, and i think i know what you mean because i had this issue myself, but i dont remember now if it was solved when using Minie libs and i dont have that code to replicate. (Anyway i trust @sgold knowledge, and prefer using native libs that will be updated - i think we just need report to him issues like this)
I don’t think that using off-heap memory is “safer” in any sense - quite the opposite, really, and the risk is rarely justified except in very special circumstances. The only “safety” you get is that your app gets to use most of the JVM heap space - but if it’s running out of heap space with physics objects on-heap, it might also run out with them off-heap. The only way to deal with this is test what you use in practice and set JVM memory arguments if needed at runtime - regardless of where physics allocations happen.
The risks, on the other hand, are plentiful - you lose out on the memory safety the JVM provides and leave yourself open to a host of memory corruption, leak, and security (granted, security is not as much of an issue with games) issues that you wouldn’t have to otherwise deal with (and memory issues are often very subtle and difficult to debug). In addition, running native code (since we’re on that topic) means you have a decent chance of a hard crash without any diagnostic hints - also a non-issue in Java-land. Fortunately, Bullet seems to be quite stable, and in my mind the benefits of running native Bullet outweigh the risks, especially considering the feature set difference between jBullet and native Bullet.
Regarding the 4GB limit on 32-bit, it doesn’t matter if you’re allocating on or off heap - a 32-bit process can only address 4GB total, regardless of whether the JVM or native code “owns” the allocated segments. There’s no way around this no matter how you divide the on/off heap allocations (short of running special PAE OS kernels, which always seemed to have some issues). Fortunately, this is a virtual non-issue now with 64-bit being standard. It will take us a while before we have to worry about 64-bit memory limits. 
yes, i know safer is wrong word, anyway its better to get more performance.
memory issues are often very subtle and difficult to debug
is this only JNI related? if not, then would also tell any C engine is unstable 
i developed in JNI, im not C master, but needed some wrappers, and i dont had much problems debuggind the issues. You are correct in C need to care about memory manage, but i belive native Bullet dont have them, and @sgold will not add memory leaks/corruption.
based on all you said its like telling “Java is better” and overall i agree, but in some cases like here C is better IMO
Not a bit. I’ve noticed that no matter how much care is taken on a C project, memory issues inevitably crop up sooner or later as it grows. The best you can usually do is code very, very defensively and fall back on good memory shells and monitor tools such as Valgrind. The situation is quite a bit better in C++ (especially modern C++ with smart pointers), but it’s still a minefield you just don’t have to deal with in Java. C/C++ can be perfectly stable, but it’s much harder to do than in Java and the likelihood of subtle errors increases substantially as the codebase grows. While I haven’t personally worked with JNI specifically, in my experience on other projects (such as mixed Python and C++), bringing a GC into the mix only adds to the likelihood of trouble since the GC can free things that are still visible from the native heap. If you can always use “safe” patterns (I.e., the native code never retains pointers to managed objects) you can (as you’ve found) go some time and be quite alright - but not all projects can easily simplify things to safe patterns all of the time.
I wouldn’t say so much that “Java is better” as I would say that “Java provides many benefits that native languages can rarely compete with.” Having spent plenty of time in both C++ and Java, I’d take Java far sooner for virtually any project I can think of doing. Regarding physics calculations, the JVM has very competitive numeric performance - but unfortunately for us, the actively maintained version of Bullet is in C++. If we don’t want to start any huge re-write projects (which don’t seem remotely justified or productive in the circumstances), we have to shrug and accept using native Bullet.
Like pspeed I believe I’ve seen a (rare) unreproducible dump once or twice, but I could have been doing something a little too wild… are we the only ones to ever see that with native Bullet?
thanks @danielp for explain.
jme3-bullet is not a small project, not a big too, its all up to @sgold who is the one taking care of physics now.
trully, if he would expand jme3-jBullet, i would use it anyway, because there are not so much differences. But we are still back to main topic.
The Minie lib use extended/fixed jme3-bullet-native to make Minie work with this physics. Making same changes for jme3-jBullet would not be just a copy paste but deep rebuild of both Minie and jBullet code, but thats what sgold could say how hard it would be to update jBullet.
recently was told jBullet had no sourcecode, but it was provided and we have sourcecode of it, so if there would be anyone who would want update it, its possible.
But still we got only one person who make physics for us, so we need bless him and do not add even more work for him. If its only for native, then lets use it.
Ofc i dont say own opinion to drop jBullet, it could stay as it is, just would make jme3-bullet-minie to work only with native, thats all. This topic is overall advantages and disadvantages, i dont see anything about drop jBullet for now, but i feel it was intended to know our opinions to stick only one physics.
Both have advantages and disadvantages ofc, but the main advantage of Native Bullet that was not mentioned as point here is:
i belive i understand topic intention, but i see alternatives all the time. Even if lets say, cant use native-physics and upgrade it to work with Minie features, i also see new alternative like creating totally new package jme3-minie with updated jme-physics and all features from Minie, while jme3-bullet-native and jme3-jBullet would stay intact to not break other people physics.
but i hope updating current one is not that problem.
I’m ignorant on this aspect of the problem, and sorry if this was already posted somewhere, but what precisely is stopping both Native + Minie JME integration while JBullet is still supported?
If the basic problem is that JBullet doesn’t have API to cater to new features, can we just have it throw an “UnsupportedFeatureException” or whatever if someone attempts to use it for something unsupported, and document what JBullet can’t do?
Is no feasible compromise possible? It’s nice to have options…
thats what i also thought, already suggested this, but seems like there were some “problems to solve” i dont remember or was never told. anyway my suggestion was failed.
i just see responses like:
so i just belive there is something that block it.
If there’s still interest in jBullet and we have the sources, what about at least sucking them into the jME repo? I’m not familiar enough with the interfaces to comment on the difficulty of dual support for both via the same interface, but even if the interface had to fork I don’t think multiple options are a drawback if folks still have a lot of interest in jBullet.
Similar thoughts here. I’ll refrain from speculating and lengthening this more until someone with more facts wants to chime in. It might be a fun project, but it’s hard to guess what the scope and difficulty is. I don’t know what the interest level really is, either.