issue with movewithcollsion

[masterdon]

Hi Everyone,

I am trying to prevent collision of ribbon elements when they are dragged.

https://www.babylonjs-playground.com/#VMFNH#50

However its not working. What am i missing here? I have also tried setting various ellipsoid property to mesh. however it didn't worked as well.

[dbawel]

Far too complicated to make this work as is... from my experience. Use Cannon or Oimo extensions and it will work. Otherwise, I hope you are a math wizard.

[masterdon]

@dbawel: any example implementing these extension on babylon mesh?

 

here is my attempt. https://www.babylonjs-playground.com/#VMFNH#51 enabling physics engine on page.

[Wingnut]

Hey guys!  Masterdon, I don't think physics engine OR BJS builtin collision system... is going to work for this kind of colliding.

I'm afraid that the "math wizard" method is the only way to accomplish this.

But there's hope.    https://www.babylonjs-playground.com/#VMFNH#52

I really didn't expect intersectsMesh [in line 160] to work, when two flat-laying ribbons intersect, edge-to-edge.  But it DOES work.

When you try to "install" intersectsMesh testing into onPointerMove, you are going to have a real challenge.  Let's pretend USER moved that left ribbon with the mouse.  They moved it along X, and when intersect happens, you will likely want to disallow further +x movement.  BUT, you want to allow ALL other drag-moves EXCEPT +x. 

Aside:  I think it is wise to ALWAYS set arcCamera alpha = -Math.PI/2 for this type of stuff, so camera is aiming +z, no matter the camera.beta setting.  It just makes life better, in general.  (imho) 

So, you will want to "derive" WHICH edge of the bounding box... had the intersect.  In other words, if right edge of tile1 intersected, no more +x dragging allowed, but you still want to allow dragging left, up, and down, yes?  You bet.

Are you ready for THIS tumor-causing idea?    You COULD put thin invisible ribbons/planes along ALL edges of each tile.  Let's call them edge intersection sensors (EIS).  For these corner tile shapes, you need 6 EIS to completely surround the tile.

With careful EIS intersect testing inside your onPointerMove func, you can determine which directions of drag... are allowed, and which are NOT allowed.  With me?  Gruesome solve, eh?  I'm not SURE it will work, but, in theory, it should.  drawRoomRibbon() will get much fatter, and so will onPointerMove(). 

The other two non-math-wizard ways... using physics engine collision, or BJS built-in .ellipsoid-to-.ellipsoid checkCollisions system (moveWithCollisions)... will probably NOT be accurate enough for your needs.

In a way, you are building a snap-to-position system, eh?

Ok, let's talk for a moment about the math wizard way.  Every mesh has a boundingBox and its best-friend... boundingInfo.  These "things" try to maintain an .extends size all the time, and those .extendxxxx properties... can be queried from inside onPointerMove.  It's not easy, but you are a superhero, so you can do it.  Using our example playground... while user is dragging tile1 to the right, you must "find" ANY mesh that are RIGHT-OF the moved mesh (there could be more than one), and make sure that THEIR getBoundingInfo().extendsWorld.x is NOT overlapping tile1.getBoundingInfo().extendsWorld.x.  With some careful calculating of boundingBox sizes, you can determine WHERE the left edge of tile2 is located, and where the right edge of tile1 is located.  That allows you to test if they are about-to overlap.  If they are about-to overlap, you can prohibit +x movement on tile1.  Gruesome, eh?

One other problem with this.  Bounding boxes are always square, so the "notch" in these corner pieces... will not be handled correctly.  I have turned-on the .showBoundingBox on tile2, and lowered pos.z on tile1... to illustrate this.  [link] 

