I was talking about storing the data in the pointer, and not interpreting the data as a pointer - that way we no longer need to worry about memory leaks. i.e. bypass type safety and use:
int mask;
dGeomSetData(geomId,*(void**)(&mask));
and, other way,
void * mp = dGeomGetData(geomId);
int mask = (int)(&mp);
Yes, its horrific, but it makes storing that mask really easy as there is no memory leak risk. Seeing as your not even exposing that geom data right now, in the C++ or Python API, I don’t see much of a problem with abusing it for this. Especially as there are work around using the id in a hash table or just using the get/set data of the body object. (And you can always assign a body to a static geom and have it permanently disabled.)
That masking solution you suggested will work though - it supports everything that is required at any rate, though I’m not sure how well it will scale to larger situations - its quite limiting in regards to how complex you can make the interaction. It would be far better to have the collide mask on a per object basis and do make callback event if ((callback1|callback2)&((category1 & collide2) | (category2 & collide1)))!=0
(I put an | between the callback masks, you could consider a & also - not sure which is best.)
Hmm, indeed it would prevent memory leaks, but it would only work if ODE or something else doesn’t dereference the pointer or so. Also, it wouldn’t allow us to add setData/getData functions later.
Here’s another, completely different idea: what about moving the setCollideEvent to the OdeGeom? The event names could be stored in an id table in the OdeSpace. We could still keep OdeSpace.setCollideEvent around for backward compatibility (it would simply always throw the event), and it isn’t more trouble for you than calling setCollideEvent instead of setCollideIdUsedForEvents or so.
This solution is more straightforward and in the end its the same thing as your suggestion, but simpler.
Would that interface allow you to limit events to collisions between two objects only when they are different types, ignoring collisions between objects of the same type though? I don’t see how it would. That is essential functionality - you do need very fine grained control here. In a fully featured game you are going to want to know about the vast majority of events and just prune very specific but regular events, like bumping into the floor or bumping into units on the same side. There has to be some kind of test for if we care about two objects colliding - masks or ids with a lookup table both achieve that. Getting all collisions for a subset of objects on the other hand would be not much better than the current system. In fact, for my pyweek game it would be identical, and actually slow things down due to the extra tests happening internally.
For storage I was only making a suggestion that is easy and avoids potential issues - using a hash table inside the space would work for every solution that has been suggested in this thread, its just more work. I don’t care so much about that though - its just an implementation detail when its the capabilities that really matter.