Questions about MoveWithCollisions

[TomaszFurca]

Hi, I try to use mesh collisions. Every mesh in scene have properties:

checkCollisions  = true

For moving character before i used translate and rotate functions. Now i can't use translate because body do not collide with any object. So After read some articles i made this controller for moving my char like it

public handleKeyUp(evt):void {
        let character = this.game.player.character;
        var speed = 0.2;
        var man = character.mesh;
        if (evt.keyCode == 65) {
            character.mesh.rotation.y = character.mesh.rotation.y-0.1;

            character.runAnimationWalk(true);
            this.left = true;
        }
        if (evt.keyCode == 68) {
            character.mesh.rotation.y = character.mesh.rotation.y+0.1;
            character.runAnimationWalk(true);
            this.right = true;
        }
        if (evt.keyCode == 87) {
            var vectorMove = new BABYLON.Vector3(parseFloat(Math.sin(man.rotation.y)) * speed, 0, parseFloat(Math.cos(man.rotation.y)) * speed);
            man.moveWithCollisions(vectorMove.negate());

            character.runAnimationWalk(true);
            this.forward = true;
        }
        if (evt.keyCode == 83) {

            var vectorMove = new BABYLON.Vector3(parseFloat(Math.sin(man.rotation.y)) * speed, 0, parseFloat(Math.cos(man.rotation.y)) * speed);
            man.moveWithCollisions(vectorMove);

            character.runAnimationWalk(true);
            this.back = true;
        }

        if (evt.keyCode == 32 && !this.animation) {
            character.runAnimationHit();
        }

    }

And now if Vector Y Axis is 0 mesh do not collide with any other mesh you can see it on my SS:

https://ibb.co/jaPH35
https://ibb.co/btDoAk

When i give value > 0, then player collide with objects, but not with all size of object and sometime character fly up and down and "stay in air".

What i must to do, to collide with boundingBox of object? 
It can be problem with ellipsoid?
Can i register function of collision instead intersectsMesh in renderLoop?

Tom

[Wingnut]

Hiya Tom.

http://www.babylonjs-playground.com/#WWCK0#4

Just doing a little testing.  Click canvas, then WASD.  There's definitely some problems with the ellipsoids or something.

Redbox Y position is already high (line 14).  Ellipsoid is small (line 19).

Click on canvas and then hold "d" key.  See redbox climb-over greenbox?  Goofy!  Ellipsoids are tall for some reason.  hmm.

Objects staying in air is normal.  Only cameras have .applyGravity, not mesh.  But you can create fake gravity for boxes... in render loop.

But first, we must fix these ellipsoid heights.  Perhaps I am making a mistake in this testing demo.  I am old geezer and forget things. 

For all future tests, let's keep ground.checkCollisions = true (so we can check ground-redbox collisions, too).  If we set redbox.y to 1.5 in line 14, WASD moving... struggles/climbs a bit.  If set to 1.0, WASD starts failing... ground-to-redbox collision problems.

Perhaps intersectsMesh (using boundingBox instead of ellipsoids) would be better.  Not sure.

Tom, there IS an "observable" called  abstractMesh.onCollideObservable.  (See docs for that.)  Two playgrounds use it, it seems.  Might be a good direction to experiment-with.  I made another demo... with redbox.onCollideObservable added in line 65 area.  It returns greenbox object when colliding with greenbox.  It SHOULD also return ground object when redbox collides with ground.  So, it might be handy for testing or other things (like fake gravity).

I wonder if onCollideObservable uses boundingBoxes or ellipsoids.  hmm.  I have SO MUCH to learn. 

I'll keep testing, maybe turn-on wireframe spheres to show collision ellipsoids, eh?   

Help welcome from all forum users, as usual.  Thx gang.

[TomaszFurca]

Check this http://babylon.furcatomasz.pl/wp/

Created this today to eleminate physics from my game. I want to use only collisions. WSAD is controllers of player, i give some value to moving down player after run, but player don't go to ground, he block in air. 

Next problem is blocking player by tree, run player to tress and you can't go back - object is blocked.

[Wingnut]

Hi Tom. 

If I understand correctly, intersectsMesh() uses boundingBoxes (either loose AABB or precise OBB).  Unfortunately, I think .showBoundingBox = true... ONLY shows loose (AABB).  There is no .showBoundingBox for OBB/precise, I believe.

None of that is important... except for fake gravity in renderLoop.  For fake gravity (an intersectsMesh/ground, so far)... there is a problem. 

Fake gravity-adjusting (forcing Y positions) likely affects ellipsoid position used for .checkCollisions and .moveWithCollisions().

Really, there's two things we might need to "force".  Return player to ground-level... after player climb-over something, and after player burrow-under something. 