So, if later, you want to use this same "system" to drag a table or other furniture... into that "notch" area... it will refuse to drag into that notch, nicely.  This is because the bounding box cannot have a notch in it (it can't perfectly match the shape of the corner tile).  Trouble, eh?

Let's pretend the notch is cut a bit deeper... until the notch area is 1/4 of the area of the tile.  THEN... do you see that... the corner tile is 3/4 filled-area and 1/4 empty-area?  THAT would be better for you, in my opinion.  THEN... you might notice that a corner section is made-up-of THREE smaller square tiles - ALWAYS square tiles.  Corner tile shapes like these... are actually three "sub-tiles"... parented together.  EACH sub-tile is square.  So now you CAN get accurate boundingbox .extends measuring, and you can put a table into that corner of the room, and it will drag all the way into the notch, perfectly.  Each corner tile is made from 3 "sub-tiles", parented-together in a certain way.

In the end, ALL your wall sections will be made-from one or more square sub-tiles, parented together to make various "compound tiles"... of any shape you choose.  BUT... this makes onPointerMove boundingBox measuring... even MORE complex, although the whole system would be powerful and versatile.  In a way, you are making a "voxels" system, I guess.  *shrug*  (like I know what voxels are)  hehe

Meantime, think about this "all compound tiles are made from combinations of square sub-tiles" -idea... even for the EIS system.  When all sub-tiles are square, they each need 4 invisible edge sensor mesh... easier.  When three sub-tiles are parented-together to make a corner tile, their EIS will be intersecting each other but you won't test intersection on those edges.  Those are intersections caused by parenting 3 sub-tiles into a corner shape... and that intersecting is good, and wanted, and won't be tested-for in onPointerMove.  Those might be called "incidental" intersections (caused by grouping/parenting)... and those are expected and won't affect dragging.  You may need to mergeMesh(all three parented-together sub-tiles) in order to get the edgesRenderer to treat them as if they are a single mesh... but that will cause a SINGLE square boundingBox once more, and then you have notch problems again.

Here's an idea for THAT issue.  Don't use edgesRenderer IF you use thin little planes (EIS) along edges for edge intersection testing.  Instead, make the thin planes... red, and visible.  Let the edge sensor planes... be your red lines.  Leave them visible... what the heck.    I think you COULD get fancy, here, too. What if "edgeSensor" is a new kind of mesh you invent?  What if there is an "intersection observer" on this new type of mesh... and it is a smart mesh... constantly watching-for being-observed-for something intersecting with it, and when that happens, it screams-out "Hey... I just collided!  Here's what I know:" => observerInfo(everythingKnown).

Intelligent red lines, monitored by observables system.  Cooooool.

Phew, eh?  I'm pooped.     Others may have better ideas.  Geez, let's hope-so, anyway. 

[Pryme8]

http://www.azurefromthetrenches.com/introductory-guide-to-aabb-tree-collision-detection/

[adam]

Expanding on @Wingnut's idea:

https://www.babylonjs-playground.com/#VMFNH#55

[adam]

In that particular example, you could create 2 hidden box meshes for each of those ribbon meshes that are used just for testing collision. 

Something like this:

https://www.babylonjs-playground.com/#VMFNH#57

(I just created the boxes for the left shape)

[Pryme8]

The thing you are going to have trouble with is the fact is is a concave shape.  
There is some reading you should do 
http://www.cs.cornell.edu/courses/cs3152/2013sp/lectures/18-Collisions.pdf
http://www.metanetsoftware.com/technique/tutorialA.html#section0

The second link is really good.  http://www.dyn4j.org/2010/01/sat/
this will explain the difference between convex and concave.

Because of your shape like @adam has said you need to split the shape up as far as the calculations are concerned.

[adam]

With children mesh collisions working:

https://www.babylonjs-playground.com/#VMFNH#59

Look Ma!  No math!

edit:  to be far, there are no response to collisions either

[Wingnut]

VERY NICE!  You guys are great!

[Wingy makes some delicious and comforting aspirin & barley soup for Masterdon's return.] 

I'm not sure that convex and concave apply to this, but maybe I wasn't paying attention to something.

[Pryme8]

Concave and convex always apply when doing collisions tests Adam just split the concave shape into two convex ones which is the correct process. (I did not look at the PG but I assume that's what he did)

[masterdon]

You guys are genious.....good stuff 

[masterdon]

Hi Guys,

Facing one weird issue. I have used  most of the same code from pg shared by @adam. . i am creating the sub collision convex by specifying height width depth as it may be different for the shape specified. all works fine in pg here https://www.babylonjs-playground.com/#VMFNH#60 

However, this sub meshes are not positioned correctly on my main code. elements are positioned in wrong place even after specifying the parent as main ribbon mesh. what could be the issue here?

 

 

[masterdon]

No worries. fixed now.