Mesh intersection events for arbitrary combinations?

[ajselvig]

Hi, 

 

I've implemented a basic scene that uses the ActionManager and OnIntersectionEnterTrigger to detect collisions between two meshes. However, it seems like a new action manager needs to be created for every node in the scene, and a new action for every combination of nodes in the scene, if I want to execute code when any arbitrary pair of nodes collide. This leads to N! actions (where N is # of nodes in the scene), which can get out of control very quickly.

 

Is there a way to simply detect all intersection events that occur in the physics engine (I'm using Oimo) and execute a function? 

 

Thanks!

[GameMonetize]

Hello intersections are not handled by the physics engine for performance reasons

 

And for performance reasons again we cannot check all meshes but only those which have OnIntersection triggers

[ajselvig]

But they are being checked at some point. Somewhere (I don't know if it's Babylon or Oimo), there is a little piece of code that says "oh, these two meshes collided, let's apply opposing forces and preserve momentum, etc...". This happens for every mesh, regardless of whether there has been an OnIntersectionEnterTrigger applied. All I'm looking for is a hook into that function.

[GameMonetize]

No Intersections are checked ony for meshes that have OnIntersectionEnterTrigger/OnIntersectionExitTrigger or for meshes that are target of  OnIntersectionEnterTrigger/OnIntersectionExitTrigger :

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/babylon.scene.ts#L1023

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/babylon.scene.ts#L1241

[iiceman]

@ajselvig: If I understand right, then you can use Babylon to check collisions between specific meshes, just like DK said. The collisions for "everything" that you talk about are probably computed by Oimo. Maybe that's more like a question for the folks at Oimo JS. Maybe they fire some event when their physics engine computes those collisions? But I do not know about that (nor could I find anything about this when googling it).

 

Maybe the question is more about what you want to achieve in the end?

 

I assume you got a lot of meshes. So checking all combinations is out of the question? I remember I read something about efficient collision detection a while ago where a similar problem was mentioned. The idea there was not to check everything with everything but to limit the objects that need to be checked. Therefore (if I remember it right) they introduced a second step before the actual collision detection where they try to find the objects that need checking before actually running the collision detection.

 

So lets assume you have 10 000 meshes and you want an event when two of them collide. Instead of checking each of the 10 000 with all the other 9 999 you first find out what other meshes are actually close to the current one and then only check those. Maybe you can cluster your scene into a fixed number of sections and for each mesh that you check collisions with you only check those that are in the same section? Of course if you are checking a mesh that's close to the border of one sections you might want to check collisions with the meshes that are in this close sector, too. So instead of checking all 10000 you only check those that are in one of the four sections (try to imagine 4 cube like sections arranged in a 2x2 matrix) close to the one you are currently trying to find collisions with. In the worse case all 10 000 are in those four sections, but then you might want to increase the number of sections. The number of sections could even be set dynamically: start with 20 (big) sections and if the number of close meshes is too high you increase the number of (now smaller) sections until you get a reasonable number of objects that you need to check collision with.

 

You get what I mean? Not sure if I managed to explain it right. Well, was just an idea... let me know what you think ... maybe it's too much overhead and just makes things worse  ;P

 

Edit: maybe I even found the article from back then: http://buildnewgames.com/broad-phase-collision-detection/ not sure if it was this one but somehow looks familiar. The thing that I described is the Spatial Partitioning, I assume, so you might want to look into that. How to implement it depends on your sue case, of course. What I described above was just my very basic idea of how it works. Maybe one of the smarter than me guys around here has a better approach for you

[ajselvig]

>> The collisions for "everything" that you talk about are probably computed by Oimo. 

 

Yes, that seems to be the case. It's certainly happening, just not at the Babylon level. 

 

>> But I do not know about that (nor could I find anything about this when googling it).

Right, I also tried googling it. The engine seems to work very well, but the documentation is almost non-existent. 

 

>> Instead of checking each of the 10 000 with all the other 9 999 you first find out what other meshes are actually close to the current one and then only check those...

I get what you're saying, and it definitely make sense. I would tend to believe that Oimo is already using a similar algorithm for their collision detection, though. After all, these calculations do have to be performed for their system to work correctly. Writing my own is possible, but I'd like to reduce the complexity and tie into their system if I can. 

 

I'll try to investigate further to see if there's a way I can hack into Oimo. Thanks for the responses.

[RaananW]

Oimo has a CollisionDetector class, OIMO.CollisionDetector which is the parent class of 4 different implementation of collision detectors. They don't have any callback (something oike onCDollisionDetected), but they have a detectCollision function, what is being triggered while updating Oimo's manifest.

Maybe this is the place to look at... But this is truly out of Babylon's scope :-)

[ajselvig]

Thanks for the direction!