Where's the native bullet method gone?


I’m attempting to create a hinge joint using native bullet …but it’s failing.

The same problem occurs when switching jme3 to use bullet instead of jbullet and executing TestPhysicsHingeJoint.java in NetbeansIDE

Currently this have been tried out only on 32bit Windows, will try 64bit tomorrow.


12-Jun-2012 21:51:08 com.jme3.bullet.PhysicsSpace addJoint

INFO: Adding Joint 4ba18d10 to physics space.

12-Jun-2012 21:51:08 com.jme3.app.Application handleError

SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]

java.lang.UnsatisfiedLinkError: com.jme3.bullet.PhysicsSpace.addConstraintC(JJZ)V

at com.jme3.bullet.PhysicsSpace.addConstraintC(Native Method)

at com.jme3.bullet.PhysicsSpace.addJoint(PhysicsSpace.java:631)

at com.jme3.bullet.PhysicsSpace.add(PhysicsSpace.java:401)


I’ve used Dependancy Walker and Dll Exporter tools to view the native methods of the dll, both have a addConstraints, but there’s no addConstraintsC. While the JNI bindings seem to have contain that method it appears that it’s not making it into the bulletjme.dll

The dll was built using: ant built-engine

Not entirely sure why’s happening with this, help would be appreciated :slight_smile:

Do you assemble and compile the libs yourself? You have to use the stable or nightly version where the bullet natives get compiled with each build.

That method is there in the source code, so I am not really sure why you’re having this issue.

1 Like

See this post: http://hub.jmonkeyengine.org/groups/android/forum/topic/old-native-bullet-library-for-android-when-building-from-sources/

1 Like

As always, that’s for the swift replies!

@Momoko_Fan said:
That method is there in the source code, so I am not really sure why you're having this issue.

That was exactly my thinking, looking through the JNI binding I was certain that there should be that method available in the DLL. Alas it was not the case.

After reading this link:
@normen said:
See this post: http://hub.jmonkeyengine.org/groups/android/forum/topic/old-native-bullet-library-for-android-when-building-from-sources/

I now understand, well at least I think I do, so please correct me of I'm wrong :)

Here's a brief summary of the process I followed:
> svn checkout of the googlecode source
> navigate to the base directory
> ant build-engine

On my machine (i.e. not the Hudson nightly build) the ant target of build-engine does not build the native bullet, it only compiles the JARs.

No, you have to either build bullet yourself or download (not checkout) the nightly version of the engine. The SDK also contains compiled versions in stable and nightly.

@normen said:No, you have to either build bullet yourself or download

My current understanding is that svn checkout gets all JME3 (including the bulletjme part), and the bulletjme part has the build script to get & build native bullet where ever it's run, then create the native for the platform (Windows 32bit in my case) - is this what you meant by building bullet? (as that'll download & compile bullet)

In the process that I'd described I'm guessing that I'd have to invoke the bulletjme build script that would get & build native bullet, then do the the JNI stuff to create the bulletjme.dll for my platform and then maybe copy the produced artefacts (depending on where the JARs are output).

Anyway the other option of download the stable/nightly build, seems like a much nicer solution in for my case, as the Hudson build produces the natives for all the platforms (Windows / Linux / Mac), where I'd just create Windows ...unless I spend time to find & correctly set up a working cross compiler & as there's no need need for that ;)

theres a file in trunk/engine/ that describes how to build and use native bullet. the nightly and stable build process build the binaries for windows, linux and android, the binary files in svn are not updated nightly, only for release versions.

1 Like

Yes, that was the line of thinking I’d come around to …nice & concise!