Jbullet version

Hi

What is the jbullet version jme3 is using and where could I find the sources?

I fetched the latest version from here but it was not compliant with the version jme3 one:

SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.NoSuchMethodError: com.bulletphysics.dynamics.DiscreteDynamicsWorld.setPreTickCallback(Lcom/bulletphysics/dynamics/InternalTickCallback;)V

So I am currently using the jar from jme3 lib but it would be nice to find corresponding sources for debugging etc.

Regards,
Tommi

https://code.google.com/p/jbullet-jme/source/browse/#svn%2Fbranches%2Fjbullet

1 Like

Thank you

Br,
Tommi

There seems to be jbullet version in github with some of the missing bullet functionality added like Spring Constraint (Generic6DofSpringConstraint):

Regards,
Tommi

.

We had to find out that jbullet sucks, we’ll use the native version at some point. So thanks but we’re fine :wink:

Well szcks is a bit harsh, the main problem is, that most of the more efficient algorithms over the last years are not in the java version.

So additionally to a langauge overhead, it suffers from inefficient algorithms.

Eg physical rays have O(n^2) in jbullet and O(log n) in native, as the java one does not use the broadphase for optimising.

1 Like
@Empire Phoenix said: Well szcks is a bit harsh, the main problem is, that most of the more efficient algorithms over the last years are not in the java version.

So additionally to a langauge overhead, it suffers from inefficient algorithms.

Eg physical rays have O(n^2) in jbullet and O(log n) in native, as the java one does not use the broadphase for optimising.

No, the main problem is that the developer tried to outsmart the JVM and do “memory management”, adding the new algos wouldn’t be a problem really.

1 Like

Tommi,

I already merge jbullet + jme’jbullet + QintBio-fork. It’s available at GitHub - davidB/jmbullet: This is a JBullet fork where I merge changes made by 3rd party since the last release of jbullet..
(native bullet crash on my config)

1 Like

Hi

Crafted fork myself as well and released to maven repo as I have interest in having jbullet going forward:

Pros:

  • Commit history intact
  • Included features implemented in QIntBio-fork
  • Object pooling removed (How is performance now?)
  • Array pooling still intact (Should be removed?)
  • Only dependency to vectmath.jar
  • Demos work as far as I can see
  • Seems to work with JME3 HEAD (Testest with TestPhysicsCharacter.java)

Maven repository:

    <repository>
        <id>bubblecloud-cloudbees-release</id>
        <name>bubblecloud-cloudbees-release</name>
        <url>http://repository-bubblecloud.forge.cloudbees.com/release/</url>
    </repository>

Maven dependency:

    <dependency>
        <groupId>org.bubblecloud.jbullet</groupId>
        <artifactId>jbullet</artifactId>
        <version>2.72.2.3</version>
    </dependency>

Work log:

  • Imported the SVN branch pointed by Normen to github
  • Merged changes from QIntBio fork.
  • Removed object pooling and hence unnecessary dependencies.
  • Hooked to cloudbees build to have route to easy release to maven repo.

Summary:

Hope this of help for other people as well.

If you are interested in grooming the code please let me know and I will add you to the bubblecloud team in github to have access to the source repository or alternatively just fork away.

Regards,
Tommi

If you want to access Generic6DofSpringConstraint in jme, you should include (like I did in jmbullet) the jme missing classes => jme dependencies but jme isn’t available on maven central.

It’s the main cause why I didn’t upload to maven central.

I’m not convince that removing stacalloc / object pooling is a good idea (need bench) because it avoid lot creation/destruction of temporary vector. (Jme use TmpVars to acheive similar gools).

It is a bit hard to say what happens with performance when object pooling is removed. My understanding is that JVMs are quite good these days when object construction and garbage-collection is in question. Array recycling is yet another topic. Benchmark would be nice and native bullet would be great base line.

If JME needs some additional implementation related to Generic6DofSpringConstraint it could be added to suitable module under JME or alternatively it could become another project like jme-jbullet-extension in github to avoid cyclic dependencies between jbullet and JME projects.

cheers,
Tommi

No need to profile, jbullet is butt slow on android, thats another reason why we move to native bullet for all platforms.

I am looking at jbullet mostly for some non JME3 related simulations all though JME3 will be used to view those remotely. Benchmark would be of interest related to questions whether jbullet object pooling helps with performance.

Regards,
Tommi

@tommi.s.e.laukkanen said: It is a bit hard to say what happens with performance when object pooling is removed. My understanding is that JVMs are quite good these days when object construction and garbage-collection is in question. Array recycling is yet another topic. Benchmark would be nice and native bullet would be great base line.

The goals of pooling is to avoid garbage-collection and the pause.
see http://www.java-gaming.org/topics/jstackalloc-stack-allocation-of-quot-value-quot-objects-in-java/18843/view.html

@tommi.s.e.laukkanen said: If JME needs some additional implementation related to Generic6DofSpringConstraint it could be added to suitable module under JME or alternatively it could become another project like jme-jbullet-extension in github to avoid cyclic dependencies between jbullet and JME projects.

There no cycle, because JME doesn’t depends of any jbullet impl except it’s own.
It’s cleaner to add a jme-myjbullet-extenstion, but it introduces overwork for a single class (projet, deployement, workflow,…).
Thanks, your comments, ping me to clean jmbullet ((I’ll change the scope of jme to provided or optional).

You refactor the jbullet code before merging => lot of noise in the diff, you can take a look at the commits of jmbullet, I tried to group diff between jbullet and the 2 forks (jme and QIntBio-fork), it may help you.
As you refactor a lot, don’t forget to exclude jme’s jbullet (but not jme3-jbullet) from the classpath when you’ll use it with jme.

@tommi.s.e.laukkanen said: I am looking at jbullet mostly for some non JME3 related simulations all though JME3 will be used to view those remotely. Benchmark would be of interest related to questions whether jbullet object pooling helps with performance.

Regards,
Tommi

As I said, it completely breaks down the performance on android, I don’t think its of interest if its a few femtoseconds faster on desktop if thats a side effect.

Ok, sorry did not catch that android object pooling link.

Br,
Tommi

Hi David

You refactor the jbullet code before merging.

I merely :twisted: moved the source folder to be according to maven project structure and demos under src/test/java to avoid them ending up in jar. If there is need to diff with other forks in non maven structure then correct folders need to be diffed instead of root folders of the projects.

There is bunch of code changes related to cutting out object pooling but that is after the merge of the two original forks.

The jbullet source code as such could use some love as it does not seem to much follow Java coding conventions and some additional javadocs would be helpful…

Might be good idea to join forces to get that code in shape .)

My main reservation now with other forks is that they are polluted with object pooling which adds unnecessary library dependencies and clutters the code. We could run some benchmarks to see if object pooling actually gives considerable speed benefit say over 30% speed up in general or more than halves the garbage collection CPU spike. If this kind of benefits can be observed then I could include the object pooling code in my personal projects as well.

In the end it would be good to settle on single fork and spend some time doing some code maintenance work like review, reformat (correct indents), comment, unit test and fix bugs.

Br,
Tommi