Jump to content

Camera's ellipsoid from above missing


kurhlaa
 Share

Recommended Posts

Hi,

Simple demo of the problem - http://www.babylonjs-playground.com/#MJRGPB

Try to move to the box from the front or side - camera's ellipsoid (with size 1.5) works as expected. Now try to move to the box from below - you can go a little inside the box and see the internals. You can notice that camera's ellipsoid from above is missing or it's size is 0.

According to this - https://doc.babylonjs.com/babylon101/cameras,_mesh_collisions_and_gravity - ellipsoid should be symmetrical.

Is this fixable? Bug exists only when moving from below the box.

 

UPDATE

Another funny thing is with planes - http://www.babylonjs-playground.com/#MJRGPB#1

... when moving through it from one side - there are normal collisions, but from another - you are able slowly go through it :) like something is wrong with collisions detection.

Link to comment
Share on other sites

Hi kurhlaa.  Yeah, I've seen this phenomena before, talked about it more than once, but nobody ever verified, validated, or agreed with me. 

You're the first.  (thanks)

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

That's "the barrels" playground.  It's been used to test various cam-to-mesh and mesh-to-mesh collision ellipsoids.

In this version... you can move the top barrel downward with shifted-Q  (shifted wasdqe available on barrel 2 - the top one)  As you can see, the collisions happens 1/2 barrel-height TOO HIGH.

Then try moving the bottom barrel 1 upward... with the E key (UN-shifted wasdqe active there).  The collision happens TOO HIGH again, by exactly 1/2 barrel height.

The same is happening with your camera ellipsoid. 

If the camera ellipsoid CENTER is above the bottom edge of the crate, collision happens.  If cam ellipsoid center is below bottom edge of crate, no collision.

This issue goes way back to 2.5 or before, but when a bug/issue is unverified, it doesn't get much attention from anyone.   But now I have validation from another.  Yay!  Maybe folks will pay attention, now.  I also don't think .ellipsoidOffset is working... but you might be able to "work-around" your issue... by setting camera.ellipsoidOffset = new BABYLON.Vector3(0, camera.ellipsoid.y/2, 0) or something like that.

Maybe I will try that with the barrels demo... in a few minutes.  Right now, I'm bitchy and sweaty from a gruesome snow-blowing session.  I live in a snowy land.  :)

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

There's a PG where (if I coded it right)... the camera ellipsoid is moving right-ward (via camera.ellipsoidOffset).  Allow the ellipsoid to move to the right for awhile, then cursor forward with the camera.  Still got collision with the submerged barrel?  Yep.  Not sure why that seems broken.  Wingnut makes mistakes, but if nobody ever talks about these issues, they just go un-answered and ignored.  (Can ya tell I got an attitude about these ellipsoid issues?)  :)  Sorry everyone.

I'll work on this... right after a shower.  :)

Kurhlaa, if you try the .ellipsoidOffset, could you report back the findings?  thx.

Link to comment
Share on other sites

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

Okay, there's my testing facility.  :)  I have "hijacked" into the playground... many of the "parts" that make-up our ellipsoid collision system.  There is another area... the webworker-based collisions coordinator... but I need to study that more.

I believe the problem (if we ARE seeing a "problem") is on BABYLON.AbstractMesh (perhaps Collider), and no problems with camera.   I believe it is something 'stupid' like the use of .radius instead of .radiusWorld, or .center instead of .centerWorld... something like that.  Here we go.  (well, I hope a "we" team forms to help-out). 

If the problem is with Collider... that might make the most sense.  The same Collider class is likely used on camera and mesh.

I start by inserting a million console.log lines, to see if I can learn something from those.  C'mon along.  I want to still keep an open mind-to me being stupid in some way, because pretty often, I am stupid. 

I also see a "freeze" when top barrel impacts bottom barrel.  Shifted-E is supposed to lift the top barrel OUT-OF collision state.  It doesn't.  For me, it's stuck.  And, "the freeze" kills the arcCam nav.

@Dad72, we could use validation from you.  Do you see/verify the "camera-center above/below bottom of crate" difference/strange-ness?  (thx)  Others too, we need verification... if anyone would be so kind.   Are kurhlaa and I seeing clearly?  (Wingy wipes his eyes and slaps his face)

Link to comment
Share on other sites

hahah.  That PG won't RUN in my IE. 

Line 399:21 - Syntax error
 
What the hell?  :o  (Wingy makes some DOUBLE-strength coffee) 
 
