solved Why camera can go through the mesh which is checked collisions?

[Emiya0306]

Here is my simple playground demo.

Just like the title described, Why this ArcRotate camera can go through the mesh? Is this the gltf file problem?

 

[Wingnut]

Hi Emiya!  (Hi to other forum users/helpers, too).

  Emiya... the built-into BJS collision system (checkCollisions/moveWithCollisions/cam.applyGravity, mesh.ellipsoids/offset)... was meant for FreeCamera, and I don't know if it will work with ArcRotate.  We should wait for more comments and do some tests.

https://www.babylonjs-playground.com/#XY4MQ5#4

Here, I changed to freeCamera.  Then I added a few helpers... like .setEllipsoidPerBoundingBox() and .showEllipsoid()  (both at the top of playground).  I call those functions on each member of container.meshes array.

AND, I turned-on .showBoundingBox for each container mesh, too.

We can see a few collision ellipsoids out there (proxy wireframed mesh to show how/where the ellipsoids are currently set)... and we can see that some/many have mis-positioned pivot points/origins  (not in center of mesh area).

Emiya... invisible vector3 'volumes' stored in anymesh.ellipsoid... are what is used for built-in collision system.  In the .showEllipsoid() helper function, wireframe yellow spheres are added to the scene... to try to show WHERE and HOW BIG the current mesh.ellipsoid... is.  The yellow wireframe spheres are temporary, and only serve to help us visualize the collision .ellipsoid.  (for each of the 15 mesh in your container.  The container itself is not a mesh, so it cannot have a .ellipsoid or a .checkCollisions.)

Same with .setEllipsoidPerBoundingBox().  It is an ATTEMPT to set do just that... set the mesh.ellipsoid to the same size as mesh.getBoundingInfo().boundingBox

So, what we really have now... is a slightly-advanced testing scene.  That's all I have done so far.   

Two other properties are involved.  When a mesh calls Wingnut's badly-coded .showEllipsoid(), the added ellipsoid is stored in mesh.ellipsoidMesh.  It is not used by the scene AT ALL, but it CAN be used to move the .ellipsoidMesh... any time the ACTUAL mesh is moved.  In other words, the mesh.ellipsoidMesh does not move or turn with the mesh.  If you move the mesh, you need to move the yellow wiredFrame .ellipsoidMesh... the same amount... or it gets left behind.  The .ellipsoidMesh is ONLY available after calling .showEllipsoid.

The other important property... which IS active on ALL .checkCollisions mesh... is mesh.ellipsoidOffset.  This is a simple vector3 to move-around the .ellipsoid position withing the mesh volume/area.

Ok, there's the test playground briefing.  Exciting, eh!  (snore).

Emiya, you might want to leave behind THIS type of collision system... and perhaps use intersectsMesh or ActionManager's onEnter and onExit stuff.  Using those two systems... would probably require that you parent an invisible sphere or box... to the camera.  This is becuase those two intersect methods... are used for mesh-to-mesh collisions, and NOT for camera-to-mesh.

The built-in collision system that uses .ellipsoids, .ellipsoidOffset, .checkCollisions, .moveWithCollisions, etc... was ACTUALLY designed for FreeCameras colliding with mesh in first-person shooters.

There... briefing complete, I suppose.  No solutions yet, but, if we want to make the builtin collision system work correctly, we will need to get our .ellipsoid correctly sized and positioned... first thing.  Then maybe make an invisible box and set its .parent = arcCam.  Then set the box .ellipsoid size/offset properly, then set its .checkCollisions true, and see what blows-up.

Emiya do you see that you have ONE boundingBox... that seems to surround the entire fountain?  If we could get the mesh.ellipsoid for THAT mesh... sized-up and centered nicely, then we could use ONLY that mesh as our master collider.  Or we can add a new invisible box or sphere... with .checkCollisions = true.  We have some options, here.

ALSO keep in mind... that arcRotate cameras have radius limiters available.  You can make the camera stop BEFORE hitting the fountain.... simply with the .radius limits on the camera.  Would THAT work for your needs?

https://www.babylonjs-playground.com/#XY4MQ5#5

