moveWithCollisions

[Lary]

Hi fellow friends, it maybe silly to ask this question, but I'm rather rookie Hope anyone can enlight me a bit~

I'm using moveWithCollisions  to control the position of a mesh,  it can move along X, Y , Z axis. 

Can I dispose Y axis, and only move along X and Z axis?

I've applied gravity and checkcollisions on meshes, it works, but not that desiable. 

Is there another way to achieve?  Thanks!

[Arte]

Hi @Lary

This is example from playground and drag and drop example with collision

Is this what you're looking for?

[Wingnut]

On 11/10/2017 at 3:16 AM, Lary said:

Can I dispose Y axis, and only move along X and Z axis?

Generally speaking, just keep the Y component of the move-amount == 0. 

So, mesh.moveWithCollisions(new BABYLON.Vector3(value, 0, value)).  This will ensure that no Y movement happens.

You picked one hell-of-a playground demo, @Arte

https://www.babylonjs-playground.com/#M63D11#2

In THIS version, I am printing vars current and diff to console (from inside the pointer-move func) (console.log @ line 99)

At the console, current is seen to have a varying Y value... sometimes 0, sometimes -2.8/2.8, sometimes -5.6/5.6. 

Current is established in a little helper func at line 50 - called getGroundPosition().  It, and onPointerMove... happen very fast and continuous... during a drag.  Current == pickinfo.pickedPoint.   I think there is near-continuous scene.pick happening during a drag. 

Since diff is derived from current, ITS Y-value varies, as well.

Ground, greenBox, and blueBox are all set .checkCollisions = false;

HOW is the blue box kept at ground height?  Why is picked-point.y... moving up/down in a +5.6 to -5.6 range?  Strange, eh? 

Soooo... in this case... you could add... diff.y = 0;  ...just before moveWithCollisions(diff); 

FORCE that Y value to stay at 0... using "the big wrench" 

[Arte]

@Wingnut you are absolutely right about moveWithCollisions .

This function you can use just for basic stuff. That why in my project "Parametric cabinets" I'm ended up with my own collision and snapping (no more "sometimes 0, sometimes -2.8/2.8, sometimes -5.6/5.6") .

Just guess who helped me. 

Regards

Arte

[Lary]

Quote

On 2017/11/11 at 8:46 AM, Wingnut said:

Soooo... in this case... you could add... diff.y = 0;  ...just before moveWithCollisions(diff); 

Great! That's exactly what I want. Many thanks @Wingnut

So the problem is I still have long way to go to learn babylonjs, and maybe a quick review of all functions.

 

[Lary]

Quote

This is example from playground and drag and drop example with collision  

 @Arte , I found the same link as you sent above. thanks all the same!

 

[Arte]

8 hours ago, Lary said:

 

I don't know how i manage to mess everything 

Example from playground

With collision

 

[Wingnut]

Actually, Arte, ya did great work in this thread.  One thing I didn't know... is that the 2.8/5.6 issue exists AT ALL.  I REALLY REALLY want to determine why that is happening.  Perhaps we will do more experimenting and figure it out.

Perhaps Lary will let us talk about it in his thread. 

That diff.y = 0 is a kludge.... a cheap and dirty work-around to an issue that needs solving instead-of work-around.  Or, at minimum, I think ALL OF US would like to know WHY it happens.

This issue also affected your procedural cabinet-making, so it was YOU who first discovered the prob.  Well done!  Thanks to Lary, too.

All things done so far, are rated A++.  We're on-the-trail of an outlaw, and I think we can capture him before he crosses the border.    You have nothing to be sad/discouraged about AT ALL. 

All is good good good.  Lary is rolling with the work-around, and now we can all do some experiments/testing.  Party on!

[Arte]

Ok, lets start.

Scene.pick using ground.position.y, correct me if I'm wrong.

That mean if we using moveWithCollision position.y should always be the same??? But it is not! 

Another thing is collision between two meshes. When first mesh collided with second mesh, first mesh bounces back (+/- 0/2.8/5.6) ?! 

Collision calculated from mouse position/movement.

When first object moves towards second object, after collision mouse moves more (near second object) leaving first mesh where collision point. BANG!!!!

But instead of staying, first mesh bounces back??? 

Is this make sense what i'm trying to explain?

[Wingnut]

At this time, I would state issue as... "Continuous picks that happen during dragging... have inconsistent Y values (+/- 0/2.8/5.6).  I also saw a RARE diff.y = +/- 8.5 during morning tests, too.  8.5 ~= 2.8 + 2.8 + 2.8.  Interesting!  

It is MY theory that IF cam were directly overhead, no pickinfo.pickedPoint.y variance would be seen at getGroundPosition().  After testing this, I find I was wrong, BUT... when camera is directly overhead, current.y is some zeroes and some -/+ 5.6.  No more 2.8's.

hmmm.

Is the amount 2.8... indicative of the amount of camera-to-ground distance-change... that happens when mouse drag is pulled or pushed?  Only SO MANY picks can happen per-second during a drag.  So, while dragging forward/backward, picks are changing cam-to-ground distance in increments of 2.8, perhaps? 

