Hi, I am evaluating porting bullet 3 to java (using also opencl via jocl), is there anyone who also is interested so that we may unite all our efforts?
I like what it is happing with JOML and I really hope we could do something similar
Sure, it will be great! I would certainly like to use a modern bullet port.
But basically, with all open-source projects that start out: You somewhat have to have an intrinsic motivation to do it regardless of what other people think of it, and you should not care whether other people will like/use it or not. It should be benefitial to you in the first place.
Sure, you can have some extrinsic motivation by people telling you that they would like it. But the base motivation needs to be intrinsic.
So, please just start with it. 
i’m game. the current jbullet port is pretty awkward (to me).
Don’t forget about supporting LWJGL3 (which has OpenCL too).
Let’s say I’d need it both for my work and my personal projects.
You know, Kai, actually I was thinking if we can rely on joml… it’d be cool, what do you think?
Nice basil
Yeah, I guess lwjgl had an opencl binding too, but I wasn’t sure.
Sure btw, as I already told SHC in chat, we could do something generic and then everyone can use the api he likes most
For the purposes of history, let me state what he said to me on the IRC:
<SHC> I really like the idea about porting bullet 3
<elect> excellent
<SHC> right now, I have no experience with it (not porting but using it) so I'm now setting up a test workspace in VS2015
<SHC> Yeah, I would also like to integrate bullet into my engine, so that would be pretty good to have.
<elect> nice
<elect> I took a look to their repo
<elect> it seems they are still in the phase of transporting bullet2 to 3
<elect> Im writing down the validation right now
<elect> I need the stl
<SHC> Standard Template Library?
<elect> I think so
<elect> We are gonna need some collision detection in the future for our engine and therefore I was looking at jbullet
<SHC> How are you planning to port it? You write JNI code? or port it to java manually by hand?
<elect> I dont want any binding
<elect> I want pure java code
<elect> so that we can tune everything
<SHC> So porting by hand? That's a lot of code there..
<elect> yep
<elect> I need hardbody collision for the moment
<SHC> So we chose the hard path of thorns,.. so shall we spend some days getting used to bullet 3 in C++ first?
<elect> maybe
<elect> I was also thinking if launching a kickstarter could make any sense
<SHC> Aren't you making it opensource? I mean, working it on free time?
<elect> both
<elect> opensource for sure
<elect> I will work on it during some part of my work and in my free time
<elect> if we go for the port
<elect> I'd like 100% java so that we can also choose to avoid some class instances for performance and memory footprint
<SHC> My idea is a bit different, we can avoid the vector classes, like btVec etc., and instead construct the structs in JNI code?
<elect> we shall discuss the pro and vs
<elect> actually I was thinking to rely on JOML
<elect> from kaihh
<elect> it looks very good for performances
<SHC> That's a good idea too, I thought so since constructing objects is very expencive but struct instances is not..
<elect> so at least the math part is "already done"
<elect> ^^
<SHC> haha yeah, agreed, we shall be using JOML. And the bindings? I have to see an overview of bullet and read some demos.
<elect> what is your dev os & machine, SHC?
<elect> Im using an i5 & 770 on 15.04 x64
<SHC> Windows 10, i7 4790k, NVIDIA GTX 750 Ti and 16 GB RAM.
<elect> or i5 & 680
<elect> good
<elect> modern enough
<elect> (for opencl support)
<SHC> Yeah, I think OpenCL is supported even on GTX 210
<elect> yeah, but it is not mature
<SHC> That's the minimum I heard
<elect> I read the guide, they say cl kernels are very likely to crash for a large number of reasons
<elect> moreover they cannot use cpu as opencl devices, dont know why
<elect> does lwjgl has a opencl binding?
<elect> I guess so
<SHC> Yes, LWJGL had OpenCL bindings
<elect> nice, we can do then something generic and everyone will choose what he likes most
<elect> like joml
<SHC> yeah
<elect> I already cloned and built it
<elect> most of examples run
<elect> just a couple crashes
<SHC> Oh I'm now reading the manual.
<elect> the problem is that they made a browser windows example and when you open it selects automatically the last example you run.
This means once it crashes I have to clean and clone again, since everytime I open from that moment going on it keep crashing
(coz it tries to open the same example)
<elect> anyway the opencl support is experimental
<SHC> Did you create a repo?
<elect> no
<elect> not yet
<elect> I am still in the decision phase
<SHC> oh kk
<elect> the thing is that it relies of course also on acceleration structures
<elect> I am just starting with that too
Just posting it here in case anyone would like to know what happened behind the scenes in the IRC.
I don’t know what requirements a physics engine like bullet has regarding math.
I’d suggest you take one or two weeks digging inside bullet’s sources, playing with a native bullet build for a while to get a feeling, and then see if JOML can help you with anything.
You see, JOML is geared towards transformation calculations for OpenGL rendering. Not towards a physics library.
So I reckon you have to write most algorithms and data structures by hand anyways. Of course, there are basic data structures you always need, like vec3 for acceleration, velocity and position vectors. But that’s basically it, I guess.
Also understand that JOML tries to cover far less surface (meaning set of requirements) than what a full-blown physics engine like bullet does.
And a physics engine is driven by alot more forces (all kinds of features (rigid body, soft body, …), performance, runtime-footprint, ) to be useful to a broad set of people than what a simple linear algebra library like JOML is.
One thing to keep in mind is that Bullet3 is still pretty much experimental (under heavy development) and depends on OpenCL.
OpenCL support and drivers are still not very widespread and judging by current trends its not looking like it’ll get much better any time soon (both OpenGL compute and Vulkan seem like much better bets atm). Therefore any application using Bullet3 (in its current form) will only really be usable by a small and niche target audience unlike Bullet2 which works well for the mass market.
Its a big undertaking to port and maintain a C++ code base (especially a fast moving one like Bullet3) to Java, so you should consider your options carefully (like whether to go for making a binding instead of porting).
What do you mean by “better”? OpenGL Compute != OpenCL
In my humble opinion, some forks of JBullet available on Github and the native bullet binding of JMonkeyEngine are some more viable options on the long term.
OpenGL compute shaders have better driver support is what he’s saying.
Me:
[quote]Hi Tommy and Gideon,
I am writing around in order to test the availability of doing a java port of the bullet 3, using also its opencl support.
I write to you too since you are the most active devs of https://github.com/bubblecloud/jbullet
I opened also thread on JGO (http://www.java-gaming.org/topics/jbullet3/36579/view.html)
What do you think about?
Regards,
Giuseppe Barbieri
[/quote]
Gideon:
[quote]Hi Giuseppe,
In the end I found it was better (for me at least) to use the C version via JNI. This way, we could take advantage of the main distribution, and all of the latest features.
It was a while ago since I looked at it, but I could dig out the code and give you a bit more information if you are interested.
Regards
[/quote]
Me:
[quote]Hi,
thanks both for your replies
let’s say both ways have their pro and vs.
If we do the port, we have 100% pure java, we can simply add a single fat jar and we’ll get physic. Downside we have to keep it up with the updates on the C side, but if we match closely the C style we can reduce the work that needs to be done in order to update the java version.
If we do the bindings, we take advantage of all the latest feature as Gideon says but we may get in trouble with the memory management since we will have no garbage collector and we have to free manually the resources. Moreover the usage in project gets a little more complicate and small updates are still required to match the future features.
My hope is to create a java community that helps maintaining that.
However one of the problems right now is that bullet3 looks under heavy development…and the opencl stuff is not very stable I read somewhere (experimental). What do you suggest to do? How much will it take to do a reasonable complete port? Is needed/helpful a deep mathematical knowledge for that?
Ps; may I report this discussion on the JGO forum?
Regards
[/quote]
Gideon:
[quote]Hi again,
At the time I thought it would be very difficult to maintain a Java version that was as good as the C++ version, because it was implemented for SIMD (special instructions for high efficiency), and wasn’t documented. This made it very hard to understand the implementation, in order to port to Java. Is Bullet 3 much easier to understand?
This discussion has made me want to go back and refresh my memory, clean up our code, and open source it. I’ll let you know if I get to this.
Good luck, let me know what you choose to do.
I would be happy for you to report this to the JGO forum!
[/quote]
this is how things are right now… Let’s see what Gideon will bring to us
I also tried to probe on the bullet forum, not that success so far
i was thinking the same. after goofing with the c-source it looks like JNI bindings would serve best.
testing swig’ing it at the moment.
There is already a similar solution implemented in JMonkeyEngine, why do you want to reinvent the wheel? There is gdxBullet too.
Elect, if you prefer creating another binding to Bullet, think about using GlueGen.
gdxbullet is using swig too and just like the jmonkeys bindings, it is much more then just the bindings.
using swig is not really reinventing the wheel and it’s giving us a decent level of customisation of type translation. i’m looking for low level bindings without the bloat of intermediate wrapper classes - which i couldn’t find in the wild yet.
gdx-bullet uses only LibGDX math, jme3-native-bullet is a bit similar. It’s possible to use them without depending on the engine/framework. Both aren’t bloated.
Even JBullet uses Vecmath and each engine or framework has its own math library. If you create a low level binding, you’ll have to use another math library (JOML or a library integrated into another engine or framework) or to create your own one. There is a reason why you don’t find such a library… There was a similar concern about JUMI.
I see some NIH syndrome here or a desire to spend some time in creating a new tool whereas it’s not necessary.
Imagine that you succeed in writing yet another native Bullet binding with your own math class or JOML. The developers who use a framework or an engine depending on another math library won’t use it because it would add a lot of overhead because of the conversions between 2 math libraries (look at how JBullet was integrated into the existing engines) and it would force them to package their games with 2 math libraries.
Imagine that you succeed in writing a pure Bullet 3 port depending on a particular math library and a particular OpenCL binding (don’t tell me that you will support all OpenCL bindings, be honest). Those who use another OpenCL binding or don’t want to use your math library wouldn’t use it.
At the end, you would target only some developers interested in physics but who don’t want to use any framework or engine. Is it worth? When they need numerous features already supported by existing engines, will they go on using your stuff?
In my humble opinion, contributing to some existing projects would be more useful than creating yet another library. Good luck anyway.
guess we have different definitions of “bloated” and “bindinds”. 
if you create a low level binding you should be allowed to use just the math lib you already use and not be forced to use another 3rd party lib which you would not use otherwise.
i agree with you tho’. writing another binding which pretends to be a API is not a good idea.
[quote=“gouessej,post:16,topic:55366”]
isn’t that the whole point? not using jbullet exactly for that reason. same applies to GDX - requires you to put lots of GDX classes into your CP. JME bindings i did not look deep enough to say much about it.
[quote=“gouessej,post:16,topic:55366”]
again, you pointed it out already. if you go around and pick any lib that supports “some” functionality you would like to use - you might just end up with a CP which contains alot unused code. the threshold before it becomes awkward is pretty individual i guess.
how about start small and get things done before thinking about the NASA using your code ?
There is no way to do it efficiently. I don’t think that returning only plain Java arrays would be a good idea and you would still have to convert them explicitly or implicitly when using a math library.
It requires to put only the math library of LibGDX (a few classes) into your classpath, not LibGDX as a whole. “a few classes” != “lots of GDX”
It’s not the case, it’s even more evident with Ardor3D and JogAmp’s Ardor3D Continuation as ardor3d-math can be used alone
Start by proving that it’s possible to create another binding without creating another math library and then, we’ll talk about that too.
bullet uses a C math lib. expose it with JNI. let the user decide which API to build on top. i know, that’s simplified but you get the idea.
edit
or even more low level - leave the “math lib” SWIG template open to the user. in the end it’s about objects - vectors, matrices, etc.
I don’t know, it seems to me they are useless problematics…
I mean, I am daydreaming about a working out-of-the-box physic lib.
I have my project, I add jbullet.jar and I have physic, simple.
I dont like the math lib jBullet is using? I clone it and modify it in order to use the one I want. Althought I dont see any problem, honestly, why a developer couldnt have an engine or a framework with a math lib and a phyic engine with another math lib. I agree it doesnt make more sense, but it is modular and a math lib doesnt take that much space.
I am pretty sure it is not such a critical thematic. And if I will be wrong, I have no problem at all developing the lib in order to use different math lib or opencl binding.
However, I see there are potentially a lot of java user who would benefit from a pure java bullet, but we are too many willing to actually write it… what about crowfunding platforms?