AND both actions could/should be disallowed.  Many games DISALLOW burrow-under, and require spacebar-tap to climb-over.

Let's deal ONLY with ellipsoids at this time (no talk of intersectsMesh, yet). 

Unfortunately, we are dealing-with collision ellipsoids bumping into collision ellipsoids.  Burrow-under, climb-over, and move-around... is natural (round things against round things).  If burrow and climb is not wanted, we must somehow restrict it, OR... the center of the two colliding ellipsoids must be positioned at EXACTLY the same worldspace Y-height.  If they are, I believe the collider will be forced to use a move-around, which is better for us, right?

But... ellipsoids often extend to ground or below.  SO... no ground.checkCollisions = true; (yet)   When the player's feet are on the ground, player.ellipsoid COULD BE below the ground... no good.  But we might discover that we can prevent the ellipsoids from touching the ground... with precise sizes and offsets.  We will learn more about this...as you/we run more tests.

I am not very experienced in collisions, unfortunately.  I did some tests... with another user's model.  http://www.babylonjs-playground.com/#WWCK0#7

The yellow sphere represents dude.ellipsoid. 

One thing I noticed.  See dude.scaling 10x in line 33?  Well, dude.ellipsoid does NOT scale WITH IT.  I needed line 37 to make the dude.ellipsoid big, like dude mesh.

This would mean... that you need to change all mesh.ellipsoid and perhaps "center-ize" all ellipsoids with mesh.ellipsoidOffset... in your scene.  Again, try to keep your ellipsoids from dragging against ground, or set ground.checkCollisions = false.

 

Anyway, I wanted to build a test scene (url above), but I'm only halfway done.  I have one tree trunk made... with no collisions active.  I want to code a... BABYLON.Mesh.showEllipsoid = function() {something good}.  I think this is called "overloading" the Mesh class.  Doing this (very early in code, or even global level) would put a .showEllipsoid() on EVERY mesh in your scene.  Cool, huh?  We could use that helper.

There MIGHT be a way to automatically set mesh.ellipsoid EXACTLY FIT into mesh.showBoundingBox.  Possibly, it would be another "overload" of the BABYLON.Mesh class... like BABYLON.Mesh.setEllipsoidPerBoundingBox = function() {something really good}.  Now, every mesh in your scene would have .setEllipsoidPerBoundingBox()... another very handy function, perhaps.  I/you/we just need to code these funcs. 

And, I want to make some more trees, and some barrels, and a wall... in this PG scene.  Then we can "see" all those ellipsoids (with yellow wireframe spheres). We can set ellipsoid heights and widths, if needed, or use our new automatic ellipsoid size-setter function. 

Then, more tests, trying to keep collided mesh from climbing-over and/or burrowing-under each other.  Remove ground.checkCollisions, and instead... use our fake gravity and check intersectsMesh in the renderLoop, like you did in your scene (and reported console.log(1) if intersects).  But we have to be careful while preventing/adjusting the burrow-under or climb-over condition, because if we use the renderLoop to force the player down (fake gravity) or force player UP (avoid burrowing under walls/barrels/trees, etc)... we could be causing or "jamming" an ellipsoid collision.  Jamming =  "stuck", same as we see in your scene.

I need more time, Tom.  If you (or others) want to help with my test scene and/or code-up .showEllipsoid() or .setEllipsoidPerBoundingBox()... that would be great.  I must test slow, and in playgrounds, because it is just TOO DIFFICULT to find things in your big project code.  I must keep things simple... just so I can learn.  I am not a very good coder, and I learn rather slowly.  Sorry. 

Hopefully, you and/or others will help advance my ellipsoid collisions tests.  Feel free to edit that playground, run, save more, grab zips, make trees and barrels, help/play at will.  I'll visit again soon.

[Wingnut]

No fellow testers/helpers/experts, huh?  Darn.  Oh well, my weekend gigs are done, now, so I'll get back to work after some rice krispees and some sleep.   

Maybe I should dress-up the thread like a Jacob's Ladder, so we can get some participation, eh?  Phew.

Cya tomorrow.

[Wingnut]

Alllllllllrightythen.  Trudging-on...  http://www.babylonjs-playground.com/#WWCK0#13

New .showEllipsoid() func... somewhat operational in lines 2-22.

New .setEllipsoidPerBoundingBox() func... barely/badly operational in lines 24-42.

I'm not testing any movements or collisions, yet.  Still trying to get nice ellipsoid sizing and alignment without hard-coded (manually-set) values.  I want to derive/calculate ellipsoid sizes/positions, automatically.  Then we can kick some butt... learning about .moveWithCollisions(), eh?  (such-as WHEN does it dive-under, when does it climb-over, when does it go-around, and when does it stop dead.)  We might even learn WHEN does it get stuck, eh? 