In this version, I tried to set all 15 container.meshes to .visibility = 0.01;  Worked like crap.  There should be up-to 15 yellow wireframe spheres in-scene.  I see 3/4.

https://www.babylonjs-playground.com/#XY4MQ5#6

Now, all container mesh are completely transparent, and I zoomed-in on the base ellipsoidMesh.   Some other yellow wireFrame .ellipsoidMesh are inside (trying to hide from us). 

This can be done (15 different collision .ellipsoids).  With a bit of grunting, and maybe some "origin" work in the modeler... we could get working collision .ellipsoids on all 15 sub-models of the fountain.  But, probably easier to put one invisible mesh around the entire fountain container, and set ONLY its .checkCollisions = true... and then use a freeCam, or parent a mesh to arcCam, and see if we can get basic collisions working THAT way, first.

WAY too much info, eh Emiya?  Sorry.  Maybe you, I, or others... will try a simple invisible-box-around-all-container-meshes method... soon.  But be sure to test the ArcCamera radiusLimit first.  That is the easiest method.  You can still move the arcCamera .target from mesh to mesh, no problems... but the ArcCam's radius limit will keep the camera from getting too close to ANY targeted mesh.  Pretty handy.

Ok, I hope I've been helpful.  Write back.  Other comments arriving soon, likely.

[aWeirdo]

Just have to apply collision to the correct mesh  

Had to set a rather large collisionRadius due to the shape of the mesh, but it still acts strangely sometimes.
http://www.babylonjs-playground.com/#XY4MQ5#7

[Emiya0306]

@Wingnut Hi Wingnut! Thank you so much for answering my question such carefully, the help functions are so nice, I'm very gald it gives me a lot of help.

1. Could I consider that each mesh, which I import from gltf file, has its own ellipsoid and ellipsoidOffset? (Maybe each mesh represents the different part of this model.) And because of that, I should enable all these meshes' checkCollisions and change the ellipsoid of each mesh to the correct size(maybe a little bigger than BoundingBox of this mesh) and position(maybe the center of this mesh). And then, maybe it work?

2. On the other hand, is this the modeler work? I mean making these meshes ellipsoid and ellipsoidOffset correct.

3. In help methods, I found this.getAbsolutePosition() will let meshes ignore the container.meshes[0].scaling, is it right?

Is this idea correct? I don't have a try because it has a lot of staff to adjust these meshes to correct. In my free time, I will test it and paste the PG link to here. 

[Emiya0306]

@aWeirdo Hey aWeirdo! That's very interesting! How do you find the correct mesh and correct collisionRadius?

[Wingnut]

Hi Emiya.

I made a HUGE mistake on #5 and #6 playground.  I needed to enable line 31.

Now we can look at a better #5.. https://www.babylonjs-playground.com/#XY4MQ5#8

Notice some of the ellipsoids are too low, and some are too close to camera (and are little sized).

#1.  Yes.  Each mesh is assigned an ellipsoid and ellipsoidOffset during the import, I believe.  Their initial location is based upon the 'origin' or 'center' of each mesh that is set in the modeller.  If the ellipsoid is in the perfect center of each mesh boundingBox WITHOUT using .ellipsoidOffset, that is ideal.  But, BJS .ellipsoidOffset should work just fine... to adjust the ellipsoid position, too (no matter where mesh 'origin' is positioned by the modeller).

#2.  Yes, somewhat.  Most important in modeller... is that the 'origin' or 'center' of the mesh... is actually in the REAL center (as best possible).  I THINK... mesh.ellipsoid is based-upon mesh origin/center.  SO, if your mesh origins/centers are perfect FROM the modeller, then the ellipsoids SHOULD be perfectly centered... when used in our scene.  In the #8 playground, most of the origins/centers are good, but at least two mesh have weird origins/centers.  (Those are represented by the two yellow ellipsoids that are in-front-of the fountain.  Those two are positioned too close to camera, right?)

