Native Bullet versus JBullet

sgold · May 29, 2019, 11:20pm

Both native Bullet and JBullet use a ZLib license, whereas JMonkeyEngine is entirely NewBSD license. I think we shouldn’t mix source code with different licenses.

sgold · May 29, 2019, 11:26pm

I’m unfamiliar with “custom shapes”. I searched the JBullet source base and didn’t find this term mentioned. Are you thinking of GImpact shapes?

louhy · May 29, 2019, 11:42pm

I could have pulled the term out of (imagination), but that’s how @aaronperkins also put it on his jmeplanet thread.

I can give an example from that project. The problem classes for using native were PlanetShape and PlanetCollisionShape which can be found here:

https://bitbucket.org/aaronperkins/jmeplanet/src/default/src/jmeplanet/

PlanetCollisionShape sets a custom “cShape” field which was on CollisionShape, also a (name clashing) “CollisionShape” type:
protected com.bulletphysics.collision.shapes.CollisionShape cShape;

It looks to me like this basically allowed the calcuation of the collision shape in real time, from Java. Since he was doing procedural terrain generation (I think), that came in pretty handy.

Now is it worth trying to preserve that kind of capability…? That’s a good question.

sgold · May 29, 2019, 11:44pm

I always use fixed time-steps, which might explain why I haven’t hit pspeed’s “killer bug”.

I used to deal with C code and GDB every day, but I left that job in 2001. Of necessity, I’m re-learning how to analyze core dumps and debug native code on Linux. It’s painful, but hopefully I’ll be able to tackle native-code issues as they arise.

sgold · May 30, 2019, 12:01am

I’ve contributed several C++ fixes to the jme3-bullet-native library, if that’s what you mean. Most of those edits were to our JNI glue code, which is simple and easy to modify. However, the build script for jme3-bullet-native pulls Bullet source code from Bullet’s GitHub repo (to avoid licensing issues?). For this reason, changes to actual Bullet source code must go through their repo—I’ve made exactly one such change.

sgold · May 30, 2019, 12:19am

Interesting. That does seem difficult to replicate using jme3-bullet.

pspeed · May 30, 2019, 1:15am

No, that’s not what I meant. The bug is not in our code but in bullet itself. Or at least the only thing necessary to trigger it is to provide some very specific time values. Didn’t seem like it was anything we could be doing.

pspeed · May 30, 2019, 1:26am

Yes, run the SiO2 Jaime character example:

The difference between working and not working is this line:

github.com