Change camera angle slightly, and we might see 2.2 or 3.1 values?  Untested, yet.   

I think I'm wrong, due to 5.6's seen during overhead-cam drag tests while watching console.

[Wingnut]

Oh man, collision recoil distance.  heh.  Now we have another fun clue to the puzzle.    Way to go, Arte!

[Arte]

I like puzzles if its coloured

[Wingnut]

ohhhhhh.  Have you SEEN "collision rebounds" (CR for short?) distance being 2.8/5.6?   If so... wow, I just thought about something.

During drags... dragged mesh is colliding with ground.  AND... it might be doing "CR"... ground <-> mesh.  (You probably already deduced this, eh?  I'm slow.)

Wow!  What if?

I set line 7  scene.collisionsEnabled = false;   No joy.  [#5]  (nicer console reports in #5)  (It is a 5.6 festival)   

In the #5 PG, I released the camera to be tilt-changed.  Notice the console numbers changing when dragging, while using various camera tilt-angles (pitch). 

This outlaw left-behind lots of clues/evidence.  Something stinks, nearby.  Can ya smell it?  We're close. 

Great noses can always follow a trail back-to the source of a fart.  (peeewww)

[Wingnut]

There is a "barrels" demo that was used for another forum thread.

https://www.babylonjs-playground.com/#WWCK0#53

It uses shifted and unshifted... w,a,s,d,q,e keys... to moveWithCollisions the barrels.

Also, barrel2 has an actionManager intersect-checker, just for fun.

I do not see any collision rebound (CR) when colliding the barrels.... using keypresses.

Perhaps we should add mouse-dragging... to the barrels demo.

More coffee for me, first.    Perhaps a Bugs Bunny cartoon, too.  A guy has needs.  heh

[Arte]

Here we go, barrels demo with mouse-dragging.

https://www.babylonjs-playground.com/#WWCK0#54

i'm confused 

 

[Wingnut]

Hey, thx for doing that!

Same symptom at console, pp.y all over the place. 

(What did he ask?  "Y is there PP all over the place?") 

Barrels are 12 units tall, so their positions being at ~6... is normal, I think.

Seeing some CR?  Difficult to determine?  Nod.  Might help to set diff.z = 0 and/or diff.x = 0... so we can do some single-axis dragging.

[Wingnut]

Should we try some vertical dragging?  Perhaps write a sister to getGroundPosition()... called getBackgroundPosition(), and then put a vertical ground behind the scene?   Try dragging some mesh upon the back-ground?  In theory, pickedPoint.z should be inconsistent... just like pp.y is, now.  hmm.

Last I checked, collisions from above or below (on Y axis)... REALLY sucked.  They "acted" like a rather large mesh.ellipsoidOffset.y was set, even though none was.  You can do some Y-axis colliding with the Q/E keys.  My tests show that when barrel1 is lowered (Q key) onto top of barrel2, impact happens when barrel2 is at Y = 24.  It should be Y = 18.  (50%-of-mesh-height too high)

After that, perhaps we add the third ground plane... along one side?  Add getWallPosition() and check for inconsistent pickedPoint.x?

GetGroundPosition(whichGround)... makes it a re-usable func for all three drag-dimensions (all three grounds/planes).

Investigation fun.  Likely, we can determine the anomaly with the point-picker... WITHOUT needing to create a 3-Dimension Drag'n'Drop Demo.  But we don't want to finish this adventure TOO quickly.  It's too much fun and learning-filled... to end quickly. 

https://www.babylonjs-playground.com/#WWCK0#60

For SOME reason, you need to click RUN... AGAIN... after PG loads-in.  Watch how the barrel shapes change... after that re-run.  Weird!

Drag some barrels, everyone.  All 6 should be draggable.  Recently, I set the wireframe-sphere .ellipsoidMesh tokens...   .isPickable = false. 

But, it STILL seems like the wireframe spheres are allowing picking, sometimes.  When it happens, the sphere sort-of jiggles-around inside the barrel, but generally-speaking, the drag fails.  Play around... you might see a sphere attempt to allow being dragged... instead of its cylinder "host".    The cylinders (barrels) should drag.  The spheres simply "go along for the ride".

On the walls... collisions from above happen 50% too high.  Collisions from below happen 50% too high, too.  I think that is a bug in collider processing... something to do with boundingBox measuring, I suspect.  I'll find it, someday, maybe.  Perhaps superhero @RaananW (or anyone else) will have some advice about where I should examine code.  He has done some serious work with colliders, esp involving webworker forking.

Look how solid (good) those picked point numbers in the last read-out line... look (when dragging anything).  Symptom has disappeared!   What the hell?  Our outlaw is more elusive than we first thought, eh? 

[Arte]

On last PB I'm getting error Line 92:28 - myout.cloneNode is not a function,  Should be myout1.cloneNode 

https://www.babylonjs-playground.com/#WWCK0#61

[Wingnut]

Hey, thx for fix, @Arte.  Good catch!

I need to figure-out that "re-RUN" thing, eventually.  hmm.  I use FF.  I wonder if others see it.

Before the re-RUN, you CAN drag wall mesh if you start the drag about 4-5 grid-cells beneath the actual target.  For floor barrels, start drag 4-5 cells behind (-z, closer to cam) than actual drag-target.  Strange.

Before re-RUN, (if anyone else sees the issue), notice that floor barrels... perhaps all barrels, are shorter/fatter than normal.  Some kind of engine render-perspective re- size/re-calc is not happening, upon load-finish.  (Wingnut pulls-out his Official Sherlock Holmes Magnifying Glass and looks-around, aimlessly) 

Ok, so, does anyone have any theories as to WHY we had "bumpy Y" values in the basic drag demo, and in this ridiculous 3D drag demo, it is now smooth?

I still see some +0/-0 bouncing, but no 2.8, 5.6 crap.

What did we do differently?  *scratch scratch* 

[Wingnut]

Ahh, its still bumpy.

https://www.babylonjs-playground.com/#WWCK0#64

Watch console... I am reporting the pickedPoint from the first onPointerDOWN.  I THINK I got it figged!  Keeping doing pointer-downs, without drags, while watching console numbers.  Switch back and forth between barrel1 and barrel2 (the barrels on the floor)... only doing pointerDowns on them, and watching console.  Something can be discovered. 

StartingPoint is rotten. It has a "pick epsilon".  (huh?)  It needs its Y value to be nulled-out (for floor-drags).  But why does pickedPoint SOMETIMES have a positive, negative, or 0  y-axis value?

If you click on the FRONT edge of the mesh to start floor-dragging, you get a little negative Y.  If you click on the BACK edge of mesh to start the floor-drag, you get some +Y.  The Y value is dependent-upon WHERE (upon the mesh) that you click to start the dragging, and it continues through the entire drag-sequence.  COOOOOOL!

Highlight the text of this post... to view the above hidden line, and to learn what I have learned. 

[Arte]

You have done the homework. Well done! PARTY!!! 

Should We (sorry @Wingnut) dig deeper, or ask for help from sky? 

[Wingnut]

Yeah, PARTY!!!  You ask a good question.  I think it MIGHT BE a framework-level issue... which generally means... I jump ship and allow core-coders to determine if a modification is needed.  We can force that pickedPoint Y-value to zero... inside getGroundPosition().  That would be a "work-around fix" for the issue.

But perhaps... we should ask those who see "the big picture" better than we do. 

I cannot foresee/predict ANY need for a pickedPoint on a mesh... to have a "depth" value other than 0. 

But, I dunno, I get scared easily.  I fear breaking the framework and causing hell for others.

How about you, Arte?  Lary?  Shall we go core-hacking?  Want to go "graze in the rays"?    (picking rays)

[Wingnut]

One of my favorite ways to hack core, is to "hijack" the issue-code... from framework, into PG scope.  (an over-ride of the framework version, via OUR PG version).

We know the function is called intersects() and it is on AbstractMesh Class.  I determined that is was located on AbstractMeshClass... by searching our Github site for 'pickedPoint'.

In the BJS github repository, there is a folder called dist.  Inside there... there is a babylon.max.js file that is pure, maximized JS, with no TypeScript. 

So, let's go there and find our AbstractMesh.intersects() func.

AbstractMesh.prototype.intersects() is seen about 25% down the page.  Let's highlight the whole damned thing... and paste it into playground...

https://www.babylonjs-playground.com/#WWCK0#66

There it is... at the top, in lines 3 - 62.  I put a little console.log in line 4, just to make sure that we are using OUR HIJACKED intersect() function, and NOT the framework's default version.

It is reporting to console fine.  NOW, we can insert console.log reports inside the PG intersects() function, and watch what is happening in there.  Demented core-hacking... ready to go.  Scared?  I am. 

[Arte]

@Wingnut thank you for teaching us (beginners). 

[Wingnut]

My pleasure!  But I don't think you are a beginner.  I think you are nearing BJS PRO. 

You have done many advanced things, so far.  I predict you will do many more, too.

Your procedural cabinet project is VERY cool.  I have always dreamed-of a similar project... to produce funny-looking spacecraft and aircraft, using all BJS basic shapes.  I think it will "facilitate" the invention of a new mesh "behavior", too (behaviors are a new BJS feature - do forum search). 

I think it will involve "mirroring" or "symmetry"... similar to mesh arrays in 3dsMax.  Place ONE mesh of FOUR... in a certain position on the spacecraft, and the 3 other mesh (clones)... position themselves "appropriately"... in 3 other "symmetrical positions" on the spacecraft. 

I'm not sure what that is called, but it would make procedural aircraft... easier to create, I suspect.  Maybe.    And YOU are a "snap" pro!  How handy for ME/US!  Snapping is just manual-assisted procedural-ism.    Or would snapping be... procedure-assisted manual-ism?  All-in-all (and half'n'half), that's a topic for another hour and thread.