Mesh vs MeshBuilder for Collisions

Questions
1

Please bear with me, I am completely new to babylon,js.

When I started with the BABYLON 101 course, it mentioned making shapes using the MeshBuilder. But now I want to implement collisions and which ever example I see, uses Mesh to make the the meshes. This has confused me a lot. Could someone please clear this confusion?

Also, I want to know how to implement collisions for meshes, not cameras (I’m using a FollowCamera). I checked the tutorial, but it didn’t have any example there. I tried the code given, but still the collisions don’t work. (not sure whether I should mention my code here or not). Someone could guide me here too?

BTW, I am making a 2.5D third-person game.(If that helps…)

Thanks in advance, thanks for reading through too.

If any more information required, please let me know as this is my first post!

2

Welcome to the forums!

Mesh vs Meshbuilder. Mesh is more “rudimentary” and Meshbuilder has more options. For example: say I wanted a 5x5x6 cube. With Mesh this is not possible (from my experience) as the code is var cube = new BABYLON.Mesh.CreateBox("Box", 5, scene); This creates a 5x5x5 only. Meshbuilder can have more flexibility when creating meshes. To make a 5x5x6 with it, the code is : var cube = new BABYLON.MeshBuilder.CreateBox("Box", {width: 5, height: 5, depth: 6}, scene); Do you get the difference?

Next, you would like mesh collisions. Okay. Because you have a 2.5D game, that means between the player model mesh and everything else. mesh.checkcollisions = true Only allows for collisions between the camera and meshes. not between meshes themselves. You’ll need physics (Use a Physics Engine - Babylon.js Documentation).
Here is a little demo: https://playground.babylonjs.com/#9Q08R4#7. WASD to move, mouse to look. The camera is a child of the box.

If you notice, you can collide with the little map thing. This is because the map and the cube hahve a physics impostor. The map has a mass of 0. This means that it is stationary, but can collide with everything.

If you would like me to go into detail on the pg (playground), let me know!

Happy coding!

1 Like
3

Thanks a lot for that help!!! Yes, I get the difference now. If MeshBuilder is flexible, then why use Mesh in the first place.(cause MeshBuilder has a size property similar to the one you had explained for Mesh.)

Wait, doesn’t babylon.js have an in built physics engine?, cause I saw this on their BABYLON 101 course (Cameras, Mesh Collisions and Gravity - Babylon.js Documentation), showing a tutorial for collisions between meshes and meshes without an example. Another one I saw, https://www.babylonjs-playground.com/#LYCSQ#315 was this playground, but I tried the code, it didn’t work for me. So I will require to use one of the physics engine (cannon.js)? I don’t require any interactions or bouncing of between the meshes, just basic collisions is what I require.

I was using three.js and cannon.js previously, and was very comfortable with it. I thought babylon.js had an in built physics engine and was more suited for games, which made me try it out…

Yes I would like to go in detail on the playground, Thanks a lot for the help.

Thanks for going through my long post! Please point out where I maybe wrong, if I am.

4

There is a “work-around” for basic mesh-to-mesh… using built-in collision system (non-physics engine). You use a fancy method called .moveWithCollisions() It uses mesh.ellipsoid, mesh.ellipsoidOffset, and scrub-off angle can be adjusted with engine.collisionsEpsilon

It takes a little practice to wire the player movements to player.moveWithCollisions(directionalMagnitude)… but not too bad. The system has SOME limitations… such as dive-under, climb-over, and jittering… when constantly forcing repeating collision (constant pushing of player against wall/object) (held nav-key).

A physics engine would keep player (bottom of mesh.ellipsoid) against ground… automatically.

Using the BJS built-in/moveWithCol system… no gravity on .checkCollisions = true mesh… i don’t think. Also, if you have .checkCollisions true on the ground, the bottom of player.ellipsoid could be in continuous collide with it… which means checking for wall/obstacle collision on SIDES of player.ellipsoid… might be wonky/intermittent. Better to just force player to be certain height above floor, and don’t use colliding on floor.

But watch out for dive-under and climb-over. Colliders are round… so they “scrub-off” or “slide-along” each other, depending upon engine.collisionsEpsilon settings.

It might require that player y-position be constantly set in renderloop… while player is moving-with-collision(). IF you do THAT… now you get full control of player.ellipsoidOffset.y… to use as a player height, and not be concerned with “managing it”… to avoid floor-to-feet collider scrubbing during player moves (spoke-of earlier).

Making a move-with-collision mesh mover… is good fun… but be ready for surprises, especially for low-altitude obstacles) (like knee-high stuff). You MAY find yourself constantly tweaking engine.collisionsEpsilon during the game… depending upon what kind of obstacles you are presenting to your player.