Note:  IF you can use a single mesh as the ONLY collider... (like aWeirdo's meshes[13] collider-only), that would make life easier for you.  It might also be wiser... when using this collision system.  SO... if you need really really accurate collision testing, then yes, trying to recenter the origins of each mesh in the modeler... would help.  Then import back into BJS.  Ideally, no .ellipsoidOffsets would be needed (they're already perfectly centered in each mesh boundingBox area).  We would only need mesh.ellipsoid sizing... to make the colliders bigger/smaller.

Note:  I don't know much about these 'containers' that you are importing... or much about gltf at all.  Do these containers have a "base origin" or "center"?  Do all contained mesh... derive their origins... offset from container origin?  So many things I don't know about gltf formatting and importing... sorry.  Hopefully, smarter people than I... will know more, and comment soon.

#3.  getAbsolutePosition() is mostly for position and not for scaling.  I'm no pro, but it is my understanding that .getAbsolutePosition() returns world-space position + local-space position.  Let's look at a mesh translate command...

mesh.translate(BABYLON.Axis.Z, amount, BABYLON.Space.LOCAL);

(Pretty code-pasting in this forum, eh?  4 lines of black for 1 line of code... in my FF 52)  Anyway...

This translate command moves a mesh in its "localSpace".  In a way, this is meshOffsetFromOrigin, right?  The standard mesh.position might not change after this command.  Mesh.getAbsolutePosition() WILL change.

I hope I didn't say anything wrong.

One question we all have... regarding your project...

How accurate/precise do you wish your fountain colliding... be?  Later, will you be testing for collision of tossed coin -> water?  Test when a tossed coin collides with pedestal?  If you want THAT level of precision, then yep... you need to somehow get ellipsoids centered and sized perfectly.  If you ONLY want to keep the camera from hitting the fountain, then it can be done much simpler... using a single collider like aWeirdo used.

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

Speaking of aWeirdo's single mesh collider... let's advance it a bit more.

https://www.babylonjs-playground.com/#XY4MQ5#9

There... I have set ellipsoid position upward a bit (compensate for meshes[13] having its origin on the floor).  Then I expand it a bit... and now we can do some (more) camera collision testing.

EllipsoidOffset seems like it has bad axes.  Line 64 should have moved the ellipsoid up the Y axis.  Instead, we needed line 66.  Not good.

The camera is acting VERY strange upon collision.  Not good.  Also, poles of gold wireframe ellipsoidMesh are on the sides.  Not good.  (tired of hearing "not good"?)    See " uh oh" below for more info.

Anyway, this is just some more experimenting.  Keep in mind that we also have intersectsMesh and ActionManager onEnter and onExit colliding, still available to try.  Both require parenting an invisible mesh... to the camera, though.

Sorry if all this stuff seems difficult.  Lots of learning needed for a simple task, eh?  *nod*  My two badly-coded funcs... .showEllipsoid and .setEllipsoidPerBoundingBox... is an attempt to make things easier.  I think we need more helpers.   

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

Uh oh... I did some further tests...

https://www.babylonjs-playground.com/#XY4MQ5#11

Line 79... attempt to move meshes[13] upward on the Y axis (altitude).  Instead, the water mesh... moved -Z.  This is not good.  This could mean that the model was created on a modeler with a different axis/coordinate system... possibly a right-handed coordinates system.  This is the reason why lines 64/66 seem broken.  The entire model is oddly-transformed, rotationally.

I don't think scene.useRightHandedSystem = true; will help us.    Could be a bug in our gltf importer, too, I suppose.  Also, it seems we used-to have a "rotate during import" feature/option, but I'm not sure if it works on the container loader, or on ANY gltf importing.  Help welcome from others... on this... PLEASE.

Still, I THINK we CAN re-rotate (entire container, if possible) and then do eachmesh.bakeCurrentTransformIntoVertices().  Maybe.  Let's ask for help from smarter people than I... about that, too.    (I'm not very helpful, Am I?  Sorry.)

By the way... all these oddly-positioned "origins"... might fix themselves... after we get the gltf transformed onto some different axes - axes that BJS likes better. 

Sorry for all the talking, but this subject requires some talking.  Let's all think about what's happening with the gltf loader, here, and about how to get this fountain... differently-rotated and baked.  Emiya... if you don't know about baking transforms, that is a way to change the rotation of a mesh... yet keep its .rotation and .rotationQuaternion properties remaining at 0,0,0.  It adjusts vertex positions to cause a rotation... without needing to set .rotation or .rotationQuaternion.  It gives the mesh a different "natural" rotation.  Does that make sense?  I hope so.

