If you want to spend your life in reinventing the wheel, I won’t waste mine to convince you not to do so.

Why not contacting the contributors of LibGDX? Why not asking them to extract the math and their bullet binding into a separate sub-project?

It seems to me that you lack of knowledge about the current Java ecosystem.

In the reality, it’s not so simple, especially with Bullet 3 and I read somewhere that Bullet 2 already offloads a bit some computations on the GPU but I’ve never checked in the source code if it’s really the case.

It doesn’t make sense because you can’t write that you don’t want to bloat your classpath with useless classes and that you accept using 2 math libraries, it’s not logical. Secondly, do you realize that the source code of Bullet is quite big? Do you really imagine that numerous developers would modify entirely an API in order to use the same math library?

Maybe it would be better to make the right choice now.

Why not posting a poll here before launching a crowd-funding campaign?

Finally, can you explain to us (without using your favourite search engine) what mean “tunneling”, “continuous collision detection”, “discrete collision detection”, “sweep and prune”, “broad phase”, “multisampling” (in the context of physics), “soft body”, “framerate independence”, “joint”, “Minkowski addition”, “contact”, “Gilbert-Johnson-Keerthi”, “Expanding Polytope Algorithm” and “Voronoi Simplex Solver”? If you can’t, please don’t even plan to make a pure Java port of Bullet 3.

I would vote yes for a java only physics engine, I dislike having the requirements for native files being bundled up in a java projects. This might mean there is a bit of “re inventing the wheel” but I think there a lot of advantages for this for the people that dislike natives.

@gouessej - quoting buzzwords to dissuade people from trying a project like this isn’t very helpful and doesn’t really mean much. Porting a library, essentially requires no knowledge because you are just porting code, you just need an understanding of the computer languages at both ends. A long while back I started porting bullet2 to java (a more up to date version of jbullet), I didn’t know anything about physics at that point but by porting the code I actually went off and learnt about the topic and I actually learned quite a lot in the process. Everyone starts somewhere.

This is partially true, there isnt right now “the wheel” we would like to have.

Done Let’s see what they reply.

It is more than probable :stuck_out_tongue:

You have a single jBullet.jar including the math. When a new version of the math lib is out, we include it, run the tests and if everything all right we release a new jBullet.jar. Why make your life complicate?

No, indeed, I told you ;D, I think most of devs will be just fine knowing that jBullet is working out-of-the-box and they don’t want to touch it.

Sure, it’d be, but unfortunately I dont have enough experience and data to take a decision now and know that is the right final one.

I was thinking also the same…

I’d not like to explain because I think it doesn’t make that sense to do this (and also because I wouldn’t be that good at it ;D). But I can say I have a quite solid mathematic and geometric background, I know the following terms “broad” and “narrow collision phase”, “solid” and a “soft body”, “framerate independence”, “joint” (with 3 different types). I don’t have idea what the other are, honestly.
However I think that while it’d be surely useful knowing all those, it will no be impossible to make it. After all, I do not want to write a physic engine, but I do want to port it.

You already have to bundle some native libraries if you use OpenGL and JBox2D is enough for 2D projects.

If you really know Bullet 2, then why don’t you admit that these aren’t buzzwords? They refer to numerous features implemented in this physics engine. Sorry to be a bit harsh but you should know some of those words if you learned something when porting Bullet 2, those terms should make you think about the solvers… and when something goes wrong, if you don’t understand what you port, you won’t be able to fix it, that’s my experience of porting a lot of OpenGL stuff (I’m responsible of engine support in the JogAmp community). Moreover, if you don’t understand a bit the concepts, a physics engine will just be a useless toy.

There is still a problem with your way of evaluating the wheels already available.

Some maintainers were ready to separate some other parts of their engine (the GL abstraction). We’ll see what they say.

Seriously, it doesn’t make me laugh. If you don’t really know the Java ecosystem, how can you claim that you have something new and better to bring?

You can hide the new math library inside your own library but it doesn’t mean that a developer won’t have to make some conversions between your math library and the one (s)he uses in her/his project.

It’s already wrong with JBullet, the JMonkeyEngine team has its own fork of this library. I remind you that LibGDX and JMonkeyEngine are used by lots of Java developers.

Glad to read that you admit it.

Let’s do it ;D

I’m sceptical.

So, after such a long time, a small but significative update: HelloWorld test case complete

If I wanted to use this, do I need kotlin? :-\

Did you even take a look at the example? How about testing the library as a Java developer, in order to support someone who invested a lot of time for us all with some feedback, if (not when) there’s something that is not optimal to consume from the Java side of things?

You don’t need to use kotlin, but you do need it as dependency

However, whatever you use (Gradle, Maven or the fat jar) you won’t even touch it if you don’t want to

If there’s no touching that needs to be done, then that is fantastic for me to hear. :slight_smile:
This could prove to be quite useful. JBullet2 is a less than ideal solution. Almost makes me want to use ode4j.

Because that’s a deciding factor of whether or not I am going to use the library.

What are you going to need it for exactly at first?

To replace from the game engine I wrote last year. For my personal projects :slight_smile: