Ignoring collisions on the fly

[Antodologo]

Hi there!

We are making a physics based game using Ogre and Bullet. It has been great so far, and we have already the basic gameplay without much pain. All thanks to Ogre and Bullet teams

Now we face a problem we couldn't find anywhere, it is simple, but maybe not very common (or we don't know how to search for it, there a similar problem about spawning objects in this forum, but it doesn't answer the questions that follow).

We are using gContactAddedCallback to process the contacts in our game engine and do whatever necessary. But we find we need to ignore some contacts (and the consequences) depending on the state of the objects that take part.

So the first question is easy: Is there a way (inside the gContactAddedCallback if possible) to "remove" the contact point and avoid all the consecuences of the collision as if it had never happened?

And the next question, if that is not possible, is somewhat harder: What is the best way to know when a contact will happen and avoid it just in time to never see the results of the collision?

We can't use filters because the same collision can be valid or invalid depending on the state of the objects colliding. Ghost objects doesn't seem a solution neither because if collision is valid it must happen.

Hope you understand the problem

Thank you in advance

[Antodologo]

Hi again. Sorry but I really need your help

Maybe my message was not clear enough (my english is not that good sometimes) or maybe what I am trying is impossible.

I just need a way to detect when a collision will happen and avoid it before it really occurs. If this can't be done when a contact is added, maybe I can do something on the broadphase, before the contact is checked, and avoid further processing (this is not what I am looking for, but if it is the only thing I can do it would be good to know )

EDIT:

I think I will make this easier for all. If I solve this problem I will know the answer to all my questions and apply a similar solution to the other related problems.

Suppose I have an object that needs to be respawned somewhere in the world after being destroyed. When the object is respawned a position is selected as the best one, but the object shouldn't be colliding with another object already in the world. So what is the best way to check this before the object is effectively there? Do the solution involve ghost objects? Do I filter the collision until I am sure the collision will be valid? Can I spawn the object and avoid the collision if it is found? Can I iterate over all manifolds and just delete the ones I don't like?

I hope a real use case will clarify what I am really looking for. I can't guess what should be the best way to do something like that.

/EDIT

If I can get the info I need somewhere just point me there. I haven't found much documentation about collisions and callbacks. All I have found is on the forums and the wiki and was not enough for what I need.

Thanks again. At least the message has been read 100 times, now I suppose I need just one good answer

[Antodologo]

Hi Antodologo. Welcome to the forum!

When you respawn an object I would suggest you use the collision flags. You could place the object not visible and with CF_NO_CONTACT_RESPONSE and wait for Bullet update to check if any collision happened. If collision is found with the respawned object, it must be replaced or deactivated. If there is no collision after update, the object can be made visible and you can activate contact response again.

About gContactAddedCallback... it seems the recommended behaviour is to iterate over all manifolds so... forget about that kind of callbacks if possible (I just hope the InternalTickCallback is really recommended to check manifolds every iteration of the engine).

Don't worry about the lack of interest. I know you had been looking around in the forums and the information is scattered and confusing but trying 20 different solutions just answers almost every question. One day you will post your project here and they will understand what they don't understand right now. Just be patient

Greetings

[bone]

Well I, for one, enjoy your attitude . Sorry I can't be of much more help, though.

BTW, I think that *this* forum is more for generic coding/algorithm stuff for people who are building their own physics engines, while Bullet-specific questions should in general go here: http://www.bulletphysics.org/Bullet/php ... um.php?f=9.

[Erwin Coumans]

Hi Antodologo,

Welcome to the forums. Next time please post in the proper section, you posted in the general discussion section, but Bullet related topics should be posted in the "Bullet Physics SDK Discussion, Feedback and Bug Reports" section.

If you want more fine grain control to enable or disable response for contact points between two objects, on-the-fly, the easiest is the derive your own version of the btCollisionDispatcher, and override the virtual 'needsResponse' method, and add any logic you want there.

Would that work for you?
Thanks,
Erwin

[Antodologo]

Hey!! I had almost forgotten my post here. I just came back looking for another answer to a different problem and checked this out

I am sorry for posting on the wrong section. I supposed this question was not Bullet specific as long as the problem is common for any physics library, but I am glad with a Bullet-specific answer, even best for me.

I have been able to solve my spawn problem just using collision flags for objects that have been just respawned (CF_NO_CONTACT_RESPONSE) and wait for the physics update to iterate over every manifold. If a respawned object is colliding it is ignored for simulation (DISABLE_SIMULATION) and, if no collision was found, contact response is recovered for the respawned object. I found somewhat strange that objects with simulation disabled still generate manifolds, I don't know the reason for that, but I can stand it

Anyway I will check that 'needsResponse' method and post here if I find it to be a better solution

Thank you for your time. Hope this helps someone else. I know how hard it is to answer every noob that gets to the forum and point him in the right direction

Greetings


PS: We will show something interesting "soon" (soon = in a few months ). Your engine works better than expected, maybe even better than you expected