Simsilica/SiO2/blob/master/extensions/bullet/src/main/java/com/simsilica/bullet/BulletSystem.java#L282


      
              applyImpulses(impulses);

          }       

          

          float t = (float)(time.getTpf() * speed);

          if( t != 0 ) {

          

              for( EntityRigidBody b : driverBodies.getArray() ) {

                  b.getControlDriver().update(time, b);

              }

           

              pSpace.update(t);        

              pSpace.distributeEvents();

              

              for( EntityPhysicsObject o : mobs.getArray() ) {

                  

                  if( o instanceof EntityGhostObject ) {

                      // The only reason its in the mobs array is because

                      // is has a parent

                      EntityGhostObject g = (EntityGhostObject)o;

                      EntityRigidBody parent = g.getParent();

                      if( parent == null ) {

…which in order to work needs to be changed to:
pSpace.update(t, 0);

As I recall, the bug can be triggered consistently by sending in a time either just under 1/60th of a second or just over… I can’t remember which and I have commented out code for both.

sgold · May 30, 2019, 1:38am

My personal opinion used to be that JME should drop jme3-jbullet. But now that we have JBullet source code again, I’m less adamant. At this point, I barely care. I created this topic because I want this discussion to take place outside the screenshot/WIP topic.

I help out with jme3-bullet for the same reasons I respond to troubleshooting requests on the Forum: mainly to “give back” to the JME community. Last year there was plenty of “low-hanging fruit”—known issues with jme3-bullet that were easily fixed. I used them up.

The more time I devote to Minie, the less interest I have in the other physics libraries. Fixing issue 797 in Minie was a major effort. I don’t want to repeat all that effort for jme3-bullet, let alone for the unfamiliar jme3-jbullet. Back-porting a stripped-down DynamicAnimControl to jme3-bullet and jme3-jbullet was a good exercise. It also reminded me how uncomfortable I feel working in the shared codebase.

Perhaps there are good ways to add features to jme3-bullet without adding them to jme3-jbullet. Having done that once (for issue 964) I believe it’s not a good use of my time.

In the big picture, there are clear advantages to keeping jme3-bullet more or less interchangeable with jme3-jbullet:

If you hit a bug (or limitation) in one library, you can easily switch to the other.
It simplifies the documentation, particularly the Wiki.
The libraries can share example code such as jme3-examples.
The libraries can, in principle, share tools and content.

sgold · May 30, 2019, 2:00am

I’ll look into this.

oxplay2 · May 30, 2019, 7:35am

I’ll look into this.

nice, because looks like this block some people from using native.

I’ve contributed several C++ fixes to the jme3-bullet-native library, if that’s what you mean. Most of those edits were to our JNI glue code, which is simple and easy to modify. However, the build script for jme3-bullet-native pulls Bullet source code from Bullet’s GitHub repo (to avoid licensing issues?). For this reason, changes to actual Bullet source code must go through their repo—I’ve made exactly one such change.

Both native Bullet and JBullet use a ZLib license, whereas JMonkeyEngine is entirely NewBSD license. I think we shouldn’t mix source code with different licenses.

i dont think ZLib is a problem, its popular license that as i know can be easly mixed with new BDS and do not affect overlay license. So it could be just added into JME repo, but verify me if im wrong. i base my answer based on what i heard when i asked our lawyer if i can use Zlib myself in project. So everything should be fine. Also i think its not even required to write anything like new BDS/Zlib in license description.(the main project license, just in subfolder license only)

Also i think even if it pulls Bullet source code from Bullet’s GitHub, then Zlib still is attatched trully into JME. i think it was done only just to match newest version? or some similar reason.

anyway the only thing probably to do, would be need to tell that its modified version of oryginall bullet lib.(and which files exactly)

i will still try to get more information about it anyway.

some link:

like someone mentioned, thats also what i think:

You can use any mechanism to include those licenses that you like, as long as it becomes clear to a visitor of your project which license is applicable to which portion of the project.

sgold · May 30, 2019, 3:40pm

I am not a lawyer.

The ZLib license indicates that “Altered source versions must be plainly marked as such”. The NewBSD license lacks such a requirement. Each time you alter a ZLib file you have to clearly document the fact.

oxplay2 · May 30, 2019, 3:47pm

as i know you anyway have a changelog, so it can be always said that changes in lib are contained in changelog

jayfella · May 30, 2019, 5:04pm

The thing is, as easy as it may sound, you are not the one doing it. Maintenance and PRing and all the rest involved is a time consuming task.

“Just do this” is simple to the person saying it, not necessarily to the person having to do it.

oxplay2 · May 30, 2019, 6:21pm

The thing is, as easy as it may sound, you are not the one doing it. Maintenance and PRing and all the rest involved is a time consuming task.

“Just do this” is simple to the person saying it, not necessarily to the person having to do it.

you are totally wrong.

like i said before:

But still we got only one person who make physics for us, so we need bless him and do not add even more work for him. If its only for native, then lets use it.

i also dont force to do anything, i just discuss what can be done. do you see somewhere “do this”?

telling own opinion and supporting is also imporant.

pspeed · May 30, 2019, 8:51pm

If we maintained our own jbullet.jar it would be in its own repository under the JME project. So not really that big of a deal that it has its own license. It would be built and deployed to bintray, etc. separately… probably with its own group. (org.jmonkeyengine.jbullet) for example to properly distinguish it from any future jbullet and from a regular jme jar.

Someone just has to do it. Which is always the bump in the road.

sgold · May 31, 2019, 5:39pm

Maintaining jme3-bullet shouldn’t be all up to me. Or at least, it needn’t be that way. In the past, I’ve had invaluable help from @RiccardoBlb and others, for which I am grateful.

I didn’t create the library, and I don’t own it. The source code and build scripts are open to inspection. Anyone can submit a pull request—though I wouldn’t say it’s easy. Frankly, maintaining jme3-bullet has always been a hassle.

I would appreciate more help.

oxplay2 · May 31, 2019, 7:20pm

i afraid not many can understand this all physics there and know how to debug it. if it would be easy, anyone could just update it.

jBullet might be easier for some people, but still, we use native one for Minie.

sgold · May 31, 2019, 7:59pm

It’s not necessary to know GDB in order to help.
If you see something that’s not as it should be, open an issue at GitHub and document the issue. Documenting issues is helpful, and it’s just as vital for enhancement ideas as it is for killer bugs.

oxplay2 · May 31, 2019, 8:08pm

you are 100% right, without reported issues, cant fix anything.

testcases are best to replicate. (if no need special hardware to replicate)

i will soon enough test new Minie features too. just need finish character and world editor.