Feature Request: provide an alternative to b2Contact.SetEnabled that is persistant

[GoogleCodeExporter]

Disabling a contact persistantly for the duration of the collision requires 
mainting a list of disabled contacts which is way more hassle than simply 
having an additional flag in b2Contact that isn't instantly re-enabled on each 
step as e_enabledFlag.

(This assumes that calculating the contacts which must be disabled is expensive 
so that redoing that check in each step isn't really an option, which is 
currently the case in one of my projects)

Therefore, please provide an alternative to b2Contact.SetEnabled that is 
persistant until contact deletion (which I assume happens no later than when 
the bounding boxes of the bodies are no longer touching?) or if explicitely 
changed.

Original issue reported on code.google.com by jonas.thiem@gmail.com on 9 May 2013 at 2:21

[GoogleCodeExporter]

Please note I currently maintain a list of data structs, one for each 
b2Contact, where I need to do a lookup on each collision step. So this is not a 
theoretical problem and has an actual performance and code bloat impact.

Original comment by jonas.thiem@gmail.com on 18 May 2013 at 8:03

[GoogleCodeExporter]

If you *always* want the persistent behavior, you can comment out the line in 
b2Contact.cpp that normally re-enables the contact. At the beginning of the 
Update function, you'll find:

// Re-enable this contact.
m_flags |= e_enabledFlag;

Original comment by iforc...@gmail.com on 18 Jul 2013 at 5:08

[GoogleCodeExporter]

Sure but then I depend on a modified version of Box2D. That is rather 
undesirable behaviour (because it makes the build of my project more 
complicated).

Original comment by jonas.thiem@gmail.com on 18 Jul 2013 at 7:38

[GoogleCodeExporter]

And yes we do always want the persistant one. However, it would be really nice 
to have this in upstream. Depending on modified library versions sucks :-/

Original comment by jonas.thiem@gmail.com on 18 Jul 2013 at 7:46

[GoogleCodeExporter]

If you don't want a response, why don't you use a sensor instead?

Original comment by erinca...@gmail.com on 28 Oct 2013 at 5:46

[GoogleCodeExporter]

As I said above, I want to disable a contact *for the duration of a collision* 
(=until the involved fixtures are no longer overlapping). Not permanently. I 
don't think that can be done with a sensor? (I would need to turn a fixture 
into a sensor and back, that doesn't seem to be possible)

Original comment by jonas.thiem@gmail.com on 28 Oct 2013 at 9:11

[GoogleCodeExporter]

The problem is that b2Contact persists even when fixtures don't touch. The 
lifetime of b2Contact is tied to the overlap of the fixture AABBs. So you may 
disable a contact and never get a chance to re-enable it.

Original comment by erinca...@gmail.com on 29 Oct 2013 at 6:02

[GoogleCodeExporter]

That is interesting. 

The reason I chose to do what we do is because of speed, our collision callback 
jumps into Lua and therefore not as cheap as a simple C function call. 
Therefore I had the idea of limiting it to a single collision event, since that 
seemed to be the most natural less frequent choice.

I am just considering re-enabling the b2Contact after a given amount of time 
(possibly after doing an actual shape intersection check) to make sure it is 
re-enabled at some point even if the AABB overlap is still taking place.

For this timed solution, we would still need to keep our own b2Contact list, 
but we would only need to consult it after a given time and not each tick. This 
means, a persistant enable/disable would still save us performance because 
otherwise we need to do the list lookup for disabled contacts each tick.

So in conclusion, I would still be interested in this feature.

Original comment by jonas.thiem@gmail.com on 14 Feb 2014 at 1:30

[GoogleCodeExporter]

I don't think I can implement this feature robustly.

Original comment by erinca...@gmail.com on 4 Apr 2014 at 4:21

• Changed state: WontFix