solved Collision and Gravity Mystery

[JohnK]

On colliding with a box the camera sees through the box.

In the following PGs I have used camera.ellipsoidOffset to place the camera at the middle of the ellipsoid (line 86) and used two viewposts. The lower viewport uses a second camera slightly above and behind the main camera. I have added a cone to represent the main camera with an ellipsoid around it. I have also customized the key input behaviour. Up and down arrow keys move the camera forward and backward , left and right arrow keys turn the camera. I have also lowered the speed of the camera.

Face a box and walk towards it until it collides and will not move forward. You can see through the box.

https://www.babylonjs-playground.com/#DHMD1C

There is also another mystery as the camera moves forward it rises upward as can be seen by the spheres parent to the main camera. At the start you can only see the top of the sphere then as it moves the whole of the sphere becomes visible. You can see the changes in y in the console.

Perhaps they are to do with my customised input manager but no - I removed it and did a PG with default behaviour same problem

https://www.babylonjs-playground.com/#DHMD1C#1

TLDR;

These issues came to light as I am in the middle of writing a PBT (playground based tutorial) for camera collisions, gravity and customized camera inputs and have been following this thread with interest. Last week I never noticed the gravity issue or the see through the box issue. Now whether changes instigated as a result of this thread 

has altered some property of the camera or I am mis-remembering what I saw a week ago or was just too focused on the code for the PBT I am not sure but the mystery is there now.

 

 

 

[Wingnut]

https://www.babylonjs-playground.com/#DHMD1C#3

Hi JK.   Any changes? 

Camera.minZ was fooling us into believing we can see thru the box.

Also, I turned on camera._needMoveForGravity = true... which caused the camera to move upward at scene-load... which tells me that something was positioned too low, and ellipsoids are Y-overlapping.  Thus, the camera rises when first cam-nav happens (in earlier demo).  A vertical "scrub-off".

Lastly... extra white space at bottom of posts?  ahem.  heh.  (hug)  I hope I've been helpful.  Just more things to document, eh?  *nod*  (sorry)

[JohnK]

8 minutes ago, Wingnut said:

Also, I turned on camera._needMoveForGravity = true... which caused the camera to move upward at scene-load... which tells me that something was positioned too low, and ellipsoids are Y-overlapping.  Thus, the camera rises when first cam-nav happens (in earlier demo).  A vertical "scrub-off".

Need time to digest this - perhaps I should have taken wine with it!

[Wingnut]

  I hear ya.  These "things" messed-with ME, TOO, when I worked with those collision barrels, and the minZ thing got me when working-with Kurhlaa's "which side of the plane" collision issue.

MinZ is sneaky.  That SOB will bite you at the ODDEST times.   

And don't forget engine.collisionsEpsilon  ...  that's "how far out-of-alignment must two pushing-on-each-other ellipsoids BE... before scrub-off happens?" - setting.

And remember that... while holding down camera forward key against a collision... camera vertical jiggle can happen... USUALLY because camera gravity is on, and the camera is trying an ellipsoid "scrub-over" (climb-over)... but keeps falling back to the ground (and back-sliding) because of cam gravity.  That one took a while to fig.  Mostly happens with small obstacles, or obstacles which are somewhat buried in the ground.

It can also happen with a camera ellipsoid dive-under (belly scrub - heh)... when ground collisions is set true.  Camera tries to dive-under/scrub-under a slightly-elevated obstacle, yet ground refuses to let camera zoid... enter into ground zoid.  Same kind of fighting, but camera gravity is not a factor.  Wedging is happening, between ground ellipsoid and obstacle zoid. 

On another note:  I'm puzzled how Splash got his stairs to work so nicely.  I tried showEllipsoid on the stairs, and the collider is way off to the side and up in the air.  Yet... those merged-box stairs work just great.  How?    It would be nice if we could sprinkle some of that SAME "magic dust" onto the polyMesh/extrudeShape versions of stairs.

[JohnK]

1 hour ago, Wingnut said:

which tells me that something was positioned too low

Yep you're right. One of those stupid errors, the ellipsoid is 2 units high so half the height is 1 not 0.5

By not setting camera.minZ the camera 'saw through' my ellipsoid lines, next job re-position them so they are out of view of the camera. That's the way it goes solve one problem create another. Party on............ (who say's that??? )

[Wingnut]

Oh yeah... .ellipsoid values are radii, right?  Not diameters.  I always forget THAT, too.  Ow... there's TOO MUCH to know... I'm out-of brain space! 

JK, I added a little section about dive-under... to my prev post.  It might be something to "cover" in the docs, too.

Dive-under wedging between ground and raised obstacle... is something I have not tested very much.

To test, I think collisionsEpsilon will need to be set "thick"... to avoid sideways scrub-off during the wedging tests.  Maybe not.  Get zoids left/right aligned nice... no chance of sideways scrub-off.    (no, readers... don't REALLY set it to 'thick'.  Set it to a number that makes scrub-offs seem thick.) 

Then... yeah, ram a camera between a slighty-elevated obstacle, and the ground.  I wonder if it will jiggle, or just wedge-in tight and stop dead.  hmm. 

Why has a mental image of an elephant trying to pass thru a thick grove of bamboo... come to me?    Sort of like... bowling with elephants.  heh 

Flying a camera thru a ball pit.  Ellipsoid-plowing festival.  (Wingy plants a field of ThinZoid sweet-corn, and polishes his bowling ball.)

Having a good grasp on moveWithCollisions()... is handy in this area of town.  Is it's parameter a distance?  Is it a velocity?  (is a velocity... a direction with magnitude?)  (same as a force?) 

Folks think about them there thangs, sometimes.   

I heard a rumor... that moveWithCollisions(possiblyMisNamedParameter) may have happened.  This may cause the need for some documentation "explaining".   Not sure.  Good adventure.