heavy, huh? nod. FUN! Good luck.

Here is a playground (series-of many)… where we once did experiments with dragging and keypress-moving barrels… which had their ellipsoids showing… via an ugly helper-func. WASDQE to keypress-moveWithCollision left barrel, same keys but SHIFTED… for right barrel. And mouse-dragging is active… somewhat.

3 Likes
5

BEFORE @Wingnut ‘s post,
I was prototyping the collisions thing here (https://time-taleggio.glitch.me/ ,Sorry couldn’t put it in a pg (playground), it didn’t work for some reason (even after removing the engine and resizing parts…)). The collisions are working here, but is this a proper way of doing it? I just copy pasted code from here and there, so the code isn’t clean (Sorry abou’ that!).

AFTER @Wingnut 's post,
Woah, that’s quite heavy, but I’m ready to grasp it all! I used the same “moveWithCollisions()” in the above link, but not COMPLETELY sure how it works, any explanation is available anywhere? Also, I didn’t get what you meant by “engine.collisionsEpsilon”. A bit of depth explanation would be nice (for the .collisionsEpsilon and the ‘Y position’ in the render loop part). Thanks a lot for your help!

I never knew I could find amazing community members to help me at my problems (I code under a rock…)! I would like to thank everyone who helped me!

1 Like
6

Notice added playground link in my previous post. It’s a cool one… some demented tests.

Ok… Engine.CollisionsEpsilon could be called “the angle needed for collisions scrub-along to happen”. If you were pushing player against a flat wall, what angle would you need to turn… to make player no-longer be dead-stopped, and instead… start sliding along wall. The same is true for up/down… related to collider-active ramps, I guess. This is why low-altitude obstacles are likely to suffer? from easy climb-over by player. Player is bowling ball, squirrel is a marble, and moveWithCollisions() is a 40 horsepower motor. :slight_smile:

When I say set player y-position in renderloop, that is mostly for height-mapped terrain (bumpy landscape). I think jerome invented a mesh.getHeightAboveGround() thing… or similar… so… if you constantly make sure player.heightAboveGround() > whatever (during player moving)… then you don’t ever need to set ground.checkCollisions = true. In fact, you want it false… because YOU are the boss of gravity and ground following, and you don’t use ground.ellipsoid (colliding against bottom of player.ellipsoid)… for ground-following… at all.

If your ground is always flat… and player should stay resting upon it, then you can simply use y=0 in all your moveWithCollisions() directions… all should be good… no need-for “stick me to the ground” glue. :slight_smile:

And thx for the kind words… we want everyone to have a blast with BJS/webGL. It’s too cool to miss. :slight_smile: Oh yeah, one other thing about collidiing with checkCollision=true… planes. Collisions only work on ONE side of them… the top side. You need to know that. :slight_smile:

Left plane is top-forward… arrow-key camera colliding works fine. Right plane is inverted… and collider sinks-thru like mud. :slight_smile: Also part of the fun… I guess.

Line 265 is interesting, eh?

1 Like
7

You are my saviour!!! You have made me fall in love with babylon.js! :relaxed:
Thanks for that warning about the planes. Was just about to do that! The “sinking through mud” is like converting a bug into a feature :sunglasses:
Line 265, how is .CollisionsEpsilon gonna work with planes and cameras? (cameras don’t a have a shape right, so no curves or edges?).

Anyways thanks a lot for that explanation, you made my day. Thanks to @Givo too for helping.

Happy Coding!
BJS/WebGL, too good to miss. I’m in everyone!

EDIT:
Just tested with the .CollisionsEpsilon, I’m getting some crazy weird behaviour…

2 Likes
8

See the most recent playground I posted. Camera-colliding, right? Only freeCams have ellipsoids… as far as I know. And they have .applyGravity and ._needMoveForGravity = true (to start camera falling at scene.onReadyObservation.) FUN! If used, scene.gravity applies to it.

With proper terrain tilt, it can cause a HELL OF A FUN sledding ride at scene-start - maybe. :slight_smile:

The whole built-into-BJS colliding system… was first-designed to be for first-person shooters… freecameras as the player view… not third-person following. Then… I think it was @Dad72 … one of the early founders/heroes of BJS… who… came up with the idea of moveWithCollisions() add-on semi-dangerous feature… and he and Deltakosh invented it in some dirty warehouse somewhere. :slight_smile: To give due credit, I think local hero @RaananW may have tweaked the Collider class… helping it (MWC) work better, too.

2 Likes
9

Thank you Wingnut for your nice words. After, it is deltakosh who writes it. But it’s true that there was a long talk about this feature at the time. That dates now.

1 Like