Java port of Bullet
Java port of Bullet
Hello,
I've ported Bullet 2.66 to Java. The first alpha version is available here:
http://jezek2.advel.cz/tmp/jbullet-20080111.zip
And webstart on:
http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp
Currently only the BasicDemo is partly working, there is some problem with box/plane for ground, so spheres are simply falling down. Also it uses only SimpleBroadphase without removing overlapping pairs and it's only partly optimized, so it's pretty slow.
The remove of overlapping pairs is disabled because it touches some bug with SequentialImpulseConstraintSolver, which is accessing array out of bounds.
UPDATE 2008/02/07:
More information and latest versions can be found on JBullet homepage.
I've ported Bullet 2.66 to Java. The first alpha version is available here:
http://jezek2.advel.cz/tmp/jbullet-20080111.zip
And webstart on:
http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp
Currently only the BasicDemo is partly working, there is some problem with box/plane for ground, so spheres are simply falling down. Also it uses only SimpleBroadphase without removing overlapping pairs and it's only partly optimized, so it's pretty slow.
The remove of overlapping pairs is disabled because it touches some bug with SequentialImpulseConstraintSolver, which is accessing array out of bounds.
UPDATE 2008/02/07:
More information and latest versions can be found on JBullet homepage.
Last edited by jezek2 on Wed Feb 06, 2008 11:11 pm, edited 1 time in total.
Re: Java port of Bullet
I already posted over at JGO - but I post here again, in case you visit this board more often:
Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first post reads like size==1)
Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first post reads like size==1)
- Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Java port of Bullet
Wow, that is impressive work, how long have you been working on this? Can you describe your porting approach, did you use any automated tools, or manual find/replace?
Erwin
- It looks like interaction in the Java BasicDemo between spheres (sphere vs sphere and sphere vs box, a box spawned by the user) works fine, and so does picking.
- SimpleBroadphase is a good start, although it is exhaustive/brute force. More parts of Bullet (like its SequentialImpulseConstraintSolver) could be split up into a 'Simple' version and Optimized/Cache friendly version. Such Bullet Simple/Light/Educational version would help porting and understanding of code.
- It Would be good to figure out what is happening with the ground. In particular the btStaticPlaneShape should be fairly straightforward, as it doesn't rely on other algorithms (it doesn't need GJK, nor GJK but only the getSupportingVertex).
Erwin
Re: Java port of Bullet
Sorry, forgot to reply. For others, I also posted about the Java port on:irrisor wrote:I already posted over at JGO - but I post here again, in case you visit this board more often:
Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first post reads like size==1)
http://www.javagaming.org/forums/index. ... ic=18035.0
Re: Java port of Bullet
Hi, thanksErwin Coumans wrote:Wow, that is impressive work, how long have you been working on this? Can you describe your porting approach, did you use any automated tools, or manual find/replace?
![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Yeah, although there is a little but hardly visible bug, which I already fixed in my version (will be part of the next update, after I fix the bug I mentioned in the last paragraph of first post).Erwin Coumans wrote:
- It looks like interaction in the Java BasicDemo between spheres (sphere vs sphere and sphere vs box, a box spawned by the user) works fine, and so does picking.
Actually I didn't have too much problem understanding the code, Bullet has very nice structure. The simple versions are basically there with the #ifdefs or flags, and was sufficient for my porting needs (at least so far).Erwin Coumans wrote:
- SimpleBroadphase is a good start, although it is exhaustive/brute force. More parts of Bullet (like its SequentialImpulseConstraintSolver) could be split up into a 'Simple' version and Optimized/Cache friendly version. Such Bullet Simple/Light/Educational version would help porting and understanding of code.
Yeah I think too, but I'm now focused to hunting the bug I mentioned in the last paragraph of first post. I can already "fix" it by workaround, but I think that I have now fairly clear trace of origin of this bug. This bug costed me a couple of hours, but on the bright side, I learned more about Bullet internals, which is always goodErwin Coumans wrote:
- It Would be good to figure out what is happening with the ground. In particular the btStaticPlaneShape should be fairly straightforward, as it doesn't rely on other algorithms (it doesn't need GJK, nor GJK but only the getSupportingVertex).
![Smile :)](./images/smilies/icon_smile.gif)
Sure, I willErwin Coumans wrote:Please keep us posted if you make some progress,
Erwin
![Smile :)](./images/smilies/icon_smile.gif)
Re: Java port of Bullet
I've uploaded new version: http://jezek2.advel.cz/tmp/jbullet-20080116.zip
Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp
Changes:
- Moved all push/popProfile to try/finally blocks
- Added final for Vectors/Transforms/etc fields where applicable, and fixed some discovered bugs
- Fixed bug with non-functional removeOverlappingPair
- Enabled ground BoxShape in BasicDemo
- Implemented drawing of BoxShape
- Fixed VectorUtil.maxAxis
Known issues:
- collision of boxes has some bug
Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp
Changes:
- Moved all push/popProfile to try/finally blocks
- Added final for Vectors/Transforms/etc fields where applicable, and fixed some discovered bugs
- Fixed bug with non-functional removeOverlappingPair
- Enabled ground BoxShape in BasicDemo
- Implemented drawing of BoxShape
- Fixed VectorUtil.maxAxis
Known issues:
- collision of boxes has some bug
- Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Java port of Bullet
Wow, you are making good progress, and the Bullet Java performance is very good.jezek2 wrote:I've uploaded new version: http://jezek2.advel.cz/tmp/jbullet-20080116.zip
Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp
Have you checked the btPersistentManifold class, or contact management? Is looks like some contact normal is wrong. Also, using the btStaticPlaneShape might help figuring out what is wrong (it doesn't reply on GJK or EPA collision detection algorithms, so it is easier to debug).Known issues:
- collision of boxes has some bug
Thanks for the update,
Erwin
-
- Posts: 6
- Joined: Mon Aug 28, 2006 2:35 am
- Contact:
Re: Java port of Bullet
This is impressive! Do you plan to have a website for jBullet?
Re: Java port of Bullet
Thanksjfelrod1960 wrote:This is impressive! Do you plan to have a website for jBullet?
![Smile :)](./images/smilies/icon_smile.gif)
Re: Java port of Bullet
New version: http://jezek2.advel.cz/tmp/jbullet-20080122.zip
Webstart demos:
BasicDemo
GenericJointDemo
Changes:
- Fixed convex/plane collision detection
- Added GLDebugDrawer and fixed some bugs
- Added CapsuleShape
- Added ConeTwistConstraint, HingeConstraint and Generic6DofConstraint
- Added GenericJointDemo
- Optimized drawing of spheres and cylinders using display lists
- Fixed collision of boxes
- Added text overlay
Enjoy![Smile :)](./images/smilies/icon_smile.gif)
Webstart demos:
BasicDemo
GenericJointDemo
Changes:
- Fixed convex/plane collision detection
- Added GLDebugDrawer and fixed some bugs
- Added CapsuleShape
- Added ConeTwistConstraint, HingeConstraint and Generic6DofConstraint
- Added GenericJointDemo
- Optimized drawing of spheres and cylinders using display lists
- Fixed collision of boxes
- Added text overlay
Enjoy
![Smile :)](./images/smilies/icon_smile.gif)
- Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Java port of Bullet
Very impressive, it looks almost identical to the C++ version. It looks quite stable and fast, except for some occasional jitter, you might have noticed that?
On the math library discussion here: http://www.javagaming.org/forums/index. ... ic=18035.0
Have you considered to just port and use Bullet LinearMath classes like btVector3, btQuaternion and btTransform?
Changing the math operations throughout the entire library can be error-prone and makes maintenance a bit harder. For Bullet 2.x we probably stick with LinearMath, to keep the interface stable. More radical changes, possibly a full rewrite or change in math library might happen in a separate future project, like Bullet 3.x. We don't need to worry about that now.
Thanks again,
Erwin
It would be really nice to remove the security/permission issue. How much work is it to add support for a software render? So there is no 'trusted' OpenGL Java binding, without requiring permission?jezek2 wrote:The demo uses OpenGL (LWJGL), I'll later add support for some software 3D renderer (probably jPCT or something like that).darkprophet wrote: If its a port, how come the webstart wants to run without permissions?
On the math library discussion here: http://www.javagaming.org/forums/index. ... ic=18035.0
Have you considered to just port and use Bullet LinearMath classes like btVector3, btQuaternion and btTransform?
Changing the math operations throughout the entire library can be error-prone and makes maintenance a bit harder. For Bullet 2.x we probably stick with LinearMath, to keep the interface stable. More radical changes, possibly a full rewrite or change in math library might happen in a separate future project, like Bullet 3.x. We don't need to worry about that now.
Thanks again,
Erwin
Re: Java port of Bullet
Yes, some bug is still crawling somewhereErwin Coumans wrote:Very impressive, it looks almost identical to the C++ version. It looks quite stable and fast, except for some occasional jitter, you might have noticed that?
![Smile :)](./images/smilies/icon_smile.gif)
No, there isn't and probably won't be. There is one possibility, to use LWJGL as a webstart extension, which can be then signed separately. This allows to run just the OpenGL binding with all permissions, but the application stays restricted. This doesn't solve the issue though.Erwin Coumans wrote:It would be really nice to remove the security/permission issue. How much work is it to add support for a software render? So there is no 'trusted' OpenGL Java binding, without requiring permission?jezek2 wrote:The demo uses OpenGL (LWJGL), I'll later add support for some software 3D renderer (probably jPCT or something like that).darkprophet wrote: If its a port, how come the webstart wants to run without permissions?
I think that it shouldn't be that much work to add software mode, when I use some good library for it (like jPCT, but I'll look for others too).
The situation is little different in Java, there is official Sun's vecmath library (using official "javax.vecmath" package). It's good for interoperability between apps and different libraries. Because the usage is a bit different from C++, I had to rewrite (port) it anyway to use it. There are still portions of LinearMath in utility classes, because Vecmath doesn't have all functionality. Transform is also from original LinearMath.Erwin Coumans wrote: On the math library discussion here: http://www.javagaming.org/forums/index. ... ic=18035.0
Have you considered to just port and use Bullet LinearMath classes like btVector3, btQuaternion and btTransform?
Changing the math operations throughout the entire library can be error-prone and makes maintenance a bit harder. For Bullet 2.x we probably stick with LinearMath, to keep the interface stable. More radical changes, possibly a full rewrite or change in math library might happen in a separate future project, like Bullet 3.x. We don't need to worry about that now.
There is effort to standarize on Vecmath2, which is evolved version of the official Vecmath library, that can be extended, is truly opensource, and has more features.
To satisfy all parties, I'm leaning towards multiple builds for both Vecmath libraries, so developer can freely choose which one he prefers.
Re: Java port of Bullet
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
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
- Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Java port of Bullet
That looks good, very cool!
There is still some occasional boxes jumping up into the air just before they go to rest, in the BasicDemo.
And software renderer that doesn't require permission would be nice, but I suppose the abstraction is the first step.
Did you already make effort to isolate the problem, figuring out when this 'jumping' happens?
Thanks,
Erwin
There is still some occasional boxes jumping up into the air just before they go to rest, in the BasicDemo.
And software renderer that doesn't require permission would be nice, but I suppose the abstraction is the first step.
Did you already make effort to isolate the problem, figuring out when this 'jumping' happens?
Thanks,
Erwin
Re: Java port of Bullet
Not yet. I'm now focusing on other things and to actually use it in my applications. I will try to look into it soon though.Erwin Coumans wrote:Did you already make effort to isolate the problem, figuring out when this 'jumping' happens?