Hello,
I’ve been looking around and can’t find out when(ish) jme3 will be switching from jbullet to bullet is being aimed for?
The driver for this question, is that I’m pretty convinced that many of the physics woe’s I’m experiencing now are down to a few quirks in jbullet, and the solution …switch to bullet.
So I’m trying to decide whether it’s worth porting over to jme3 now, due to the imminent changing over to using native bullet, or whether to switch a local copy of the jme-jbullet to use native bullet for the short term.
Thanks in advance!
Attempting jme-bullet compilation for Android and getting the following error.
C:/cygwin/usr/android-ndk-r5c/samples/native-bullet/jni/jmePhysicsSpace.cpp: In member function ‘void jmePhysicsSpace::attachThread()’:
C:/cygwin/usr/android-ndk-r5c/samples/native-bullet/jni/jmePhysicsSpace.cpp:50: error: invalid conversion from ‘void**’ to ‘JNIEnv**’
C:/cygwin/usr/android-ndk-r5c/samples/native-bullet/jni/jmePhysicsSpace.cpp:50: error: initializing argument 1 of ‘jint JavaVM::AttachCurrentThread(JNIEnv**, void**)’
After the 3.0 release
Ah, after the 3.0 release very good.
Can see the value in getting all the needed features out before creating the JNI, minimize the reworking / recreating of it.
Anyway, after looking around the site for a road map (hoping for a rough date for the 3.0 release), but couldn’t find one. Is there one on the site somewhere?
It’s more on a when it’s done basis. As everyone here is can only work in their freetime on jme.
Yup, what he said…
We’ve had some talks about the Beta roadmap, which should result in a public announcement shortly. Alpha-4 was the real long-haul, so thankfully the to-dos for Beta aren’t looking too scary. The best I can do for now, in good old fashioned obscure manager-speak, is tell you that future releases will definitely happen more frequently than 4 months apart, as was the case with alpha-3 to apha-4.
OoOoooh, a beta road map 
Regular releases are always nice, as it’s a quick and easy way to reinforce the perception of progress for regular users (like myself)!
What I’ll probably do with regard to the bullet, is get it working with the jbullet-jme for JME2 then put it up as a seperate project on google code for anyone who’s interested. Later on, I’ll switch to using jme3, then maybe see if I can be of help with that switch over to bullet.
…anyway thanks for all the prompt replies!
The jme2 and jme3 versions are substantially different by now, however the access to the native part should be about the same as in the current native version of jbullet-jme. Why don’t you just extend that one instead of starting a new project?
Yeah, the contact points (method signature and classes) are pretty much identical between jbullet and bullet.
Hang on a native version of jbullet-jme?
Can only see the jbullet looking at the version from: http://jbullet-jme.googlecode.com/svn/trunk/ jbullet-jme-read-only
Is there another branch / repo using the bullet binaries instead?
monkey_scratches_head said:
Is there another branch / repo using the bullet binaries instead?
Yes, I put the link in the post above xD Its not done yet, only a proof of concept really, only the basic TestSimplePhysics works with it..
Ah, right …of course, the link! :o
Yes, after looking at that, it does ring a bell. Think that some time ago, might have had a conversation about this, and also it turns out that I still have committer privileges on the jme-jbullet project!
Unfortunately as that branch doesn’t have the all the latest java source, I’ll probably branch from the trunk and copy in the cpp parts of that into it (with the bullet 2.76 binaries) – unless there’s any objects to another branch, of course
Yeah, you can just create a new branch if you think updating the code to the current version is too much work… But I guess both ways its a lot of changes since you have the native methods which work slightly different.
Well, updated the jme3 project and rebuilt the engine …following the same process of deleting the jbullet.jar and adding the bullet ones from the dist/opt and now it works!
Nevermind, must of done something wrong yesterday :roll:
Not jbullet.jar, jME3-jbullet.jar
yes, jME3-jbullet.jar is the one I meant, just being lazy.
…hang on a minute, there’s a jbullet and a JME3-jbullet.jar! - that’ll be it then, I probably deleted the jbullet jar yesterday. Well, suppose that’s what I get doing simple tasks late at night after a very long day.
Now I’ve deleted the JME-jbullet.jar, jbullet.jar, vecmath.jar and stack-alloc.jar, adding in the bullet JARs from the dist/opt and the brick tower demo still work!
1 Like
Hey, I started working on native bullet for jME3, will post more about the implementation details etc. in some days, I am about 90% done already:
TestQ3 on native bullet
TestBrickTower on native bullet
Whats missing still is vehicles, debug shapes and collision callbacks as well as some bugs to fix still but all in all it proves to be quite convenient. If you want to have a look at the code, its in the bullet-native branch in svn.
Cheers,
Normen
Edit: Automatic native garbage collection also works fine, can shoot new balls with new collision shapes etc for minutes w/o memory increase: Video Link
2 Likes
Cool, since native bullet supports double precision without further changes, do you plan on adding support for this as well? (This is really usefull for vehicles and sledges as the increased precision helps here)
Wow normen, wow. Looking really forward to it.
EmpirePhoenix said:
Cool, since native bullet supports double precision without further changes, do you plan on adding support for this as well? (This is really usefull for vehicles and sledges as the increased precision helps here)
That cannot work since the bullet API of jME3 uses jME3 math ;)
Edit: The vehicles in jbullet work not good because jezek doesnt have the maxForce parameter in, I ported it in the jME3 jbullet version from the native version already
Hm oh nice, where is your jbullet version? Can I download it somewhere? (The source)