Question about collision detection and contact joints

I've got a bunch of objects grouped into spaces depending on what should collide with what, and each frame I call space.collide(otherSpace) for each set of spaces which should collide.

I use a simple collision listener from a demo which simply checks if the colliding bodies are connected by a joint. If connected, false is returned, otherwise a large amount of Coulomb friction and a low bouncyness is set before returning true. (Which creates a contact joint between the bodies, according to the ogreODE source)

Sometimes I need to check if two specific geometries collide (for instance, a "grappling hook" and a box). The objects are located in different spaces, which I don't run .collide() on so the hook won't bounce off the box instead of going through it. I do this by running hookGeometry.collide(boxGeometry) and check if the number of contact points are >0.

Since running .collide on a geometry will create contact joints between the bodies I'm wondering how this will affect the system. I specifically placed the hook and box(es) in different spaces to not get collision joints generated for them but I now realise I might be working against my own design by colliding the geometries and returning true in the collision listener.

I know I could just switch to a different listener, which will always return false, when checking if non-colliding geometries intersect. But since I've not noticed any weirdness going on between the hook and the objects it picks up I'm wondering if it's neccessary. I just don't want this thing to come back and bite me in the ass later on...

Is there already an easy way to just check for intersections in ogreODE without generating contact joints (no collision listener needed) which I have missed?
I guess it would be something like calling dCollide for geometries in ODE and just not do anything about the generated contacts. But that feels like going around the wrapper, which I don't like. I prefer working through the same API for all things which belong to it.

I'm doing this in Python in case it matters.

I dont get what is the problem.. If you dont want your hook to push the box just return false.. I do this by calling a collision method of every object that collided, if it returns false, the listener will return false I guess you just want to know if the hook is in the box, but dont want to react on this, then you could go with my idea.

Thanks for your reply.

The problem is that the collision listener has no idea that one of the geometries is the hook and it should return false.

As it is now, my geometries have no reference back to my game objects. I didn't see any need for it earlier, and I didn't know there was a set/getUserObject method in Geometry until just now.

I also didn't want to make the collision listener to make unnecessary calls to objects which should always either collide or not collide, which is the majority of all the objects in game.

The only exception is this hook, which needs to test for collisions but still pass through objects so it won't push them around.

Anyway, I just noticed that geometry.collide takes a second optional parameter which is the listener. Guess I'll just give it a bogus listener...

*sigh* The downside of working in Python vs C++, "IntelliSense" and code-completion can't always figure variable types out and help you on the way... Will have to start checking the API references and sources more often...

I see. Well then, I think these are two possibilites: make a user object for the hook (its enough if you only do it for the hook, you can check if there is a user object, if so return false, or if so, return users object return value) or make a second collision listener. I propose version a.