Added CollisionCoordinatorWorker and CollisionCoordinatorLegacy to playground.  Added a few console.logs.  Nothing learned yet.  Some console.logs might be silenced because the code is RUN on the "other side" of the webworkers wall.  Still learning.
 
MY browser launches a CollisionCoordinatorLegacy - type.  I wonder if Dad72's browser launches a CollisionCoordinatorWorker - type.  hmm.
Link to comment
Share on other sites

Update:  https://www.babylonjs-playground.com/#WWCK0#82

That gets IE working.  ( IE hates =()=> )

Same symptoms in FF/IE... also launching the legacy coordinator.

BUT... when the collision happens... IE reports:  'intersectBoxAASphere' is undefined

Hmmm

Update:  added intersectBoxAASphere() and getLowestRoot() to PG #83.  No more IE error, and FF is barfin'-out console reports much better now.  Still, symptom remains.  I'm on its trail!  :)  Need more FireFox testers/reports.

Link to comment
Share on other sites

I'm on Windows 7.  No others installed.  Yes, videos can be inserted, I think.  Not sure I ever tried it.

Strange issue.  I'm currently playing with BABYLON.AbstractMesh.prototype._checkCollision

this.worldMatrixFromCache.multiplyToRef... testing.

The next line... this._processCollisionsForSubMeshes  ... is the start of "on collide" as best I can tell.  NOP that out, and I can hold SHIFT-Q and E all day long... no collision processing at all... or not much. 

Learning learning learning.  But... why inconsistency across various platforms/OS?  Weird!

Link to comment
Share on other sites

Yep.  Good video.  Try your playground... approaching crate from the top.

Collision is stopped too soon?  Camera gets blocked BEFORE hitting crate?

Bet so.  Yep, yep, yep.  You and I are seeing the same things.  Mind if I hug you for proving that I'm not insane?  :D

Good tests, K!  Thanks.  We're gonna find out why this is happening, or die trying.  heh

Link to comment
Share on other sites

@Wingnut

7 minutes ago, Wingnut said:

Try your playground... approaching crate from the top.

Collision is stopped too soon?  Camera gets blocked BEFORE hitting crate?

this is probably because my ellipsoid's size is 1.5. If I make it smaller and go too close to the mesh - I can see through it from all the sides, so it was my fast work-around. Try to set :

camera.ellipsoid = new BABYLON.Vector3(0.1, 0.1, 0.1);
 
..and move to the box until collision from any side - can you see through it? Is it normal?
Link to comment
Share on other sites

Well, make sure your camera.minZ is set real low, first.  Perhaps set it to .0001.

You may be seeing camera clipping caused by .minZ

Then... hmmm... I'm not sure WHAT a .1, .1, .1 ellpsoid around the camera... would "look" like.  Maybe I'll test that.

But minZ first.

Link to comment
Share on other sites

28 minutes ago, Wingnut said:

I also think he might be in bed, now... he is in France, and them Frenchies sleep sometimes

Not sleeping again, but soon.

Ok, I see the problem, I did not understand how to reproduce it. the video help me.

I also see the problem. Effectively. So you have to post the bug by putting the video in reference and the PG to explain how to reproduce the problem.

Link to comment
Share on other sites

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

Yeah, low camera.minZ, and camera.ellipsoid at .1, .1, .1... works ok.

You have likely noticed that these colliders "scrub-off-of" each other when the ellipsoids are somewhat offset from one another.

How much offset must the two colliders HAVE... before this scrub-off happens?

http://doc.babylonjs.com/classes/3.1/engine#static-collisionsepsilon-number

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

Line 17 - BABYLON.Engine.CollisionsEpsilon = .1;

That makes the camera more "sticky" after collision (with continued pushing).  Less "scrub-off".

Still... collide camera on top of crate... seems... too far away.

 

@Dad72  We are beyond reporting.  We are "going for the kill".  :)  But yeah, it will be reported if we can't find/fix it ourselves.

Link to comment
Share on other sites

True, camera.minZ = 0.0001 has disabled seeing through the box, I hope it won't break something else :) I see that the default value is 1

But there still are problems with "missing" (or size == 0) ellipsoid above the camera and I can move through the wall

Link to comment
Share on other sites

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

Brought-in boundingInfo, boundingSphere, and boundingBox.  I'm on a new branch of the adventure trail.

Line 632.  That collision happens at the correct time for Dad72.  It happens at the WRONG time... for K and I.  hmm. 

What makes us different, K?  darnit.  I'll figure it out.  :)  (I hope)

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...