Emiya... do you know which modeling software was used to make the fountain?  Blender?  3DSMax?  Just curious.

I'm going to study the gltf loader docs, a bit.  loader.coordinateSystemMode = BABYLON.GLTFLoaderCoordinateSystemMode.FORCE_RIGHT_HANDED; looks interesting.  Also BABYLON.GLTFFileLoader.HomogeneousCoordinates = true; looks interesting.  hmm.  Not yet sure HOW to test them in your scene, though.  Studying...

Stay tuned... more coming soon.  Got questions?  Keep 'em coming. 

[aWeirdo]

15 hours ago, Emiya0306 said:

@aWeirdo Hey aWeirdo! That's very interesting! How do you find the correct mesh and correct collisionRadius?

When you don't know it from the modeller, trial & error is often the only way  

[JackFalcon]

19 hours ago, aWeirdo said:

When you don't know it from the modeller, trial & error is often the only way  

Yep +1, strategic trial & error on importing. Mix many prototypes...

For camera-collisions -> zoneCam. Here is the concept:

A FollowCam with simple limits.

Dynamic Boxes of custom (flat) thresholds.

2 Examples:

if(cam.position.y > 10) {cam.position.y=10}. //stay out of zone.

Add interpolation on tangent and... cam no break mesh. 

Applicable in some cases, like landscapes.

Or 2 //stay in zone...

A camera that stays with a target in a pre-defined region.

Adjusting to a new bounding box when target enters new zone.

zoneCam. Performant solution if Cam can collide with too many objects to check.

[Wingnut]

  Good ol' aFalcon "brain table of contents" comment style.  If each entry was clickable (un-folding)... we could click-drill for more details about what the heck aFalcon is talking about. 

aF:  strategic trial & error on importing. Mix many prototypes...

I think Emiya was asking WHICH mesh of the 15 used by fountain... should be used as the boundingBox.extends size... to automatically apply to a camera collisionRadius.  Is that the issue that YOU are addressing, aF?

Me, I would "sum?" all the boundingBox.extends used in the entire model, then make an invisible checkCollisions meshBuilder-box of that size.  No need to set .checkColliisons on ANY of the mesh models, that way.

Or merge all the meshes and then use the result's extends-size for mergedMesh.ellipsoid size. 

But we still have not determined if Emiya needs super-accurate collision testing (perhaps to detect where a tossed coin landed/impacted), or basic summed bbox collision accuracy, or something as simple as camera.minRadiusLimit.  We got no info, and aFalcon is speaking in TOC.  :/  heh

Camera zones?

[JackFalcon]

@Wingnut ...  another mentor teaches principle-of-both. It is a perspective that works well in technology and context like this. 

The concept of zoneCam can be helpful to many people. But as you said, hard to tell if it is relevant here. Possibly not, but still good to add to basket of ability.

 

[Wingnut]

aF:  Performant solution if Cam can collide with too many objects to check.

After thinking about that further... I think I get it now. 

I couldn't fig how/when a camera-zone system would be useful, and I have never seen anyone use such things... other than LOD.  ArcCams already stay in a zone with their target... but the zones are circular/spherical.  

So... if a cam is not within some distance of a mesh... mesh .checkCollisions is set false?  Interesting idea.  CheckCollisions maxZ. 

The less mesh in the collision-testing array, the faster the system collision polling?  Ever tried it, aF?

[JackFalcon]

Nice. Great points. I will look for maxZ.

console.log -> ERROR: afalcon 10,000ft.

 

[Emiya0306]

@Wingnut Nice answer for my question! Thanks a lot! I get so much helpful knowledge about it. 

I just started learning how to import models recently. I think I need to learn about both two (High precise and low precise) way to check collision.

But just like you say, low precise way that we can use single mesh to check collision, and set the ellipsoid and ellipsoidOffset to suitable value, then we get it!

