well that is not how to switch to bullet-native, the SDK code is compiled (java bytecode) to work with jBullet lib which have “linearmath” as a package dependency.
I’m experimenting with replying by email right now, so please excuse if
this message looks wierd 
Essentially the issue lies much deeper, namely a serialization mismatch
between jbullet and bullet-native, as elaborated in earlier posts.
As from the SDK side it should really depend on jme3-bullet (which is
the wrapper fore both, native and jbullet), however it might contain
some unclean code which depends on jbullet (especially some linearmath
package stuff, since this is jbullet-only).
I am currently busy by being sick and working on my own game but in
theory it should be possible to just change the gradle file to remove
jbullet, add bullet-native and see what happens. Maybe it doesn’t
compile but as I said it should just work flawlessly (that’s the idea
behind loose coupling)
1 Like
What about making version with just native bullet? I bet if someone who are moving to native bullet can just detach physics via old SDK and after it forgot about jbullet at all. At least as temp solution to help people whose hands are growing out of ass (like me and some other requesters).
Yes, that’s what we want to happen. I think there are a few issues left and few people helping.
Ya, when I had the issue I didn’t dig too deep to see what the problem was exactly, but as you said I suspect a serialization/deserialization issue between jbullet and native-bullet. Essentially I couldn’t load a j3o that was created with jbullet into a native-bullet environment. As normen said above, it might just be a matter of changing how native-bullet loads j3o data for mesh collision shapes.
Just try the latest commit I pushed to the SDK. Build from source and
see if it works.
Someone should try to fix bullet native anyway, assuming the issue is on
the bullet-native side and not the jbullet side (Because bullet native
essentially should use whatever the real bullet does)
I tried to build and failed. Possibly I do something wrong but I dunno what exactly. So issues with gradle are next:
Maybe I should download sources of jme engine before. I have no idea, really.
Multiple issues here: You used your own gradle on the task build inside of the gradle folder.
This means you try to build gradle with gradle it seems?
The correct command is gradlew.bat buildSdk and then gradlew.bat run to run the SDK.
But yes, you need the engine, see build_engine.sh, it’s actually for linux boxes but it works in Source Trees git shell (whever you installed your git to) and is manually completely doable.
Just download, build and gradlew.bat install the engine and possibly adopt the Engine File name inside of sdks build.gradle
1 Like
Okay I will try soon as you said. By the way, does installing engine means that it placed in local (my computer) repositories?
Yes, the Problem is that the online repos don’t contain several jar’s which wi have to build locally
Yes. Everything went right! It uses native bullet as default (I checked it as it allows to add physics without any issues and it crashes when you try open models with jbullet physics. But it is ok). So, is it possible for me to compile somehow?
2 Likes
I did a test run and this version of the SDK runs much smoother on my macbook pro. The scene editor is much smoother as well. I’m in the process of building the zip installers. I’ll update later.
I will be very grateful for installers. Do you use 3.2 or 3.1-beta?
Well i’m running into some issues, it takes a little over an hour to build. Once you’ve built the engine and sdk, go into the sdk/jdk folder and run the download-jdks.sh. This will download the required platform specific jdks needed to build the installers. After that you can go back into the sdk folder and run ant build-installers.
I’m building on osx so i’m not building windows or linux installers at the moment. So far I haven’t completed a build, I’ll try my best to inform you.
Also kudos to everyone’s work on this issue.
1 Like
The same way as mentioned earlier. And
Makes me think that you already achieved that?
If you only call build-installers it might build all installers and that takes quite some time, even on travis. Glad that download-jdks works flawlessly though, it was a tough one 
What exactly runs smoother? Without any rigidbodies in the Scene Editor there should be no change in performance so it might be a placebo effect?
Because actually even when you have RigidBodies you don’t have any real physics calculations, only the control added.
I mean make installers. I will try to make it in the way described by rsdunya.
@Antonystar I built the 3.1.0 snapshot osx. Did you have any luck?
@Darkchaos By smoother I mean, the scene editor is 10 times more responsive in 3.1.0, the background was black and I had performance issues seeing my terrains.
Also i noticed that now when importing models (in this case mountains), the collision seems to just “work” without me adding any rigid bodies.
Now I stucked with shell. I installed cygwin to execute command but get next error:
$ sh download-jdks.sh
download-jdks.sh: line 23: syntax error near unexpected token >' download-jdks.sh: line 23: echo “> Installing 7zip”’
PS. I have very little experience with it.
That’s really strange, note though that those files were never checked for a windows environment and for the mac os jdk (if you don’t comment it out, which you didn’t) is compiling some software from scratch which might lead to various trouble for you.
I highly suggest you to install a linux vm or a bootable usb stick, if possible, if you really need installers.
You can safely remove the “>” from any echo line you encounter, it’s just a stylistic thing actually.
If you only want the SDK to be usable by you, you can
a) use gradlew.bat run or
b) Inside cygwin ant zipDistribution (or comparable, don’t remember) or
c) Launch netbeans\bin\netbeans.exe and open the sdk project, right click “build zip”. This is equivalent to b) if you can’t use ant from the command line.
b) or c) will lead to the platform-independant zip file which you can safely use to have the latest sdk. It’s like the portable version
The only difference is that your system needs to have a jdk somewhere and that it isn’t bundled with (old versions of) blender/jdk
1 Like