Stop mesh without collision

[BabylonFan]

Hi! I'm new to this so this is probably a dumb question.. Been trying to make a game where object moves through labyrinth without going through walls. I implemented collision detection to the point where I'm sure its working but when I tried to move it with .position method there was no collision happening so I ended up using the moveWithCollisions method. This works but once you press the button the object starts moving and doesn't ever stop it just changes direction at another key press. It also increases speed and both of this thing make it very useful to move it through gaps in the walls and navigate it.. So is there a way to control speed and stop mesh before there is a collision/intersection? Or is there a whole different better way to implement movement of that kind? Any advice, opinion and info welcome and thanks so much  

 

This is how code for one key press looks like: (sphere is the object we're trying to move - i have yet to import it but at least I know how to do that)

window.addEventListener("keydown", function(evt) {

if (evt.keyCode==87){//forward

                    scene.registerBeforeRender(function () {

                        sphere.computeWorldMatrix(true);

                        //labyrinth.computeWorldMatrix(true);

                        if (!sphere.intersectsMesh(labyrinth, true)) {

                            //sphere.applyImpulse(new BABYLON.Vector3(premikanjeX, 0, premikanjeZ), sphere.position);

                            var forward = new BABYLON.Vector3(parseFloat(Math.sin(parseFloat(sphere.rotation.y))) / 8, 0, parseFloat(Math.cos(parseFloat(sphere.rotation.y))) / 8);

                            sphere.moveWithCollisions(forward);

                        }

                    });

}

}, false);

 

 

[iiceman]

Hey there and welcome to the forum. It might be a good idea to provide a playground example with you current approach so we can see your code in action and help you find a fix easier.

 

Here is an example i threw together in the awesome babylon playground: http://www.babylonjs-playground.com/#2T2IC

 

It's based on a tutorial from temechon about moving with physics (http://www.pixelcodr.com/tutos/physics/physics.html), but the basic idea stays the same with moveWithCollisions.

 

It seems you want to do things  a little bit differently since you only want to move your sphere according to it's current rotation but maybe the example helps you though.

 

I am not sure how exactly your example works... I don't think you need that !sphere.intersectsMesh.. stuff since the move with collisons does that already for you if you enable collisions in the scene. Maybe you just forgot to reset your forward vector on keyup?

 

I hope any of this helps. If not, try to create your own playground example and I am sure we will find a solution

[RaananW]

Hi,

I noticed you have tried using the physics engine for that (apply impulse). I assume it don't work out so well, but I think it will actually fit your use case. Care to share your experience?

Just a small not, rotation.y is always a number, there is no need to parse it as float. So is the result of math.cos.

[BabylonFan]

It's hard to use playground since I have some imported meshes in my code + there is so many more things happening that it's a big pile of stuff right now xD otherwise I don't have any real experience with the physics engine so I would really love it if I can avoid using it thanks for everything I'll try to figure out a way to implement the example in my code

[Vousk-prod.]

Just a little question about oimo and cannon : could we also use physic and collision while moving objects with mouse drag or physics engine systematicaly require impulses or velocity vectors to move objects ?

[Temechon]

 

 

physics engine systematicaly require impulses or velocity vectors to move objects

 

This.

[Vousk-prod.]

Ok, I was pretty sure of this. Thanks.

[Wingnut]

Hi guys.  Fenomas gave us an interesting reminder, recently.  He said something about physics objects often being launched into movement... with physics "springs".  I have not tried a demo with that idea, yet, but I sure plan on it, someday.

And, don't forget you can move physics-active mesh using standard positioning methods... IF you call mesh.updatePhysicsBodyPosition() afterwards, like line 64 in this demo... http://playground.babylonjs.com/#A4HF3#6

And, overlapping mesh impostors will cause them to automatically de-overlap... http://playground.babylonjs.com/#8KNKC#11

And, don't forget about gravity.  Using a 500 mass anvil and a teeter-totter ... well, you get the idea. 

I don't know what 'systematically' means, so maybe none of these methods are 'systematic'.  Also, these are all starting methods, not stopping methods.  Setting the mesh physics state AGAIN... (especially with BABYLON.PhysicsEngine.NoImpostor) might stop a mesh in its tracks.

Admin, it might be wise to adjust any inconsistent spelling of impostor in our source code.  https://github.com/BabylonJS/Babylon.js/search?utf8=%E2%9C%93&q=imposter&type=Code

Only one playground series was found that used the wrong spelling within code... http://playground.babylonjs.com/#HMFDE#0  (and #1 and #2).  They look abandoned and broken for different reasons, so maybe not worth repairing.

[Vousk-prod.]

Hi guys.  Fenomas gave us an interesting reminder, recently.  He said something about physics objects often being launched into movement... with physics "springs".  I have not tried a demo with that idea, yet, but I sure plan on it, someday.

 

Ah ah, simulating king of spring interaction is the way I went some years ago (in VRML ) to move physical objects with the mouse (determining mouse acceleration and applying it as a velocity to the object with a little inertia to have smooth movement), I remember it was not a fun struggle to obtain something convincing (and by the way I did not obtain something convincing ).

I would have thought many years later physics engine would have provided an integrated way to drag mesh, but it seems not .

 

But since we can call mesh.updatePhysicsBodyPosition() everything is allright then, we still can move mesh with the mouse and have correct physics calcluations! Thanks for the piece of info Wingnut (and nice winter avatar ).

[Vousk-prod.]

(Hmm, in french we are often using the word "systematically" to mean "in all cases")

[Vousk-prod.]

Ok, I tried your suggestion Wingnut :

http://www.babylonjs-playground.com/#DJPVS

 

Pretty simple in fact.

But it would be better if we could avoid the intersection between mesh.

 

1. The physics should be more reactive. As a general rule, I find that every scene with physics I saw on this forum always seem to be played in slow motion (even with 60 FPS). Is it possible to accelerate the physic time speed ?

 

2. For a better result I should also block the current mesh movement if the other collided mesh is heavier, this could be easily done with mesh.intersectMesh unfortunatly this function does not correctly work in Firefox (works nice in IE and Chrome though http://www.html5gamedevs.com/topic/15651-collision-takes-place-even-when-not-colliding/ ), maybe a truncate stuff in the calculations of FF ?

[Wingnut]

Hi VP! 

 

Um...

 

#1 - Have you ever played Supersonic Sled?  http://www.nvidia.com/coolstuff/demos#!/supersonic-sled

 

PhysX running.. multi-threaded... yum.  Somewhere between Lynx and Supersonic Sled, someone asked "What IS a web browser?  What IS a game client?"... you know... a bunch of "by definition" labeling stuff.  Canvas is like a "cave to hardware" but it has a bunch of sandbox "thou shalt not" draped onto it "by definition".

 

Did anyone understand that whatsoever?  I sure didn't. 

 

#2 - Still missing a response to http://www.html5gamedevs.com/topic/15651-collision-takes-place-even-when-not-colliding/#entry109249 ?  *nod*  I'll try some tests... see if I get the same results.

[Vousk-prod.]

1. Nope, never played with Supersonic Sled. I had a look on youtube vids, that's nice (maybe a little bit outdated however).

 2. Yep, still missing. I tried to figure out the problem but with no luck. Do you get same results on FF ?

[Wingnut]

Hi vp.  You should DL Supersled and run it if you can.  The bridge explosion in high tessellation is just amazing.  And there's a chicken gun... shoots physics-mass chickens at things... including the sled and bridge pieces.  The physics are nothing short of amazing, and so are the laughs.  But even there, when the poly's are high, it's slow-motion speed.  It just seems to take SO MANY calculations to do good physics, and I guess that's understandable.  I'm right with you on this, though.  The faster the better.

 

#2.  I didn't get time (or have enough energy) to test things well.  I ran it, but I don't quite understand what I am seeing, yet.  The mouse drag quits working in both browsers after an intersect or two.  I'm not sure why that happens.  And, the amount of output to my console is difficult to read.

 

I wish we had an easier test-scene.  And it doesn't help that I have been seriously coding-lazy, lately.

position ok : 1.9665289155453785, -74.3295659583294position ok : 1.8100786193533445, -76.94343798575841position ok : 1.652248939021451, -79.58035588593947collision position : 2.4816477010369837, -82.29005710142906 -> revert to position : 1.652248939021451, -79.58035588593947collision position : 1.652248939021451, -79.58035588593947  <<==== -> revert to position : 1.652248939021451, -79.58035588593947position ok : 1.652248939021451, -79.58035588593947

http://www.babylonjs-playground.com/#11JY4O#1 - sliding the red sphere into the front of the green box, with FF 41.0.2... this is some output I get.  The line with the arrow is the weird one.  Right after the revert to "clear of intersection" (coi?), the next collision is the same location as the coi position.  How can that be?  *scratch scratch* 

 

Now to IE 11.0.9600 or something like that... IE won't let me copy'n'paste the version number, nor can I copy'n'paste select multiple lines of console output.  Nice work, MS... sheesh.  SO, I will show you ITS console output by pasting to forum... line by line.  (yikes - what a P.O.S. browser!)  Copy ALL is on the right click... oh boy.  In IE...

position ok : 1.0130338733668615, -80.06446797980652collision position : 0.8948195175615972, -82.44962365993439-> revert to position : 1.0130338733668615, -80.06446797980652collision position : 1.0130338733668615, -80.06446797980652  <<====-> revert to position : 1.0130338733668615, -80.06446797980652collision position : 1.0130338733668615, -80.06446797980652-> revert to position : 1.0130338733668615, -80.06446797980652

Same as FF at the arrow.  An intersect has happened at a coi safe position.  I have not yet checked your playground to see if you are making a mistake in your console reporting or position reverting.  On this computer, the scene is acting exactly the same in both browsers... which COULD indicate that there is a mistake in your code.  The console is showing similar activity, too. 

 

Also, notice that the X position seems to change drastically upon collision.  In FF...

position ok : 1.652248939021451, -79.58035588593947collision position : 2.4816477010369837, -82.29005710142906

1.65 before intersect, 2.48 when intersecting.  In IE...

position ok : 1.0130338733668615, -80.06446797980652collision position : 0.8948195175615972, -82.44962365993439

1.01 pre-intersect, 0.89 at intersect.  hmm.  Not sure if that is pertinent.

 

I might not be able to get back to this until January, but if you could make a really SIMPLE playground, that might help.  And maybe you or others can see something in these console outputs... that could help.  (I'm not much help, am I?  Sorry)  Be well.

[Vousk-prod.]

Yep, I got the exact same results : a collision has happened at a previously "coi" safe position. I don't understand why.

I know that while I'm re-positionning the mesh to previous "coi" position, the mouse is still hovering a "collision position", so the calculation of the new current position leads to collision, but when we then move the mouse elsewhere, next new positions should be ok...

 

I can't make simpler PG, it's already ultra simple. It's the drag'ndrop default demo with just an intersectMesh detection added. I don't know how to simplify more, even the console info is pretty straightforward, isn't it ? (you manage to see the incoherent behavior the same way as me)

 

But now there is new strange facts...   as if my comptuer is haunted by the forum messages...

When I wrote that test scene, the bug occured for me (in FF, but I didn't test in other browser at that time). Then DK wrote that it totally works for him, so I checked in IE and Chrome, and that was ok ! But now you tell me it doesn't work for you in IE, so I checked again, and now it doesn't work anymore for me in IE, nor Chrome. Is my computer influenced by what is written in this forum ??!

[Vousk-prod.]

On this computer, the scene is acting exactly the same in both browsers... which COULD indicate that there is a mistake in your code.

 

Or in mesh.intersectMeshes    (maybe due to mesh matrix late updates or I don't know what)

[Wingnut]

Well, what I mean by simplify... is remove the mouse drags and use keypresses.  You are reverting (relocating) the mesh... against a mouse drag.  You are forcing the mesh to "back off" while the mouse drag is still running on the IRQ (Interrupt request, remember those?)  hehe.  So, you force the mesh away from the intersection, and then the drag tries to put it right back to where it was before the revert.

If you keypress-tap the mesh into intersection (not keypress held down, that will defeat the revert again)... then we might know more.  Maybe.  :/

Or, maybe use a slow render-loop move... to get to the intersect, and then remove the animated mover as soon as there is an intersect (so it doesn't try to go back into intersect).  Then do your revert, and see if you still have intersect.  I feel the dragging is causing problems here... maybe.  heh.  I think we need to get engineering-grade precision, here.  Dragging has very little precision, imho. 

Get the camera in real close, show bounding boxes, only 2 mesh, change colors on mesh when we are intersected/not... show the values on-canvas and not in the console, etc. ( text-spewing playground - http://playground.babylonjs.com/#5R8A1 ) or maybe use dynamicTexture to put your readouts on a small plane parented to the camera.

Let's get some precision, here.    Intersection workshop 1.0, ya know? 

[Vousk-prod.]

The idea here is to add a collision check to the dragging system. That's why I stick to drag method to move the object.

 

In fact, this is already a very simplified test PG . In my real stress test scene, I have many objects, many colliders, and I record the 20th latest good know "coi" position for each object. Even when applying the oldest one (which throw back the moving object very far from the collider mesh, it's the same scenario, some movement later, it also stuck in position (even far from the collider), claiming intersecting, but when can see by eyes that's not the case).

So I created this simple PG with some console log to demonstrate.

 

How do you do a "slow render loop move" ? Would be usefull to understand the problem (but the final purpose still is to have collision with a drag at real speed).

 

Ok, simplified PG :

http://www.babylonjs-playground.com/#11JY4O#2

Kept only two cubes, stronger zoom in, changed color when mesh intersect. Showing bounding boxes for cubes is useless (they are identical to the cube themselves).

Still logged info in console, because we need history to sudy what happened when, and in which context. Showing log in the canvas is accessible more directly (no need to press F12) but I think it's not good (it takes more ressources and time than direct console, so you're biasing your realtime checking, it's much longer to code - debug is a process where you need to optimise time spent, better to take time to produce smart code than to produce beautiful debug info -)and  knowing the fact that any coder needs to open it's console all day long it's not a big deal to provide some console.log I think (but maybe I'm wrong and nowadays console is a "has been" process).

 

I know that the mouse position tends to put back the object to the collided position, and this could be the thing to fix, but for the moment nothing jump to my eyes as an evidence, since even if mouse tends to force mesh in collided position, we always keep only good position and immediatly move the objet to the correct one when bad is detected, so we should never have the object stuck in collided position.

We still have some possibilities :

- my logic of remembering good position is bad coded, or inapplicable for some reason

- the onpointermove plays a tricky game with us (multiple simultaneous calls ?)

- intersectMeshes has a bug

- mesh positioning or world matrix or I-don't-know-what is not updated as quickly as the onpointermoves are called, leading to kind of wrong intersectMeshes calculations

[Wingnut]

Hi again!  Yeah, that's a slightly better playground. 

 

 

I know that the mouse position tends to put back the object to the collided position, and this could be the thing to fix, but for the moment nothing jump to my eyes as an evidence, since even if mouse tends to force mesh in collided position, we always keep only good position and immediately move the object to the correct one when bad is detected, so we should never have the object stuck in collided position.

 

But but but VP... what about the mouse pointer?  Did you move that away from the intersection as well?  No.  So the variable named current which SHOULD be renamed currentPointerPos... went stale, after your revert.  (it went out-of-offset-sync with the mesh revert position) You backed-off the mesh but you didn't back-off the drag pointer position the same amount. *

 

Take a look at this one...

http://www.babylonjs-playground.com/#11JY4O#5

 

Very slowly drag blue against green (to do the intersect).  You can actually see the mesh revert to the "last good position" (you can see a little gap between the meshes).  Your "last good position" is still a bad position... if you drag too fast (due to deep-buried intersect).  We can study the deep-buried intersect (dbi) problem later. 

 

I temporarily disabled the snap-to-origin in pointerUp func. 

 

Look at line 106.  As soon as an intersect occurs, I shut-off the pointerMove listener, so it can't bounce. 

 

Why does it bounce?  Because the mouse pointer position didn't revert when the mesh reverts.  Keep in mind that mouse drag is not one single move.  It is a sequence of many many little moves... updated very fast.

 

I'm not sure how to fix this.  As you can see in line 87, there I re-activate the pointerMove listener in the pointerUp func... sort of a kludgy way to do it.  The user needs to re-click on the blue box to do more dragging.  In essence, that line is resetting current (and startingPoint) to a fresh pointerDown position.

 

* One might think that an easy fix is to set current == revert position, but that won't work.  It is unlikely that the user did a pointerDown at the exact center of the blue box.  Pointer position will never (or very very rarely) match blue box position.  Current is likely a position on the ground plane... a position that is located behind the blue box.

 

To be brief, you cannot allow the pointer to continue dragging TOWARD intersect... after an intersect has happened.  You have to shut-off the drag, or somehow reset its current drag position... to be the same position AS IF the user dragged the mesh to the revert position.  I suspect you would need to subtract revert position from intersect position, and then subtract THAT difference... from current.  Careful here.  PickedPoint [returned from getGroundPosition()] is essentially a vector2 on the XZ ground plane... so be careful what kind of subtracting you use (when building a reverted current should you decide to calculate such a thing).  I bet you knew that already. 

 

Maybe you could record lastGoodMeshPosition AND lastGoodCurrentPointerPosition, right?  Revert BOTH of them.  *shrug*

 

I hope you understand this, and I hope I'm correct, because it sure is difficult to explain.    It looks to me like intersect is working properly, but I certainly could be wrong... about ALL of this.  But maybe not.  This is a fun and useful project/experiment, no matter what.  Thanks for making the fresh PG, and for putting up with my theories, VP.  Even if I'm completely wrong and lost in the ozone, I'm learning tons. 

 

PS: I believe that the "stuck" is caused by a dbi that happens, which fools your lastGoodPosition recorder, so when you revert from this pointer-caused deep-intersect (dbi)... it reverts only PART WAY out-of the intersect condition.  In other words, the deep intersect was actually TWO intersects deep into mesh (BBox) overlap, so a single revert... only backed-out ONE step, thus causing "stuck".  Wow, eh?  I'm scared!  heh

[yuccai]

Hi,

You need to compute the world matrix of the mesh before checking collisions. In this way you're sure that the good registered positions are correct.

Here is the PG : http://www.babylonjs-playground.com/#11JY4O#10