Box (slab) alternative to ellipsoid / ellipsoidOffset (for checkCollisions)

Questions
1

Hi,

Is there a collision box (slab) alternative to setting the collision ellipsoid / ellipsoidOffset when using checkCollisions / moveWithCollisions? (With ‘slab’ I mean the same as a ‘box’, just to hint that it need not be a same size cube.)

When moving around with a FreeCamera on a scene with a Ground and some meshes (loaded models) and a basic shape Box, all with checkCollisions set to true, then I notice that the meshes use the ellipsoid / ellipsoidOffset property of the mesh for collision. And for the simple box mesh (created with BABYLON.MeshBuilder.CreateBox) the collisions are nicely in a box (slab) manner: straight instead of round at the edges.

I am looking for a way to set a box like collision property on the loaded mesh, without the need to create an invisible box mesh (for collision computations) myself or to revert to complex collisions (e.g. traverse all mesh faces etc.). Especially for loaded models that fit better in a simple collisions box (slab) shape instead of a simple ellipsoid (round) shape, the collision box would be a better choice.

The collision box (slab) would not need to be the same size as the bounding box; but the bounding box would be a nice default starting point for setting the collision box. Notice that the BoundingInfo class already works with both a bounding box as well as a sphere (ellipsoid): BoundingInfo - Babylon.js Documentation

If there’s some obvious reason why one should always revert to creating (hidden) collision box manually, let me know as well :slight_smile: Then I’ll just keep on creating hidden boxes with collisionsEnabled for my loaded models…

Q

1 Like
2

Hey QH, you still here? I saw you forum-active just a few minutes ago, as I was finishing-up this PG:

https://playground.babylonjs.com/#KQV9SA#35

Lines… umm… 106+ were all added by me.

IntersectsMesh() is a boundingBox-based overlap-tester/method… but you must test each active scene mesh… one-by-one. There is no eventpacket = player.intersectsMesh(anyOtherActiveMesh). IntersectsMesh() requires a single source and a single target.

So, you can maybe see… that I am iterating thru all scene active mesh (except a mesh named imported)… to check if imported intersects with something. (imported is the mesh going in a circle). IF it intersects a scene-active mesh, it rotates on Y-axis a bit. It’s working, but it’s painful, and it might be a problem with many-mesh scenes.

But still, I wanted to show it to you, so you could ponder it. Got questions about it, holler.

You would want to install this render-loop tester ONLY when you are moving a mesh. Use your observer .add() and .remove() power… to make sure it is only active during a mesh movement. And in this case, you need-not use .moveWithCollisions or .ellipsoid stuff or .checkCollisions = true… because you would not be using that collision system anymore. You have built your own… using intersectsMesh.

There is another box that is off-screen to the right… called testbox. I wanted to make sure IT was not included in active mesh. (…to avoid testing intersect with mesh that are out-of-cam-frustum).

Great question, in your post, by the way. We have needed optional cubic colliders for .moveWithCollisions() and freecams … forever. I think it is somewhat difficult to code. Not sure. It might require big-mods like adding mesh.cuboid and mesh.cuboidOffset, and inventing a cubical collider. :open_mouth: All sorts of hell could happen in Engine.CollisionsEpsilon, esp when an ellipsoid collider… collides-with a cuboid collider. Ouch. :slight_smile: Beer-barrel-belly-boy… meets sharp-edged block-head girl. :slight_smile:

Stay tuned for wiser comments from others… because my post just shows a clumsy work-around… and not necessarily a good solution/system. Good seeing you again, too… hope ya been well.

Issue active… ideas welcome.

3

I think I got the hang of the whole topic/point I’m discussing. Also after studying your playground @Wingnut :slight_smile:

The mover (e.g. the camera or the controlled mesh) uses the ellipsoid, yet for all meshes in the world to collide with the Collider uses the BoundingInfo sphere to do a first fast check if there can be collision at all for the BoundingInfo box, which requires more math due to axis alignment. See the BoundingInfo and Collider class file code.

If the BoundingInfo for loaded mesh assets cannot be used for collisions, because it is somehow off too much from the shape inside it (e.g. the spacecraft or the building etc.), then the fastest way to solve (and make) the collision computation without any additional code on the engine end would indeed be to create a mesh which has the BoundingInfo box property set to the values I am looking for. For example by creating an invisible box mesh with those (smaller) dimensions than the original loaded mesh and set the checkCollisions on that hidden box. Plus parent the collision box mesh to the loaded complex mesh to simplify computations for.

Once colliding (when intersectBoxAASphere returns true), the function after _collide that does the most seems to be _testTriangle on all the triangles in the mesh. This is very precise collision! Hence, the “visual accuracy” of how to collide with a real model mesh when using a hidden collision mesh I can define by choosing the number of triangles of the hidden collision mesh.

A box collider mesh would always have 6 faces and 12 triangles. Playing with a Sphere or Cylinder from MeshBuilder I can create more or less precise “smooth spherical or cylindrical surface” collisions. Theoretically, the computations for an ellipsoid with ellipsoid (sphere) collision could be simplified in Math to only position+radius, but I can understand the precision achieved with that over a real (hidden) Sphere with ‘enough precise’ segments would do the trick without much noteworthy difference…

Concluding: An alternative to ellipsoid could be a cuboid. That will make computations a lot more difficult because of axis alignment with the world etc. Colliding the current ellipsoid with spherical objects in the world could be improved by switching to pure sphere-with-sphere collision math, but would the player notice the difference in a precise enough (hidden) Mesh sphere is used? And when I really want a box as the camera, I would opt to switch to a real Physics engine and make the camera/player child of a Physics box. :slight_smile:

4

Yeah, adjust the boundingBox size yourself, but you don’t need a separate mesh… just force the boundingInfo to new values, and then intersectsMesh will change behavior accordingly.

Lines 116-120. (@adam taught me how to do that… thx Adam.)

No changes for ellipsoid/checkCollisions/moveWithCollisions system, though, as you likely know. hmm.