Camera jumps back at low height meshes

[bestog]

Hello,

I'm currently building a scene where a person walks through a room. There are several objects in the room.

When I run and run against a large mesh, I collide and can't get through (it's wanted). When I walk towards a low (low height) mesh, I'm suddenly reset, probably to the old position.

Camera position: [0.1.2, -2.25]
Camera ellipsoid: [0.5,0.59,0.5]

Scene gravity: [0, -9.81, 0]
Bottom is at y = 0

How do I set the camera's collisionsbox correctly to run on the floor and not get the effect of low meshes?

 

Thank you.

[Wingnut]

Hi bestog, welcome aboard.

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

Hold up-arrow until camera impacts barrel2... which is small and mostly buried in ground.

Keep holding up-arrow.  Camera bounces forward/backward.

Same issue as yours?  Probably so. 

I have no solution, but perhaps, now, we all have a playground example to test/play-with. 

I have a theory, though.  Our colliders try to "rub-off".  The camera collider is much higher than the barrel2 collider, so camera tries to "climb over" the barrel2 ellipsoid.  BUT... camera.applyGravity is STILL true... so camera slides back to ground.  Over and over... attempted climb-over, gravity says no.  Thoughts, anyone?

[Wingnut]

More:  https://www.babylonjs-playground.com/#WWCK0#46

Here, same procedure... hold up-arrow. 

I tried an experiment in lines 140-145.  If camera and barrel2 collide, move barrel2.ellipsoidOffset.y HIGHER into the air, perhaps matching camera ellipsoid height perfectly (trying to avoid climb-over/gravity-fall issue, theorized earlier).  No change in symptom.

Then I try line 132... initially-set barrel2.ellipsoidOffset.y HIGH ABOVE barrel2 mesh, and try colliding again.  Same symptom.

So, perhaps there is framework bug.  It seems barrel2.ellipsoidOffset is NOT being considered.  hmm.  Still studying.

[Wingnut]

Addenda:  Reminder to Wingnut and others... when barrel2 is below ground, and .checkCollisions = true on BOTH, then we are in continuous ground-barrel2 collision state.  Perhaps a bad thing, but maybe not.  Perhaps ONLY when camera is in continuous collision (like it is most of the time - with ground)... that we need be concerned.  hmm.

Also:  The wireframe "showEllipsoid" sphere-like mesh - it is stored in barrel2.ellipsoidMesh.  It was put there by a barebones func called showEllipsoid, at top of PG code.  Funny thing - in line 144 of this PG, I set barrel2.ellipsoidOffset = 5.  When collide happens, we see .ellipsoidMesh move to 5 units high.  Use down-arrow to back-out after collision... to see the .ellipsoidMesh at 5 units high.  But... I didn't put it up there!  I never called line 145.   I have no observers on barrel2.ellipsoidOffset... and and and.   How did .ellipsoidMesh move up there?   It's just totally blowing my mind.    Upon collide, ellipsoidMesh re-positions to Y=5 just fine.  But... ironically, it seems like .ellipsoid itself... ISN'T moving to Y=5 on-collide.  SO STRANGE!!!  I think it's a CODE GHOST!!!  

One more test:  [link]  In this PG, don't waste time.  Hold up-arrow, and enter jittery-collision with barrel2.  Hold up-arrow longer... let it bounce.  After approx SIX seconds, I set camera.applyGravity = false (via a timer in lines 251-253).  The camera jitter/bounce is VERY-reduced, after 6 seconds.  hmm.

[bestog]

@Wingnut 

Thank you very much for the great contributions and the detailed playground. 
You handled my problem well. As I read it out, is that a general problem in the library? The camera wants to try to climb over it, but I don't want it to.

Do you have to increase the gravity or adjust the ellipsoid to get a good approximation to the solution of the problem?

Thank you for the quick help!

[Wingnut]

Hiya bestog.  Thx for the kind words, and thx for discovering/reporting this issue.

You ask good questions.  I'm not sure what to do about this.  I think we need to do more tests... to see if barrel2.ellipsoidOffset is working correctly/at-all.  I was hoping we could get MANY forum helpers to help us with this issue, but that hasn't happened yet.

There is a STATIC property...  engine.CollisionsEpsilon .  This value is the AMOUNT of positional offset that two colliding ellipsoids must attain... before a climb-over, dive-under, or rub-around... happens (I think).  Unfortunately, it is not user-settable (although I need to learn about "updatable statics").  Another problem is that it affects ALL collisions (possibly including cam-to-ground), no matter if the collided mesh is low/small or high/tall.

