Native Bullet versus JBullet

yes, i know safer is wrong word, anyway its better to get more performance.

memory issues are often very subtle and difficult to debug

is this only JNI related? if not, then would also tell any C engine is unstable :slight_smile:

i developed in JNI, im not C master, but needed some wrappers, and i dont had much problems debuggind the issues. You are correct in C need to care about memory manage, but i belive native Bullet dont have them, and @sgold will not add memory leaks/corruption.

based on all you said its like telling “Java is better” and overall i agree, but in some cases like here C is better IMO

1 Like

Not a bit. I’ve noticed that no matter how much care is taken on a C project, memory issues inevitably crop up sooner or later as it grows. The best you can usually do is code very, very defensively and fall back on good memory shells and monitor tools such as Valgrind. The situation is quite a bit better in C++ (especially modern C++ with smart pointers), but it’s still a minefield you just don’t have to deal with in Java. C/C++ can be perfectly stable, but it’s much harder to do than in Java and the likelihood of subtle errors increases substantially as the codebase grows. While I haven’t personally worked with JNI specifically, in my experience on other projects (such as mixed Python and C++), bringing a GC into the mix only adds to the likelihood of trouble since the GC can free things that are still visible from the native heap. If you can always use “safe” patterns (I.e., the native code never retains pointers to managed objects) you can (as you’ve found) go some time and be quite alright - but not all projects can easily simplify things to safe patterns all of the time.

I wouldn’t say so much that “Java is better” as I would say that “Java provides many benefits that native languages can rarely compete with.” Having spent plenty of time in both C++ and Java, I’d take Java far sooner for virtually any project I can think of doing. Regarding physics calculations, the JVM has very competitive numeric performance - but unfortunately for us, the actively maintained version of Bullet is in C++. If we don’t want to start any huge re-write projects (which don’t seem remotely justified or productive in the circumstances), we have to shrug and accept using native Bullet.

2 Likes

Like pspeed I believe I’ve seen a (rare) unreproducible dump once or twice, but I could have been doing something a little too wild… are we the only ones to ever see that with native Bullet?

2 Likes

thanks @danielp for explain.

jme3-bullet is not a small project, not a big too, its all up to @sgold who is the one taking care of physics now.

trully, if he would expand jme3-jBullet, i would use it anyway, because there are not so much differences. But we are still back to main topic.

The Minie lib use extended/fixed jme3-bullet-native to make Minie work with this physics. Making same changes for jme3-jBullet would not be just a copy paste but deep rebuild of both Minie and jBullet code, but thats what sgold could say how hard it would be to update jBullet.

recently was told jBullet had no sourcecode, but it was provided and we have sourcecode of it, so if there would be anyone who would want update it, its possible.

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.

Ofc i dont say own opinion to drop jBullet, it could stay as it is, just would make jme3-bullet-minie to work only with native, thats all. This topic is overall advantages and disadvantages, i dont see anything about drop jBullet for now, but i feel it was intended to know our opinions to stick only one physics.

Both have advantages and disadvantages ofc, but the main advantage of Native Bullet that was not mentioned as point here is:

  • jme native bullet have support of @sgold in Minie (not just current features)

i belive i understand topic intention, but i see alternatives all the time. Even if lets say, cant use native-physics and upgrade it to work with Minie features, i also see new alternative like creating totally new package jme3-minie with updated jme-physics and all features from Minie, while jme3-bullet-native and jme3-jBullet would stay intact to not break other people physics.

but i hope updating current one is not that problem.

2 Likes

I’m ignorant on this aspect of the problem, and sorry if this was already posted somewhere, but what precisely is stopping both Native + Minie JME integration while JBullet is still supported?

If the basic problem is that JBullet doesn’t have API to cater to new features, can we just have it throw an “UnsupportedFeatureException” or whatever if someone attempts to use it for something unsupported, and document what JBullet can’t do?

Is no feasible compromise possible? It’s nice to have options…

2 Likes

thats what i also thought, already suggested this, but seems like there were some “problems to solve” i dont remember or was never told. anyway my suggestion was failed.

i just see responses like:

so i just belive there is something that block it.

1 Like

If there’s still interest in jBullet and we have the sources, what about at least sucking them into the jME repo? I’m not familiar enough with the interfaces to comment on the difficulty of dual support for both via the same interface, but even if the interface had to fork I don’t think multiple options are a drawback if folks still have a lot of interest in jBullet.

1 Like

Similar thoughts here. I’ll refrain from speculating and lengthening this more until someone with more facts wants to chime in. It might be a fun project, but it’s hard to guess what the scope and difficulty is. I don’t know what the interest level really is, either.

1 Like

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’m unfamiliar with “custom shapes”. I searched the JBullet source base and didn’t find this term mentioned. Are you thinking of GImpact shapes?

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.

1 Like

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.

2 Likes

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.

1 Like

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

1 Like

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.

1 Like

Yes, run the SiO2 Jaime character example:

The difference between working and not working is this line:

…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.

2 Likes

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.
4 Likes

I’ll look into this.

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.

1 Like

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.