For hight precise way, more good staff depends on modeller staff! We just enable all meshes' checkCollisions, and use our pretty helper to check it. Then, tell the result to modeller suitable or not and make our life more better. 

I think my problem has already been resolved! Thank you every one! @aFalcon @aWeirdo  

[Wingnut]

Cool!  Did you model this fountain, E?  Pretty nice. 

Which modeler?  Blender?  Max?  RenderMan?  Amaya?   Know?

We COULD have a bug in BJS gltf importer... which makes your model be sort-of rotated somehow.

I hope it's not a BJS framework bug,  but, I would like to investigate further.

If there's ANY chance that you could share the modeller file with us, that would be great.  (.blend, .max, whatever.)

I use a free github account to publish some of my files... to the public.  Here's my github misc folder...  https://github.com/Wingnutt/misc

I have no .max or .blend files in there right now, but I sure could.  See the mesh01.obj file in there?  Now look at this playground... https://www.babylonjs-playground.com/#3FV2X#13

There's my mesh01.obj... being used in a playground... so we know there's no CORS origin problems with free github accounts. 

And we can drag'n'drop files into the github folder... from home computer.  Easy.  I have never regretted getting my free github account.  I actually love it, and try not to abuse the 'gift' with too many huge files.

Hey, fellow gltf importer people... have you seen this incorrect-axes gltf model problem... before?  Any info about this... quite welcome.  If anyone has info, or knows how to "transform" the fountain onto better BJS axes (with JS playground code)... that would be great.  Speak up, gltf and transform experts... please.  (thx!) 

Is this 'container" stuff... new?  Possibly broken?  This is the first playground that I've seen LoadAssetContainerAsync used.  Not sure what its story is.   Anyone got thoughts? 

Ok, bye again. 

[Guest]

gltf can look backward or forward depending on the tool that generates them. Spec evolved recently and now it defines the forward facing vector.

But for gltf generated before they may look at the wrong direction. But I see no problem with the fountain here

 

AssetContainer is a new feature of 3.2 and it allows you to easily load / unload portion of a scene (think about game levels for instance): http://doc.babylonjs.com/how_to/how_to_use_assetcontainer

[Wingnut]

Hi guys, thx for the replies.

@Deltakosh https://www.babylonjs-playground.com/#XY4MQ5#14

Line 59 tries to move water meshes[13] +Y.

The water mesh actually moved -Z, yes?

No problems?

[Guest]

No problem  you are changing local coordinates of the given mesh but as it inherits from its parent and parent has rotation this is working as expected

If you want to move it in world coordinate you have to use translate: https://www.babylonjs-playground.com/#XY4MQ5#15

[Wingnut]

Ahhh, they are Quat-rots!  No wonder I couldn't find them.

https://www.babylonjs-playground.com/#XY4MQ5#16   (see console results from lines 73-78)

Yep, meshes[13]'s parent, and its parent's parent, and then parent levels 5 and 6... all have quat-rots.  I'll be darned.

What a model.  Some kind of parenting festival.   Interestingly weird.    Thx DK! 

[Wingnut]

Update:  https://www.babylonjs-playground.com/#XY4MQ5#22

Ok, I got out the chainsaw... and hacked this puppy to pieces.  Pressure washing. 

First point of interest:  A new master parent for the fountain... called fountain.  It is scaled the same as the old parent/root... container.meshes[0].  It is a box... mostly invisible, sitting in the center of the fountain's base.

Next... the washing - lines 78-90.  Commented well... it removes all sorts of bacteria and germs from the container meshes, and re-parents everything to our new fountain parent.

It seems... there are only 5 "pertinent" mesh in container.meshes - meshes 6, 9, 12, 13, 14.  Weird.  What are the others for?  *scratch* 

Lines 112-117... tip 'em up.  All 5 of these main mesh... were laying on their backs.  We needed to stand them up... and we did so by quat-rotating them... -90 degrees around X axes.  Quaternion rotating sure is ugly code, eh?  It scares my dog sometimes. 

Lines 119 - 124... bake 'em down.  Weld them in place.  Keep the mesh oriented how they are, but reset all the quat-rots to 0,0,0,1 (identity).

Lines 126-132 ... make sure they got set that way.  See console.

