Java port of Bullet Physics Library

Game Mechanics
#21

Thanks, it’s just a simple testing scene (from original Bullet), you can check the sources for details and play with adjustments :slight_smile:

I’m leaning towards the idea of automatic Ant-based source translation to vecmath2 (the original would be still using Sun’s vecmath), so I could support both of libraries at once to satisfy all parties :slight_smile: There might be also builds with doubles instead of floats in future.

Though I think you’re not quite fair to the Vecmath2 effort, it’s really independent of Xith3D, and have interesting features, and could be extended more, whereas with Sun’s vecmath we’re stuck in time :slight_smile:

#22

anyone tried to contribute changes back? In best case the vecmath2 lib could be a extension of Sun’s improved vecmath package instead of a fork.

EDIT: added improved before vecmath to make it clearer

#23

Where are you getting that vecmath is closed source, or not accepting contributions - looks pretty open to me?

https://vecmath.dev.java.net/

It’s a sub-project of:

https://java3d.dev.java.net/

Where most of the mangement get’s handled. I’m sure they’d be excited about a whole bunch of contributions that reduce GC and improve performance!

EDIT: Infact:

Kev

#24

Why not have method that take floats and you translate them into whatever libs you want?

so maybe: position(float x, float y, float z); It might break the API, but then atleast your math lib neutral, much like ODE.

DP :slight_smile:

#25

Holy cow, that’s amazing!! :smiley:

pressing e for more people and . for bombs loads of times doesn’t ware it out - it’s still stable, nice job with the port.

#26

That’s not an option, Bullet doesn’t have clearly seperation between public API and “internal” things. In fact, Bullet is pretty modular and you can happily use any internal stuff when you need just that. ODE on the other hand has C frontend API that hides all internal stuff.

#27

JDL is not classic opensource license, for example it requires that modified versions passes TCK. To obtain it I must do some paperwork, which I don’t want. To change things I must become member of JCP, another thing that is barrier for me.

With truly opensource I have much lower barrier to contribute or even make own changes for my own usage (none barrier).

I’ll provide builds of JBullet for both vecmath libs and let decide developer what he likes/needs. This issue is pretty closed for me by this.

#28

OpenMaLi is certainly not specialized especially the vecmath2 package. There may be some packages or classes, that would not be there, if I wouldn’t use it in Xith3D as well as there are some changes or additional classes, that came from influences from the JOODE project. But these specific classes are all written in a way, that make them usable for other purposes, too. And this is, what should be applied to everything committed to the project.

So it is perfectly independent from Xith3D or any other project.

Marvin

#29

I’ve been thinking a lot about Vecmath libraries lately. I’ve come to the conclusion that it simply can’t be done “nicely” in Java. For example, supporting read-only Vector3f would need “const” support in Java, but that’s horrible thing as it pollutes entire code bases. It can be done somewhat by interfaces, but that’s not good for performance and is not ideal either.

I’ve come to similar conclusion with properties in Java (instead using getters and setters). I thinked and tried few approaches (and searched web for ideas), all had major drawbacks, I then realized that getter/setters are simply the best option, their only drawback is that you have to type more, but that’s not much issue because we have powerful IDEs.

Also, with physics library, you have to already somewhat translate between graphics and physics layers, so wrapping between different Vecmath libraries is not much problem. Maybe I can add “float x,y,z” versions to some “public” and supposedly to be widely used methods to ease this, as darkprophet suggested.

So my conclusion is, that I will stick with official “javax.vecmath” library, and everything that is not included can be added through utility static methods, we as Java developers are using them a lot already, so no issue :slight_smile:

Marvin I’m sorry about it, but I think that Vecmath2 don’t add much value (at least in current version) to switch from official Vecmath (or developers’ own implementations).

#30

just for a note: the next version of Java3d (and vecmath) will also have GPLv2+CP ex as license (1.5.2). The 1.6 release is planed to be the “big changes” release but I am pretty sure that this release won’t happen this year.
1.6 is probably the release with the best chance to get a contribution approved.

#31

Good to hear :slight_smile:

#32

Hello jezek,

i know Bullet from Blender and it is fantastic to hear that you ported this library to java.
For me it would be very interesting to hear if i could use jBullet also in Jogl.
If this is possible could you please post an example how to realize this.

Anyway, keep on with this good work and thank you for making this public available!

With kind regards
Marcel

#33

JBullet is fully independent of any 3D engine or graphics library/binding. You can use it with JOGL just fine. I don’t use JOGL so I have no plan to create any JOGL examples. But as both LWJGL and JOGL are OpenGL bindings, it should be pretty similar.

#34

That sounds really good.

But maybe you can help me a little bit with an example to start.

If i have constructed a world (extended to 1000 units) with a plane in my OpenGL display method how can i create
gravity for the world and a sphere which is affected by this gravity settings falling on a plane in this world:

(assuming a constant frame rate)

display(GLAutoDrawable drawable){
gl = drawable.getGL();
…
gl.drawSphere();
…
gl.drawPlane();

}

Any help or a code snippet is really appreciated!

#35

I would get the source code since I believe it contains the sources for all of jezek’s demos, which should give you an idea on how to set up the physics and run the simulation. If that doesn’t give you what you want, visit the bullet webpage and read bullet’s user guide.

#36

I’ve just compared the ragdoll demo in the Java port and the original Bullet SDK (v2.66). The Java version is WAAAY faster. What gives?

#37

I’ve been looking at both Bullet’s and jezek’s code fairly heavily and my first guess would be because jezek uses object pools while a lot of the functions for Bullet create unnecessary new objects.

#38

hmmm: I spoke too soon. I built Bullet on my work computer using Visual Studio 2008 express edition - that’s where it ran slowly. I build it at home using Visual Studio 2005 express edition and that ran much better - a little better than the Java port, particularly under high load.

It might be something about the project conversion to 2008 that stuffed it up? Who knows :slight_smile:

At any rate, this port is pretty impressive for only being a few days work so far. Really looking forward to seeing a website for this project and seeing what we can do with this puppy!

Great work, jezek!

#39

New version available on JBullet homepage.

Changes in release 20080206:

  • Memory optimalizations
  • Added heap info
  • Implemented HeapSort
  • Added optional support for GNU Trove
  • Added BspDemo and fixed ConvexHullShape
  • Added ConcaveDemo and it’s supporting classes
  • Abstracted OpenGL rendering
#40

Oooh, I may just have to use this. Awesome! :smiley: