My physics and (real) math days are far behind so I’m probably little use, but what kind of help (and hassle) were you referring to?
1 Like
As I said, I’d appreciate help documenting issues. Fixing them too, if you have relevant skills or are willing to learn.
Other needs I’m aware of:
- check the wiki (and javadoc) for accuracy and clarity, fix any issues
- write more example code:
- an example using GImpact shapes
- an example using simplex shapes
- an example using cone shapes
- an example that clones physics controls
- an example that serializes physics controls
- an example of a simple physics server and client
- set up automated testing to catch regressions (like we have for
jme3-core) - set up continuous-integration builds of Android natives (like we have for desktop)
I won’t detail the hassles of supporting the physics libraries—lest I discourage anyone or sound like a whiner.
2 Likes
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.
P.S. I’m sorry for disturb veteran chat.
1 Like
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.
3 Likes
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.
2 Likes
Okay, we’ll see where I go with this if anywhere, but maybe I can lend a hand. First finding…
With all these apparent “bugs” turning up in the NB 11 Gradle maybe I’ll have to revert to 10 at some point, but that one looks workaround-able.
2 Likes
For the examples listed above, did you mean for jme3-examples in Git, or “wiki examples”?
1 Like
I was thinking of jme3-examples when I wrote that.
1 Like
PR for one out. Let me know if you’ve got any specific ideas and I’ll see what I can do.
1 Like
@lifeinwild Just noticed this - no disturbance! It’s great to see knowledgeable new users show up! (Love the kitty photo btw.)
1 Like
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.
7 Likes
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 
1 Like
I may help with that
That would be great!
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
Ook I see. What a pity… 
2 Likes
Effective today, jme3-bullet is the default for jme3-examples:
It’s not difficult to switch back to jme3-jbullet, if you need to.
4 Likes
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
1 Like
I tried and was unable to reproduce this bug. Has anyone seen it recently?
1 Like
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.
See and following comments: Questions about character movement/physics engine in multiplayer game - #8 by remy_vd
1 Like