Lines 136-139 - the testing lines.  They all work perfect!  YAY!  2nd level water is moved up, left, and back... 15 units.

Lines 143-147 - do a little animating of the fountain box... our new master parent.  Looking good.

Lines 149-153 - refresh the boundingInfo... which, hopefully, does SOMETHING important. 

Lines 155-164 - activate all my setEllipsoid and showEllipsoid helpers. 

Complete disaster.  The ellipsoidMesh are nowhere near where they are supposed to be.   

Oh well.  It was going good till then.  heh.   Perhaps I left some dirt... after the washing.   

Do I dare .showBoundingBox on all 5 mesh?  I'm scared.  https://www.babylonjs-playground.com/#XY4MQ5#23

Hmm, looks darned good.  Apparently, the mesh origins/centers are still toasted, or I have some issues with my two helper funcs.  Wingnut incompetence, for sure. 

[Guest]

Nice!

[Wingnut]

RAID Quaternion Killer... 16 oz aerosol spray.    "Identifies and kills quat-rots... where they live."  heh

"Identify".  Get it?  Set all quats to identity == identify?  ar ar ahem.  Let's sniff that fountain file.

https://raw.githubusercontent.com/AwesomeFE/UntitledGame/frontend/home/client/src/mobile-game/assets/models/GamePlayer/fountain/fountain.gltf

Gruesome!  Url found inside...

https://sketchfab.com/models/44b51abf755941c3a71c477f77d08b25

SketchFab 3.18.2

A few things named "3DSMeshMatrix" in the file, too, so it probably started in 3D Max.  Interesting.  Pass-around Poly.    (the local girl that everyone had as a lover... at least once)

I wonder if we will see MANY SketchFab GLTF's being imported into BJS... in the future?  I wonder if they will all need "unwanted rotation cleaning" like I did?

I wonder if an algorithm CAN be designed/coded... that CAN determine IF/WHEN a model is importing unwanted rotations.

In summary, I wonder how many more times... in the future... cleaning Sketchfab models will be necessary... to get nice BJS imports from SketchFab gltf's.  hmm.

I wish I were a genius.  :/

[Wingnut]

https://www.babylonjs-playground.com/#XY4MQ5#26

Some ellipsoidOffsets adjusted... looking pretty good.

Line 180... container.meshes[14] remains disabled, because it APPEARS to be exactly the same mesh as container.meshes[12].  (third level water, inside the tiny top hole of the fountain).

Line 41... I re-activated camera collisions.

Line 42... enlarged the camera collider thing.  Colliders for ArcCams... interesting!

Line 43... engine.CollisionsEpsilon = 0.001;   Why?  I dunno.  This value MIGHT affect the tendency for the camera to "scrub" along the collision sphere... IF repeated inward mouse-wheeling is done AFTER initial collision.  Scrub-off tendency.    When pushing two bowling balls together continuously, how much off-center must they be... in order to NOT "stop dead" and instead continue moving and "scrub off" one another.  Wow, that's not easy to explain.  heh  I think this value... adjusts that offset amount.

A person should disable line 147 animation... to test stuff better - with more accuracy.  Animated mesh collision ellipsoids (ellipsoids with varying .position)... will make camera->mesh scrub-off testing... nearly impossible.

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

Really, only mesh 13 is used for the camera collision, because it is so big, and it 'encompasses' the three water colliders.  As long as mesh 13 is set .checkCollisions = true, the camera cannot collide with any of the 3 (smaller) water colliders.

Fun with colliding.  I learn stuff EVERY TIME I play with it.  Now if I could only remember anything I learn. 

But Emiya is probably saying "holy crap, that was like giving birth to a rhino!"     (Wingnut hugs Emiya and makes sure he isn't having a nervous breakdown).  heh.

(Wingy lifts the hood of SketchPad and looks around in there... checking for retardation.)    FOUND IT!  Oh wait, that's a mirror, reflecting an image of me.  Nevermind. 

[Wingnut]

A post/replies from/to @hansnolte has been moved to...

http://www.html5gamedevs.com/topic/37088-loading-models-and-checking-collisions/

Sorry for any inconvenience.