Lines 39 and 40... bad code.  Still, it made dude's ellipsoid (or ONLY it's yellow sphere) be same height as dude boundingBox, and ALMOST same width, but not near same thickness.  Ellipsoid is too flat.  Also, yellow spheres on wall, barrel, and tree trunk... bad height, so far.  Better code needed.

Warning: Maybe only my yellow sphere is too flat or too short.  Still testing/learning.  Don't trust yellow sphere to match mesh.ellipsoid size or position, yet.  Sync not yet proven/tested.  I'm still working on that, and can use advice/thoughts/code.

.showEllipsoid() and .setEllipsoidPerBoundingBox() are not working on merged mesh, so far.  Might never work on them... not sure.  Also not sure about clones and instances, yet.

More tests/reports soon.  Anyone... feel free to advance/experiment... all knowledge/info warmly welcomed.  (thx)

[Wingnut]

Latest Update:  [#17] - Not much progress on setEllipsoidPerBoundingBox().  All it does is make all ellipsoids be sized 10, 10, 10 in line 48.  But showEllipsoid() has sphere.position PERFECT.  None of the mesh have .ellipsoidOffset setting.  The only mesh that needs one is dude (name = Man).  He was scaled-up 10x in line 87, and his cyan sphere has not yet been re-centered for that.

Red spheres are the conestacks (tree limbs)... and inside the reds, there are slightly-down-scaled white spheres (the tree trunks). 

I will continue efforts on setEllipsoidPerBoundingBox() func.  Lots of playing-with boundingBox properties/measurements... needed inside THAT func.  I am not very good at that.  All help welcome. 

It won't be long until we can SERIOUSLY torture moveWithCollisions().  I'm looking forward to it.

Merged meshes and clones both seem fine, but instances aren't working, because instance.showEllipsoid() and instance.setEllipsoidPerBoundingBox()... NOT FOUND on the instances.  Instances seem to be "dumb mesh" to a degree.    We could force those funcs onto the instances, if need-be.

I can probably include the trunks in the conestack merges, but, for now, let's KEEP the trunks having separate ellipsoids from the cones/limbs. 

More soon.  (I'm SO SLOW, huh?  sorry.)   Reminder:  We have no .setTarget() or .lockedTarget on our arcCam, so control-dragging should allow moving its target (for easy viewing of stuff).

[TomaszFurca]

Hi, thanks for help. I use your function in my test project. I must put some changes, because I have many classes in JS i must put scene as argument and set sphere parent as "this" (mesh).

        BABYLON.Mesh.prototype.showEllipsoid = function(scene) {

            // this.refreshBoundingInfo();
            var sphere = BABYLON.MeshBuilder.CreateSphere("elli", {
                    diameterX: this.ellipsoid.x,
                    diameterZ: this.ellipsoid.z,
                    diameterY: this.ellipsoid.y
                },
                scene);

//            sphere.position = this.position.clone();

            this.ellipsoidMesh = sphere;
            sphere.showBoundingBox = true;
            sphere.material = new BABYLON.StandardMaterial("collider", scene);
            sphere.material.wireframe = true;
            sphere.material.diffuseColor = BABYLON.Color3.Yellow();
            sphere.visibility = .1;
            sphere.parent = this;
            // sphere.position = this.position.add(this.ellipsoidOffset);

        }

Without setting parent ellipsoid do not move with object. 

Check this: 

http://babylon.furcatomasz.pl/wp/ - this is test project with enabled showEllipsoid. Why half ellipsoid is below ground? Maybe this is problem with models? Wrong center?

http://babylon.furcatomasz.pl/ - this is old scene, where i show you physics problem, now physics is disabled. I used  function setEllipsoidPerBoundingBox() to prepare ellipsoids.

In two preview i can see lower perfomance than using physics CannonJS. Maybe this renderLoop on every character in map decrease perfomance:

game.scene.registerBeforeRender(function () {
            if (!mesh.intersectsMesh(game.gameScene.ground, true)) {
                mesh.position.y -= 0.1;
            }
        });

 

[Wingnut]

Hi Tom, thanks for doing tests.  Good ideas (using parenting and scene).  Parenting CAN be an issue IF the sphere changes position when parented to player (non-moving player).

Is sphere/ellipsoid at player's feet, no matter parented or un-parented?  Should be so (before moving player). 

I think this happens because player origin or player pivotPoint is set at player's feet (possibly settings in modeling software).

See [#20]... line 115.  I put tmp rotation around x.  We can see that "Dude" has his pivot point LOW.  Origin is LOW, too, because when I scaled 10x in line 95, he got ONLY taller, but his legs did not extend thru floor.  He ONLY scaled upward.  YOUR player might do the exact same thing... when adding simple rotation animation like my line 115.  Your player will likely x-rotate around pivot point at his feet. 

We PROBABLY want him spinning around his belt-line/waist... but maybe not. 

Look at line 92.  That is a setPivotMatrix command that you can play-with.  It moves pivot points but not sure about origin.  Not sure if useful, but it is something to test.  This is ONE method to try/test.

---------------------

There is another method you can try.  Do this BEFORE any calls to showEllipsoid(scene) or setEllipsoidPerBoundingBox(scene)...

1.  Position player half-way into floor (so player legs are below floor).
2.  Call player.bakeCurrentTransformIntoVertices();
3.  Return player position to original position.

RUN.  After that, is sphere in center of player?  Maybe.    Pivot point might also move to center, and without need for setPivotMatrix.  Experiment and learn, and then report discoveries, so everyone can learn what we learn.    (thx)

If that sucks, maybe need some changes in modeling.  Not sure.  I think, in Blender, pivot point and origin are not same thing.  You might need to learn about these... in Blender docs.

--------------------

Another method... maybe the BEST method...

Set player.ellipsoidOffset = new BABYLON.Vector3(0, halfHeightOfPlayer, 0);  I haven't learned how to calculate player boundingBox height, yet, sorry.  But you can probably just use your eyes and guess half-height of player.

This should move collision sphere upward.... and WITHOUT needing to bake, or setPivotMatrix, or do modeling changes.  I think this is .ellipsoidOffset purpose.  I am still learning, though.    update:  Tests look good - line 93.

--------------------------------------------------------------------------------------------------

Now let's talk about this...

game.scene.registerBeforeRender(function () {
    if (!mesh.intersectsMesh(game.gameScene.ground, true)) {
        mesh.position.y -= 0.1;
    }
});

Good fake gravity, but it ends too low.  This finishes with player boundingBox intersecting ground.  No good.  Constant collision.... bad performance.  I think you can fix by doing this...

var oldPositionY;
game.scene.registerBeforeRender(function () {
    oldPositionY = player.position.y;
    if (!mesh.intersectsMesh(game.gameScene.ground, true)) {
        mesh.position.y -= 0.1;
    }
    else {
        mesh.position.y = oldPositionY;  // exit intersect condition/state
    }
});

IF there IS intersection, we move player BACK-TO previous position.y.  This sets player OUT-OF intersection, and should improve performance during player moves.  We never want constant intersect or constant collision.

IF you change origin in Blender or use bakeCurrentTransformIntoVertices() method (if that works), you will need to increase player.position.y to get player feet at ground level.  No problems there.  This fake-gravity code should still work fine.  It is best to set player.position so that feet are 0.21 above ground.  This will prevent our "fake gravity engine" from accidentally leaving us in boundingBox intersect state.

Avoid constant intersects with ground.  If ground.checkCollisions = true, avoid constant ellipsoid collision with ground, as well.

Okay, again, thanks for doing tests and reporting info.  Nice work.  Keep going... you are becoming collisions expert.  We will add our information to BJS collision docs, alongside @Dad72's demo (section 4), which is good, but it doesn't answer our big questions.  (WHEN/WHY do moveWithCollisions() ellipsoid colliders...  climb-over, dive-under, go-around-to-left, go-around-to-right, or dead-stop with no go-around at all.)  I want to know that answer.    I think ALL collision-ellipsoid users want to know that answer.  We will soon learn when/why.

Maybe Dad72 already knows answers to that question.  He has done MUCH work with .moveWithCollisions().  I think that function... was HIS IDEA... about 2.5 years ago.  VERY useful func.

We MIGHT be able to add some features to moveWithCollisions()... that prevent various types-of "glance-off", especially climb-over and dive-under.  More soon.

[Wingnut]

Okay, I did some "bakery tests".  Time to make the doughnut holes. 

http://www.babylonjs-playground.com/#WWCK0#22

Geez, what a beast.    But better.  Better butter makes a batter better.  (never mind me, I'm trying comedy, and failing)  heh

Lines 92-96.  Phew.  First the scale-up 10x in line 92... then I bake THAT.  Cooool.  Baking sort of makes the 10x size... become the mesh's "natural size".  After any "bake", the mesh .position, .rotation, and .scaling values... are "nulled" to zero.  "Naturalized" 

SO, I baked-in the scaling big-ness, then I dropped him into the floor halfway, then baked him AGAIN ("naturalized" origin and pivot points to waist-level).  Double bake!  

Then I brought him back to floor level with line 96.  He's looking pretty good.  Line 122 x-rotate test... rotates him at waist-level.  SO... baking worked well, and it makes the house smell great.   

I am still working on .setEllipsoidPerBoundingBox().  I HATE bounding boxes... but... I think I will get better values from boundingBox .maximum and .extendSize and .center... now that I "baked the scaling". 

I was getting really small numbers from bounding box measuring tests... but I think that is because the 10x scaling wasn't baked-in.  The boundingBox wasn't updated after I scaled dude 10x.

No 10x scaling on your player, so no issue for you... about baking-in a .scaling.  But you can use that "sink-into-floor bake"... for your player, I think.  More soon.

[Wingnut]

Alright, as predicted... mesh.getBoundingInfo().boundingBox.maximum (and .extendSize) are reporting better values.

http://www.babylonjs-playground.com/#WWCK0#23

Line 43 this.ellipsoid = bb.maximum.scale(2); ...does a pretty good job at setting our spheres to match boundingBox size. 

this.ellipsoid = bb.extendSize.scale(2); also works.  Not sure which is wise way.

Perhaps STILL keep ground.checkCollisions = false; 

I tried applying dude.ellipsoid.scale(number)... but no success yet.  Likely a Wingnut mental problem. 

To be safe, perhaps adjust .ellipsoid and .ellipsoidOffset (if needed) BEFORE creating clones, and before calling our custom funcs.

This got us VERY close, eh?  YAY!   Easier than adjusting manually.    Player is still Z-thin, though.  Depth-thin.  Not sure why.  More soon.

Possible issue:  Are red spheres SOMETIMES below ground and SOMETIMES above ground?  hmm.  The red conestack spheres seem too tall. Merge-related, I think. Testing.

Latest:  [link]  I did some gruesome stuff in lines 89-95, trying to get a thicker ellipsoid for dude.  Also activated collision.  Active keys - WASD to move laterally, Q/E to move up/down, Z/C to Y-spin for no real reason, and R to reset player. 

Issue:  Hold W to back-up player into wall (or travel behind wall then collide from behind).  Collision happening too soon.  There is still a gap between player and wall... when collision happens.  Problems.  Possibly, invisible dude.ellipsoid is bigger than my dude.ellipsoidMesh sphere.  Not sure, yet.

Lots of dive-unders.    Still learning.  Perhaps time for a break.  Need to examine dude.refreshBoundingInfo();  too.  Not sure what its purpose.

[Wingnut]

Latest... is #28, now.  I'm doing some measuring in lines 23-25, making sure dude's sphere is exactly the same size as dude.getBoundingInfo.boundingBox.maximum.scale(2).  It is.

I also activated line 4... this.refreshBoundingInfo();

SOME forum users might have noticed that I have been "chasing" an elusive "difference" between BJS 2.5 boundingBoxes and 3.0 boundingBoxes.... for over a month, now.

So, just for fun, I fired-up #28... in BJS 2.5 mode.

http://www.babylonjs-playground.com/index2_5.html#WWCK0#28 vs.  http://www.babylonjs-playground.com/index.html#WWCK0#28

Differences!  Positioning differences, not sizing differences.  hmm. 

I'm still looking at stuff done in this commit, but I'm not sure of the purpose of these new "world" methods... introduced in 3.0 (centerWorld, extendSizeWorld, maximumWorld, minimumWorld).

---------------------------- Off-topic stuff -------------------------------

Is BJS going out-of-business?  Seems sort-of ghost-town-ish 'round the forum.    Maybe everyone went GearVR coding.  :x 

A special thanks to @jerome for doing some fairly-recent inside-the-ts documentation.  Way to go, Super-J!  Don't shoot yourself if the BJS ship is going down, J-man.  It's all for the greater good (I hear).    (Wingy chains-open the Gates of Babylonia, affixes padlocks to prevent the doors from closing, and swallows all keys.)

[Wingnut]

Latest:  http://www.babylonjs-playground.com/#WWCK0#30

This PG is for climb-over/dive-under testing.  Only barrels. 

Left barrel is the "mover" and its Y position is precisely set in line 270.  See info in line 269. 

Hold down the D key.  Keep holding it, and eventually see barrel (left) "climb-over" barrel2 (right).  Clearance height is 36 - an interesting number (see more below).

Needless to say, things are way way wrong.  Mesh are far apart from each other... and still causing collision. 

Set line 270 Y value to 24.0, (RUN, then hold D key) and we get "dead stop" collision.

Set line 270 Y value to 11.9, and we get "dive-under" (hold D key for a long time, it will dive).

Let's see... 24.0 - 11.9 = 12.1.  The barrels are 12 units tall.  Hmm.

All console reports are ellipsoid sizes, not positions.  Right barrel (barrel2) is at Y-position 6, half it's height (line 292).

No barrel .ellipsoidOffsets are set.  Actives keys are WASD (laterals) QE (altitude) R (reset mover)

I think... we got trouble... right here in River City.  Continuing tests.  I'm too scared to try a 2.5 version.  hehe

I have a collide observer on barrel... at line 282-285.  It is working, but its red text colorizing... is over-ridden by line 187 which happens every keypress.  De-activate 187 to see text change to red on-collide.  Unfortunately, there is no barrel.onCollideClearedObservable ... to change text back to yellow when collision has cleared.

I guess I could TRY to code one.   

[Wingnut]

Ok, we're back on this thread... with #31 playground... simple 2-cylinder .ellipsoid collision tester - active mover keys WASD QE R.

When @Deltakosh got back to town, he immediately adjusted some boundingBox code, which DID improve our heightMap physics, but not our built-in ellipsoid collisions.  This thread is branched from a physics thread.

Thread history:  This thread is a 'branch' from another thread.  Forum-friend @TomaszFurca was using physics in his scene... but having problems with his player and barrels tipping-over, and sometimes minor sinking-into-terrain (which we named "muddy ground") (not same as complete mesh fall-thru).  Anyway, when Tom decided to quit physics and instead, use BJS built-in ellipsoid collisions, THEN I asked him to split the thread (which he kindly did).  I wanted the physics-issue thread and HIS demo of that issue... to remain active.  Then he opened THIS thread, so we could talk about the NON-physics issues (like moveWithCollision and ellipsoids).

The return of our savior:  Yay, Deltakosh is back in town.  So we will ask HIM about the #31 playground, and tell him to hold-down the D key, and see if HE thinks the BJS collision ellipsoids are .positioned correctly.  Ignore the green spheres, DK.  They are only caused by our calls to .showEllipsoid (tries to create a sphere that is .positioned same as mesh.ellipsoid) and .setEllipsoidPerBoundingBox (an automatic ellipsoid size-scaler).

Hold D key a LONG TIME... to see barrel1 "climb-over" barrel2.  Keep holding D key until climb-over completes.  Barrel1 Y position is 36 after climb-over.  Much too high.

Just ignore the green spheres, as wanted, Deltakosh (and others).  They have no checkCollision flag set.  They are "collision inert" 

Just use the WASD QE R keys... to drive-around the left cylinder/barrel. 

Is it acting correct?  Are collisions happening in correct places?

For me... no.  On my computer with Firefox, collisions are happening at bad locations.  They happen when there is much "gap" between barrels.

I thought MAYBE this issue was related-to heightmapImpostor boundingBox issue.  But, now DK fixed the heightmapImpostor (at least partially), and we still have problem with non-physics collisions.  Colliders seem mis-positioned.  Help welcome, from anyone.

I have a personal bitch (not towards you, Tomas) about the lack of forum-helper participation.  Visit The Wingnut Chronicles for talk about that.

[TomaszFurca]

After some tests from my side i don't find successful result of check collisions method. So from my side I still wait for help from anyone.

For moving I back to physics, but with box, which is parent of player Mesh - then it works, how i need. But resolve problem with checkCollisions is needed for other reasons.

I work on Chrome 56 and 58.

[GameMonetize]

Ok here is something better:

http://www.babylonjs-playground.com/#WWCK0#32

Please check line 45: this is how to compute the right ellipsoid.

Check also line 9,10 and 11 to get the correct diameter

[Wingnut]

EXCELLENT!  Thx DK!

I actually caused my ellipsoids to be too big...  @ line 45.  DARN... why didn't I catch that?

(because I didn't have mesh.showEllipsoid() working yet) 

[GameMonetize]

We are stronger as a team

[Wingnut]

Absolutely agree.

[TomaszFurca]

Hmmm... actually is pretty perfect, but elipsoid is in wrong y position.

After some test I prepare this:

http://www.babylonjs-playground.com/#WWCK0#33 - then press Q, set position Y of barrel1 (line 100) to negative and press E. Now collisions are sems to perfect, but elipssoid mesh is now generated correctly and i must fit it using offset (line 107)

After some tests and changes, check this: http://www.babylonjs-playground.com/#WWCK0#35

Added 

line 49

this.ellipsoidOffset = new BABYLON.Vector3(0, this.ellipsoid.y, 0);

 line 184, comment that:

mesh.ellipsoidMesh.position = mesh.position.add(mesh.ellipsoidOffset);

 

[Wingnut]

*nod*  I think I understand.

http://www.babylonjs-playground.com/#WWCK0#36

Hold 'D'.   Moving barrel should NOT be allowed to go under barrel2, correct? 

Our green spheres are overlapping... when we hold 'D' key, and do this travel-under.  Our green spheres should NEVER be allowed to overlap, right?

I 100% agree, but...

...did you see @Deltakosh comment in other thread?  " Regarding the sliding issue (into terrain valleys), this is because initially... collisions were made to do FPS camera. "

Good info from DK.  The built-in collision system was not designed/intended to be used for what we are trying.  It was designed-for a movable first-person-shooter camera (view from player's eyes)... to properly bump into things.  Not intended for use with a player-mesh, using follow/chase camera.

In documentation, @Dad72 gave us a demo (thx Dad!)  It uses Z & S keys, and mouse for turning).  This demo might be misleading... because it uses chase/follow cam.  But still, it does basic colliding... just fine (against heightMap ground and wall).

So, it is a good demo, and a misleading demo, all in one.    His demo uses...

meshPlayer.ellipsoid = new BABYLON.Vector3(0.5, 1, 0.5);
meshPlayer.ellipsoidOffset = new BABYLON.Vector3(0, 2, 0);

  ...in the importMesh callback area [browse his code].  This is a standard human-like shape, lifted-UP a bit, position-wise.  Nothing weird.

With Tomas' scene, player collides with many things.  Some things are short, some tall, some narrow, some wide.  It is a much more-demanding collision-active scene - more things can go wrong. 

I'm not sure what the wise solution, is.  IntersectsMesh (which is pure boundingBox collision and not .ellipsoids, I believe)... CAN be used... but it won't give us the "walk-around" or "climb-over" features of the ellipsoid/moveWithCollisions system... unless we code our own collision system using intersectsMesh.  hmm.

Tomas... I think... if you can get the ellipsoid collision system to do as you wish, GREAT!  Use ANY adjustments that you need/want, just so it works for you. 

I'm sorry that the perfect system is not here, but we will be looking-at this issue, and doing more thinking... for the future.  Currently, all three of our collision systems (ellipsoid, intersectsMesh, and physics engines)... have some drawbacks.  But, they are VERY important for almost all games... so we must pay attention to them, and find the best techniques.

@Convergence might be interested in seeing the mesh jitter when player constantly walks against wall (in Dad72's demo).  Convergence has some jitter problems when using constant downward push (fake gravity) in renderloop.  (Although the jitter seems less, today.  Perhaps Deltakosh tweaked some code.)

I think jitter happens because this system avoids constant collision.  If collision happens, system "pushes back" a little... to exit collision state (constant collision is a performance killer).  Just a theory... not sure.  Convergence might need to use... 

var gravStep = .01;

scene.registerBeforeRender(function() {
    if (!player.intersectsMesh(ground, true)) {
        player.moveWithCollisions(new BABYLON.Vector3(0,-gravStep,0));
    } 

    else {
        player.position = ground.getHeightAtCoordinates(player.position.x,
            player.position.z).add(new BABYLON.Vector3(0, gravStep, 0);
        gravStep = 0;
    }
});

// something like that. *shrug*  You must re-set gravStep = .01 if you JUMP or somehow lift player,
// or make player walk-off cliff. I'm sure there are wiser ideas/methods.

Anyway, that is somewhat off-topic for Tomas thread, but perhaps Convergence will join us for further ellipsoid collision discussions.  More minds, more ideas.    Be well, guys... talk soon.

PS: Convergence/whomever... I DID do a little experimenting with your scene, using 3.0, non-workers, other changes... also using Tomas's new .showEllipsoid and .setEllipsoidPerBoundingBox funcs (some tools that Tomas and I needed, and that Deltakosh recently fixed for us - thx DK).  I pretty much failed to discover anything, but I am going to do more playing.  Fake gravity is pretty important.  I want to see what the options are.  Experimenters should probably activate line 16 or line 60... to (try-to) keep our yellow shown-ellipsoid... at the same .position as gray mesh sphere.  Wingnut still learning/testing. 

[Convergence]

15 hours ago, Wingnut said:

 

@Convergence might be interested in seeing the mesh jitter when player constantly walks against wall (in Dad72's demo).  Convergence has some jitter problems when using constant downward push (fake gravity) in renderloop.  (Although the jitter seems less, today.  Perhaps Deltakosh tweaked some code.)

I think jitter happens because this system avoids constant collision.  If collision happens, system "pushes back" a little... to exit collision state (constant collision is a performance killer).  Just a theory... not sure.  Convergence might need to use... 

var gravStep = .01;

scene.registerBeforeRender(function() {
    if (!player.intersectsMesh(ground, true)) {
        player.moveWithCollisions(new BABYLON.Vector3(0,-gravStep,0));
    } 

    else {
        player.position = ground.getHeightAtCoordinates(player.position.x,
            player.position.z).add(new BABYLON.Vector3(0, gravStep, 0);
        gravStep = 0;
    }
});

// something like that. *shrug*  You must re-set gravStep = .01 if you JUMP or somehow lift player,
// or make player walk-off cliff. I'm sure there are wiser ideas/methods.

Anyway, that is somewhat off-topic for Tomas thread, but perhaps Convergence will join us for further ellipsoid collision discussions.  More minds, more ideas.    Be well, guys... talk soon.

PS: Convergence/whomever... I DID do a little experimenting with your scene, using 3.0, non-workers, other changes... also using Tomas's new .showEllipsoid and .setEllipsoidPerBoundingBox funcs (some tools that Tomas and I needed, and that Deltakosh recently fixed for us - thx DK).  I pretty much failed to discover anything, but I am going to do more playing.  Fake gravity is pretty important.  I want to see what the options are.  Experimenters should probably activate line 16 or line 60... to (try-to) keep our yellow shown-ellipsoid... at the same .position as gray mesh sphere.  Wingnut still learning/testing. 

Thanks Wingnut for the suggestions

I don't actually have this problem with a groundmesh, I have a similar solution to yours, however there are also other various meshes the playermesh can walk on, which is where the jitter (that was the word I should have used) occurs. And to check for intersections on every frame for every possible intersecting mesh will probably kill performance..

Optimally I would just like to disable the pushback' from the collision worker.

The .showEllipsoid is a very useful function you wrote there; are you sure its still accurate when it comes to mesh scaling and a non-standard position of the pivot point?

[Wingnut]

Hi @Convergence.  No, I'm not sure of anything.   Those ellipsoid tools are pre-alpha (barely turned-on and begging for all the help they can get).  I doubt that they can handle scaling or unusual pivot points. 

Heck, I can't even get them to stay .positioned, even with line 16 parenting method.  I think parenting method must be abandoned.  I think I need to wedge-into the IRQ vector.  (hehe, old Commodore 64 talk).  For us, it's called register Before/After render.   

It would be nice if .showEllipsoid was rendered with a shader... in post-processing, or similar.  I think that's how .showBoundingBox is done.

Good questions, C.  We could definitely use your expertise (and from others, too).

I agree with your intersectsMesh comment, too.  Likely slow.

And I saw one other possible "thing".  It looks like .moveWithCollisions automatically sets a collider on the moved mesh, even if moved mesh.checkCollisions = false.  So, we/I really shouldn't be moving those ellipsoid tokens (the yellow too-much-tessellation spheres)... with .moveWithCollisions (line 60).  We/I should use a non-collisions mesh-mover for the yellow token... or use parenting.

AND... I don't know IF there IS a push-back.  But the shaky/jitter is there, and that is SOME evidence that it exists.  I guess I/we need to study some code and watch some numbers.

I think I will re-read RaananW's 2-part series about collisions... see if I can learn more things.  It's mostly about workers, but he might mention this push-back thing.  We'll take ANY knowledge that ANYone has.  We're just that kind of knowledge collectors, we are. 

My lack-of game-coding experience is not helpful at all, though.  You mentioned angle-of-collision in your other thread, if I remember right.  That would be sweet, and IF there IS a push-back (undo the collision state, post-collision), then THAT code must have determined an angle-of-collision, or else it wouldn't know which direction to push-back.  Perhaps collider.velocityWorld.

I have SO much to learn.  Perhaps we are wasting our time... trying to adapt this collision system... to be our one-stop for ALL our non-physics collision needs.  Maybe we need another, more-robust system.

Perhaps physics engines are the best way... even though physics engines do not like forced .positions and .rotations.  I think we need a .moveWithPhysics()  - possibly using a physics joint between player's head and an invisible mesh above head, as Fenomas suggested.   (Work-WITH the physics engine and not so much forcing - which can cause impostors to lose orientation sync with their assigned shape mesh.)

Yeah, any info and ideas that ANYONE has... are certainly welcomed, in this thread.  Improvements/additions to .showEllipsoid() and .setEllipsoidPerBoundingBox() are quite welcomed, too, including changing their names and complete re-thinks/re-factors.    Anything goes - we're in mad scientist mode.  heh.

[Wingnut]

Oookay, I re-read Rannan's 2-part thing.  I got no epiphanies, (sudden, new enlightenment)... but still a good read.  I learned things.

At the end of part 2, there is a comment (first one) about disabling collisions on skyboxes... when using workers.

http://www.babylonjs-playground.com/#1XM3K6#2

Interesting.  When workers enabled... we cannot disable collisions on skybox.  So, collision-active camera... won't pan/move.  Interesting!

"Stuck in a skybox with you" - Stealers Wheel.  errr... no.