Enter, Inside, Leave distinction with contact manifolds

[toglia]

Hello again! Isn't the title's size restriction too small? I was going to start with a "yet another thread about"...

So, after some investigation I found out there's a life time variable on the btPersistentManifold that basically helps you know whether a contact is new. I tried it, it works fine , BUT:

If I do something like:

Code: Select all

if (pt.getDistance() < 0.f && pt.m_lifeTime < 2) {

with a btGhost that has CF_NO_CONTACT_RESPONSE I'll get true when it enters AND when it leaves the "trigger". Now, is there a way of knowing when a collision object has entered or left the btGhost/Trigger separately?

Before knowing about the m_lifeTime variable I did this by storing and checking new vs old objects in a contact list. This worked, but looks like an overhead now.

Thanks.

[Erwin Coumans]

I've not looked into this test for a while, and I'm a bit too busy to digg into this right now. At some stage when we implement unit tests, the enter/inside/leave would be a good test to include.
See http://code.google.com/p/bullet/issues/detail?id=384

You might want to stick to your own workaround for now,
Thanks,
Erwin

[toglia]

I've not looked into this test for a while, and I'm a bit too busy to digg into this right now. At some stage when we implement unit tests, the enter/inside/leave would be a good test to include.
See http://code.google.com/p/bullet/issues/detail?id=384

You might want to stick to your own workaround for now,
Thanks,
Erwin

I think you got me wrong, sorry. I'll start again.

My problem:
I need to know when ghost or rigidbody collisions are new, currently touching, or have stopped touching. (Enter/Inside/Leave Callbacks...)

Fact:
I have read in the forum from official sources that the life time variable (m_lifeTime) of the contact manifold point could be used to know this.

Test:
I have found that using this variable like mentioned does not offer a final solution cause:
1) Rigid bodies when colliding can stay in m_lifeTime = 1 for several frames. (note I would just need the first)
2) Ghosts with disabled collision response can make this m_lifeTime = 1 when entering and when leaving the collision.

Question:
Does bullet provide additional information that can be used to know whether these objects have truly started/kept/stopped touching, or do I need to keep track of this my self like mentioned before with a list or something?

Thanks again Erwin.

P.D.: If you didn't get me wrong please excuse me, I didn't know why the unit testing had to do with this, are you working to solve this of future versions, maybe?

[ludovic.silvestre]

Hi toglia, I also had the same problem and decided to use a list to check for new/old contacts, and I do believe it's the best way to find if an object entered/stayed in/leaved a collision.

Before explaining myself, I must warn you that I'm pretty new to Bullet and may have a wrong perception on how collision detection works.

The problem with m_LifeTime is that it represents the lifetime of a contact point, not a collision between two objects. The class btPersistenManifold does represent a collision between objects and contains at most 4 contact points.
Basically what I'm trying to say is that two objects could collide permanently (stay in collision), but the manifold could have different contact points in each physic steps, because the manifold added/removed contact points in each steps.

[Erwin Coumans]

Per-contact point lifetime is not reliable for this indeed.

Another solution would be to add a lifetime to the manifold (btPersistentManifold) in addition to per-contact point. The lifetime would increase, as long as there is at least one contact point in the manifold.

If we pass this information in the add/remove contact point, it could be used to distinguish enter, inside and leave events.
What do you think?
Thanks,
Erwin

[toglia]

Sorry I didn't read this earlier.

Personally I find it highly important to know these states per PersistentManifold. It's useful for almost every scenario I can think off, so having a final solution for this would definitely be appreciated.

I ended up using the new vs old list compare, but I'm not sure if its the best solution judging from my little experience in high performance programming.

Your solution seems clean enough. Maybe it can be implemented in the next release?

[DanielS]

So did a solution for this make it into bullet?