in theory, java’s physics libraries can give the same result in all environments by strictfp. On a well-tuned physics stage of a one-person offline game, it helps creator to reproduce the expected results in any environment.
C ++ physics libraries can not do that.
For me, the binary level cross-platform is the strength of jmonkey.
However, jbullet does not seem to use strictfp. But using strictfp is easy.
If jbullet and bullet native implement the same API, and if jmonkey chooses a library to use depending on whether the native-bullet supports the runtime environment, it will improve cross platform. However, it does not have the exact same API, and jbullet seems too old.
The “downside” would be that you’re losing some precision for more capable platforms. Would that matter if you’re only simulating physics locally? I don’t know, but if I’m only targeting desktops, I don’t want someone’s crappy phone limiting my design. Well I’m sure it already does due to JME support, but it’s not something I’m jumping at a chance to expand on.
Dang kids with all that modern technolergy… and get off my lawn too.
Dang kids with all that modern technolergy… and get off my lawn too.
they need your lawn to catch that pokemon in game! then phone app say them to share photo when they are on your lawn on FB to get more points! and they even dont know GPS send their location into metadata.
Since we keep 2 physics libraries around, we can make one of them the default.
Currently the SDK uses jme3-bullet in its BasicGame and JmeTests project templates, but the Engine’s jme3-examples sub-project defaults to jme3-jbullet.
Unless there are prompt objections, I’d like to make jme3-bullet the default for jme3-examples.
In my opinion nowadays native bullet is a better choice. Being actively mantained is a big plus. Also I found it to be more consistent across devices than jbullet, specially from desktop to android (which is my focal point) and also a little quicker
I though someone already did after my last manual compilation… I may help with that
As a side note… is there any reason why openCL is not being used at all for both desktop and android bullet native? I don’t know the inners of the library but if that may improve performance it could be something interesting to look at while minie is not default in jme
The only downside is getting bullet-native to run on arm linux (raspberry pi), for example, where jbullet would just work.
If we had the manpower and wouldnt be years behind, we should have our own jbullet fork maintained. And if it’s only to spot bugs in either implementation
I had it too. Without that line of code bullet just start acting up after some time. Forces are ignored, collisions don’t happen. It just renders it unworkable.
We had it in Monake as well: Fix Physics, ez-pz · MeFisto94/Monake@f562ad1 · GitHub
Unfortunately it’s not a good test application as you are missing the assets (licensing) and I don’t remember what kind of problems we had, it was either: Walking speed was capped, you couldn’t get any faster for some reason, ghost collisions not happening or falling through random planes.
Don’t ask me if that is expectable or maybe related to precision, CCD or whatever, but this could be experimented with a test as well (a capsule whose physics rotation is basically camera.getLookAt())
they need your lawn to catch that pokemon in game! then phone app say them to share photo when they are on your lawn on FB to get more points! and they even dont know GPS send their location into metadata.
