Mesh to mesh collision

Hi!

I’m implementing a level editor in which I need to avoid the user to place objects overlapping other objects. There’re objects of really different sizes so user could, for example, place a bottle below a table so I need detailed collision checks so some objects could be inside the gaps of other.

I’ve tried using Node.collideWith(Collidable, CollisionResults) which ends up with an UnsupportedCollisionException if using any spatial as collidable parameter (it expects Ray or BoundingVolume). For this use case it’s not an option to use the bounding volume.

Also I’ve tried setting up physics (with minie) setting ghost controls with mesh collision shapes based on simplified low-res models and using GhostControl.getOverlappingObjects() but in the end uses AABBs so same here, not a good resolution collision check for this case

So here’s the question… Is there any way to do a mesh to mesh collision check in jme3 nowadays (or MeshCollisionShape to MeshCollisionShape in minie)? I know this could be a performance killer but I’m not using this in all frames, just in a callback when the user moves the object and not for all nodes in the scene, just a subset and also if a prior BB to BB collision is detected

Thanks

1 Like

JME doesn’t have anything like this built in and it’s a fairly complicated topic. (I have a book on my shelf that is devoted solely to mesh collisions… a whole book.)

You are probably better off representing your objects with simpler compound shapes in the physics engine and not using ghost controls.

OR when the small object is trying to intersect with the big one, model it as a handful of spheres that you use to collide with the scene with standard JME mesh stuff.

Thanks for your answer @pspeed

Yes, I know it’s a complicated topic, so I hoped there was something I could use already implemented in the engine.

I could use compound shapes or even simpler basic shapes for most (if not all) the objects, there’s no problem with that. What I don’t understand is how could I check the collisions among them. Also, should I use RigidBodyControl instead of ghost and fully use the physics?

My idea is to allow the user move everything freely but not allowing him to place the object in an inadequate way (colliding with stuff the object shouldn’t).

Current implementation is based on spatial.collideWith(bounding) works for most of the cases because I’m using as bounding parameter the smaller object between them but not as accurate as I would like it to be

Nah, the engine doesn’t have anything. (I’m not sure any game engine does, actually.) I guess games don’t usually have a use for an operation that would potentially take several seconds.

Your example of putting something on a table made me think of using a sphere to represent the bottom.

I’m not sure, but this might work for you:

CollisionResults bottleResults = new CollisionResults();
bottle.collideWith(table.getWorldBound(), bottleResults);

CollisionResults tableResults = new CollisionResults();
table.collideWith(bottle.getWorldBound(), tableResults);

int mult = bottleResults.size() * tableResults.size();
boolean collided = mult > 0;

In this case, mult will be greater than zero only if both CollisionResults detect something.

Minie implements mesh-mesh collisions. As you discovered, however, ghost overlap tests use AABB. Perhaps you could get exact collisions from ghosts, but I believe the best approach would be to use a contact test:

https://stephengold.github.io/Minie/javadoc/master/com/jme3/bullet/CollisionSpace.html#contactTest(com.jme3.bullet.collision.PhysicsCollisionObject,com.jme3.bullet.collision.PhysicsCollisionListener)

Not sure which would work best: GImpactCollisionShape or MeshCollisionShape.

Thank you all for your answers and proposals

@pspeed honestly, I don’t get your point :confused:

@fba I tried your approach and although it looks good, it’s giving me same collisions than my current method of using the smaller object bounding volume as parameter, let’s say always doing table.collideWith(bottle.getWorldBound())

@sgold I’ve tried the contactTest method but it’s returning 0 and the listener is not being called although there’s an obvious collision when having the collision shapes created as CollisionShapeFactory.createMeshShape (which in the end creates MeshCollisionShape objects). If I change it to CollisionShapeFactory.createDynamicMeshShape (which creates HullCollisionShape) it’s detected but again I’m losing resolution as the hull is bigger than the mesh. I’m using minie 4.0.2. Maybe mesh to mesh is implemented in a latter release?

1 Like

No, there haven’t been any major changes like that. Try using a GImpactCollisionShape; it has a constructor that takes JME meshes.

Thanks for the advice! I just tried it and GImpactCollisionShape is really detailed (almost same as MeshCollisionShape). Now that I’m using gimpact, the PhysicsCollisionListener.contact callback is called but contactTest always returns 0. Maybe an issue in minie?