hmm.  I REALLY don't think barrel2.ellipsoidOffset... is working, but I make lots of mistakes.  I need to do more testing.  In this playground, line 132 moves the ellipsoid 10 units into the air.  In this condition, holding up-arrow colliding shouldn't happen AT ALL, yet it still does.  Why?  I dunno.  It makes no sense to me.

So... I have no solution, and I'm FAR-FROM an expert with this collision system.  Sorry.  I'll keep thinking and testing.  Hopefully, others, with more/better ideas, will comment soon.

[Wingnut]

Hi Bestog and other forumers.  I haven't given-up work on this issue, and I got a little time last night... to turn knobs and see what breaks.

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

Same ol' stuff... a small .checkCollisions cylinder (barrel2), mostly buried in ground.  It's .ellipsoid has been sized exactly to match it's boundingBox, and it has no initial .ellipsoidOffset.

When scene starts, I begin increasing the X value of barrel2.ellipsoidOffset (in line 265).

For fun, you can wait until the .ellipsoid is far away... and then hold up-arrow to drive camera into barrel2.  IT STILL COLLIDES!  It probably shouldn't do that.  Bug?  Anyone know?

In an earlier post, I mentioned that engine.collisionsEpsilon appears to be NON-user-settable.  But, I learned some things. **

Barrel2 does NOT have a "collider class" object, but the camera DOES.  In this version 52 playground, (in lines 267 & 269)... I did some little experiments with the camera._collider.

One thing that COULD be done... is onCollide, set camera._collider.basePoint.y = camera._collider.collidedMesh.position.y.  After first collision, we could move the camera's ellipsoid to exactly match height of collidedMesh ellipsoid... so no attempts allowed for camera to climb-over or dive-under the collision.

BUT, this has a potential problem.  Lowering the camera's collider... will make the camera rise into the air more, because of the continuous collision-with-ground that the camera is also doing.

**  The collider on the camera... ALSO has an .epsilon... and it IS user-settable.  SO, possibly, setting camera._collider.epsilon = someStrangeValue... MIGHT keep the camera from trying to climb-over the low, small collision.  Remember I said that collision epsilons are the amount of difference-in-position-required... for a "rub-off" (such as a climb-over) to become active.  So, it seems, that with a large enough number... a rub-off will NEVER happen, and that is what is wanted.  BUT... perhaps that is what is wanted... on LOW, SMALL mesh, ONLY.  Maybe for normal-height, larger collisions... you DO want some rub-offs... such as "slide-arounds".  So, that big camera._collider.epsilon value... might SUCK for taller mesh/collidables.

Let's pretend that user/camera walked-into something small and low (you need to test for that), and camera came to a stop, as wanted (because we set the .epsilon to a high number after the first collision was sensed).  When do we set it BACK to normal?  hmm.

Now user turns-away from that collision, and does some more "walking".  What you COULD do... is... when the camera does 3-5 successful non-collision moves, reset the camera._collider.epsilon back to default value... preparing it for normal-height rub-offs.  ONLY when the camera collides with low/small things.. do you set .epsilon to a big fat number.

You can test if a collidedMesh is low/small... by testing its boundingbox sizes/extends, and its position.

Gruesome, eh?  camera._collider has a LOT of knobs and dials, so there's lots of experimenting that could be done.  It could become a "smart collider"... knowing exactly what it is colliding with, and able to adjust itself based upon measurements done to .collidedMesh.  But keep in mind... that the camera._collider is dual-purpose.  It is in NEAR-CONSTANT-USE keeping the camera from falling through the ground.  Make a change to the _collider, and the relationship of ground-to-collider... will also change.

Here's another thought.  Once the camera is at ground level, turn off ground.checkCollisions and camera.applyGravity.  We have a func called... ummm...  ground.getHeightAtCoordinates(X/Z).  With this device and the renderLoop, you can constantly GET the height of the ground underneath camera.position... and set camera.position.y continuously... so camera is always at ground level... even in mountainous terrain.

After that, the camera._collider will be dedicated to ONLY watching for X/Z collisions, and no longer needed for Y-axis ground collisions.  Any future adjustments done to properties on Collider class... will not affect camera Y position.

Meantime, I STILL don't think freeCamera is taking mesh.ellipsoidOffset into consideration whatsoever.  I'm still searching through freeCam collision system as best I can... too see if mesh.ellipsoidOffset is ever considered or calculated-into the collision testing.  As you can plainly see, my barrel2 ellipsoid can be offset FAR FAR to the right, and up-arrow collisions still happen.  I dont think this is good/right, but I make mistakes fairly often.    More later, if/when I learn more.