Collision detection is becoming the bane of my existence. I can do the simple stuff (spheres and AABBs), but I’m always running into loopholes and problems. I was wondering, is there a native Java 3D collision detection library out there that I can just use and that just works?
It looks like JBullet has just about anything I could want for collision detection, but can you use it separate from the physics? Is JBullet even still active?
Are there other options?
It probably comes down to how you are stepping your simulation. Maybe expand more about what problems you are having doing your own collision detection.
I’m sure there are numerous issues with my own collision detection code. I’m really more interested in using a library if it’s available though. This is one of those mathematically intensive things that libraries should readily exist for anyway (IMHO). It seems like everyone is just reinventing the wheel each time they need it. There’s numerous options out there for C and C++, so I’m just looking for a Java option.
Yes, JBullet can be used just for collision detection. Use CollisionWorld and CollisionObjects instead of DynamicsWorld/RigidBodies, or even concrete algorithm classes directly. Beware though that the collision part is optimized towards dynamic objects (eg. objects have some margin by default) and made with more universal interface, there are better approaches for static geometry (like specialized KDTree implementation with direct access to your data or having own internal optimized representation).
JBullet is active though the development is quite slow these days. But it’s actively maintained and supported and it will be for years.
Part of the issue of just a collision system is that in order to avoid a lot of those loopholes and things you need to know a lot about how, where, and how fast an object is moving. Simple static collision testing will not usually cover everything.
Thanks for the info on JBullet Jezek! I’ll dig into the JBullet source code and see if I can find where the algorithms are hiding.
Demon and Nate, I have a solid implementation for spheres, capsules, and AABBs (using swept spheres and corner rays for movement), but my biggest issue comes into play with (of all stupid things) walls. As long as my walls are axis aligned I’m fine, but once I rotate something or setup a diagonal it all falls apart. Then, when I go to add something more like OBBs, I start having troubles with OBB vs capsule detection, not to mention the whole issue of figuring out the best size and rotation of the OBB in the first place. And just when I think I’ve got it, players let me know that a few of them (odd that it’s only a few) can fall through the walls. I’m sure I would have an optimized collision detection system if I could build my own, but I’m getting frustrated with how one little thing turns into a dozen extra classes I have to write from a bunch of math algorithms that I still don’t totally understand… ouch, my head hurts.
falling throught wall can be due to the lack of precision of double/float, something like that you compute the position after collision and think it is still in front or just touching the wall (same for edges) but in realty it is a little behind and if you dont manage this case you go throught the wall, even if it happen rarely this is not soemthing that you can let player esperience too much
One advantage of JBullet’s collision system is that it has convex sweep tests (but use them with GhostObject for better performance). In my game I use these for FPS character. It just uses two sweep tests of capsule against static geometry. First towards the direction it’s moving and when it hits a wall it uses second to achieve sliding along the wall. There is also another sphere sweep test for vertical movement.
Convex sweep tests are really great because they can’t miss and if you maintain some little margin you can’t run into float imprecision either.
Does JBullet optimize large terrain objects at all? Meaning: if I feed the collisionworld a large mesh made up of numerous triangles (let’s use an ugly example of the entire interior of a building all as one mesh), will JBullet be testing whatever dynamic object I put inside against every single triangle for the mesh every update? Or does it break it down using something like an octree?
Not that I would do that mind you! I’m just trying to get an idea of how JBullet handles things.
[quote]Does JBullet optimize large terrain objects at all? Meaning: if I feed the collisionworld a large mesh made up of numerous triangles (let’s use an ugly example of the entire interior of a building all as one mesh), will JBullet be testing whatever dynamic object I put inside against every single triangle for the mesh every update? Or does it break it down using something like an octree?
[/quote]
Yes it does. Triangle tests are very expansive and partitioning them gives a very good boost in speed.
jME3 currently has a collision system that implements what you want, it might be possible to separate it so it becomes a general purpose collision system that can be used in any java game.
Guess I should have asked a singular question. Sorry.
[quote]Yes it does.
[/quote]
Yes to which one? It tests the object against every single triangle each update? Or it organizes it into an octree (or something similar)?
Edit: BTW, is jME3 available anywhere? I can only find info for downloading jME2 (which I tried a year or so ago).
I love this game, and the physisc engine looks very nice, last time you post about your game I bring the link to my job and we all play your game for one hour instead of unreal ! this was pretty fun
as you told about static geometric/mesh collision I would like to point something out (just in case nobody think of this yet) :
computing sphere collision to static mesh is exacly the same as computing sphere collision to moving/rotating mesh it
just requiere to change the frame of reference for the moving sphere
this barbare word just means to works in the object local axis, this way the moving/rotating object/mesh appear static to the moving sphere
and enable things like elevators / solid moving doors /etc… with no cost and without any collision engine modification.
how ? not really difficult but hard to explain…
here is an online applet demo => click on the image at the top of the website, (there is an invisible glasses/plane on the top of the table so the ball cannot fall) as you can see both sphere and mesh are moving and colisions/phsics works using the above technic. you can zoom with right button and rotate with the left one.
EDIT : typos, also sorry but the top glasses make the demo not really well explaning I will try to put a sample online with a different 3d model to better show the result
BvhTriangleMeshShape uses BVH (Bounding Volume Hierarchy) for culling. BvhTriangleMeshShape is for static geometry only, but there is also GImpactMeshShape for any type of geometry (also uses BVH). Not sure if that distinction matter in non-physics usage, but GImpactMeshShape has ability for trimesh to trimesh collision detection. Though it’s best to use convex shapes for dynamic objects (or compound of them), as they have full volume so there is a lot less chance for tunelling effect.
The BVH must be build before use, it might take some time for big meshes. There is support for serialization in original Bullet, I think it’s not ported in JBullet, I can port it if you need it.
[quote]BTW, is jME3 available anywhere? I can only find info for downloading jME2 (which I tried a year or so ago).
[/quote]
jME3 is still in active development and has not been officially released yet. You can get it from SVN in the jme3 branch:
http://code.google.com/p/jmonkeyengine/source/browse/#svn/branches/jme3
EDIT: heu… sorry… this is following a post a little above (this thread has been going too fast for me…)
sometime code better explain… below is the full physics code of the method moving the ball in the demo
public void moveBall(IScene3D s)
{
s.setScene3DObjectToWorld();
IMesh3D table=s.getMesh3DByName("TABLE");
IMesh3D ball=s.getMesh3DByName("BALL");
if(table==null || ball==null)
return;
gravity.set(0,-0.4,0);
force.add(gravity);
ballPosTable.toAxis(table.getAxis3D());
solid.getSource().copy(ballPosTable);
solid.getDestination().copy(ball.getPosition());
solid.getDestination().add(force);
solid.moveSlide(4);
ball.getPosition().copy(solid.getSource());
force.add(ball.getPosition());
force.sub(oldBallPos);
force.mul(0.475);
oldBallPos.copy(ball.getPosition());
ballPosTable.copy(ball.getPosition());
ballPosTable.toLocalAxis(table.getAxis3D());
s.setScene3DObjectToWorld();
}
DzzD: The code is kinda useless without the moveSlide method. Can you post it as well?
It may be a bit long source code and related to the 3dzzd 3d data storage, but anyway this one is just a “standard” sphere to mesh collision , it just means to move a sphere from its source postion to its desitnation position (with a maximum of 4 bounds), the full source code is available in the shared source code section in the 3DzzDDevKit thread (in net.dzzd.core.colsion) but sorry it is a pretty messy source code.
for example for static collision to mesh I would do :
solid.setSource(startposition)
solid.setDestination(endPosition)
solid.moveSlide()
thenewposaftercolision=solid.getSource();
the above source code show then how to do the same when the mesh is moving/rotating by saving the solid sphere location in its local axis before moving the mesh and then using this saved local position the next game cycle to perform colision of moveing mesh on sphere
I’ve tested it using the KinematicCharacterController against a mesh with 850 000 triangles. Takes around 40 seconds to load. Can walk around without problems for the most part. Slows down where there are concentrated areas of triangles.