Jump to content

issue with movewithcollsion


Recommended Posts

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.  :)

Link to comment
Share on other sites

The thing you are going to have trouble with is the fact is is a concave shape.  
There is some reading you should do 

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.

Link to comment
Share on other sites

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?




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...