Jump to content

Why does mesh with collision rise up


MackeyK24
 Share

Recommended Posts

When I place a capsule as a player and set the capsule right above the ground (0.1) and using moveWithCollision... Right when the scene starts... the capsule rises up a little and all the moveWithCollision the capsule is above the ground almost a half o unit...

Why does it do that... and what can I do to put my character capsule on the ground (or really close to the ground) and move around with collision ???

Link to comment
Share on other sites

Hi Mackey.  I have no solution but I wanted to add a testing playground.

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

WASDQE to move left barrel, SHIFTED WASDQE for RIGHT barrel.  All keypresses use moveWithCollisions (in case you want to TRY TO force the barrels back to ground level - Q and shifted Q).

Both barrels (cylinders with shown ellipsoids) are being auto-moved +z with moveWithCollisions in lines 218/219.

Both are 12 units tall, and are position.y = 6.01 (just above ground).

Ground.checkCollisions is set true in line 94.  (disable == no climbing, problem gone).

Both barrels climb to a position.y (height) of approx. 12.017 units.  Related to barrel height?

Both barrels also do an unwanted sideways move, just before beginning the climbing.  Related to barrel width?

Q and shifted Q can force-move barrels back to ground level... AFTER they are no long OVER the ground plane.

I started doing some investigating... but I suck.  If I had to guess, we should be checking boundingInfo and boundingBox/boundingSphere.  Likely something with .centerWorld, .radius, .radiusWorld, similar. 

We COULD say that this is GROUND-related ONLY, but I don't think that is true.  When colliding the two barrels with EACH OTHER (using provided keypresses), I have seen similar issues.  For example, there are problems when the barrels collide from above or below one-another (turn OFF ground.checkCollisions if you do apropos tests).  Generally speaking, collisions are off-by 50% of barrel height... or 100%.... exactly those values.  That screams boundingbox/collider sizes... radius, center, extends, etc. 

But I suck, so I could be very wrong.  :)  Generally speaking, climbing is caused by two ellipsoids in repeated collision, where the climber.ellipsoid.position.y > engine.collisionsEpsilon-amount above collideTarget.ellipsoid.position.y.  (wow, what a sentence)

I believe engine.collisionsEpsilon determines how much difference in ellipsoid position is needed... before a 'rub-around' activates.  Rub-around = climbs, dives, sideways work-arounds, etc.  Axial-aligned .ellipsoids will not rub-around, no matter the amount-of repeated moveWithCollisions() attempts.  (hold D key in THIS playground, to see it)

I may hijack collision-related portions of abstractMesh and bounding objects... into the playground... and get some console readouts.  But I KNOW we can "watch" this happening... numerically, in-console... IF we monitor the correct properties.  I'll try to determine how/where, and ALL others are welcome do to the same, of course.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...