jBullet3

[gouessej]

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?

@elect

I don’t know, it seems to me they are useless problematics…

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

@elect

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.

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.

@elect

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.

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?

@elect

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.

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

@elect

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?

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.

[abcdef]

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.

[elect]

@gouessej

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

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

@gouessej

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

Done Let’s see what they reply.

@gouessej

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

It is more than probable

@gouessej

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.

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?

@gouessej

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?

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.

[quote=“gouessej,post:21,topic:55366”]
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.

@gouessej

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

I was thinking also the same…

@gouessej

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

[gouessej]

@abcdef

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.

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

@abcdef

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

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.

@elect

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

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

@elect

Done Let’s see what they reply.

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

@elect

It is more than probable

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?

@elect

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?

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.

@elect

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.

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.

@elect

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.

Glad to read that you admit it.

@elect

I was thinking also the same…

Let’s do it ;D

@elect

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.

I’m sceptical.

[elect]

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

[orange451]

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

[h.pernpeintner]

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?

[elect]

@orange451

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

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

[orange451]

@elect

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.
This could prove to be quite useful. JBullet2 is a less than ideal solution. Almost makes me want to use ode4j.

@h.pernpeintner

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?

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

[elect]

@orange451

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

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

[orange451]

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