How do I check which face of a box mesh is facing "up"?

This seems like a simple question but I haven’t been able to find the answer after a while of looking, and I’m pretty new to game development so it’s possible the answer has been given already but I couldn’t perceive it.

Anyway, I have a player hitbox mesh that collides with floor boxes (a grid of box meshes) and every time there is a collision I want to check if it happened on the “top” of the box (for eg, rather than the side), i was able to use a ray from the player to the box to get PickingInfo because that’s where my investigations were leading me, and so now I know the faceId of the box mesh, but now I need to check if that matches the top face of the box.

I was thinking maybe I could use a second ray from the top of the box down and see if the faceIds match, but I also don’t know how to do that, although it seems like the wrong way of doing it because surely I could get the face’s coordinates and calculate which one has the highest aggregate y value, but that’s mostly what I am not sure how to do :slight_smile: any suggestions?

Assuming you don’t apply rotation to the cubes, you can check the y value of the normal of the picked face. Here is an example with mouse click on a cube faces:

1 Like

Oh ok, thanks, simple enough just didn’t know that I was looking for the normal and y=1 :slight_smile:

Great solution, but maybe you should be careful and perform a check like Math.abs(1-normal.y) < epsilon to be safe (epsilon something like 0.01 for eg), instead of normal.y === 1.

1 Like

What is the difference? Is that in case y is not exactly 1?

Yes, it is in case y is not exactly equal to 1, which could happen if it comes from some computation.

Is that because there is an inherent imprecision in these calculations, or would it be introduced by specific algorithms I might write? (I am just curious at this point). Eg, if you could guarantee the meshes will always have the same position is it still necessary to cater for that kind of computational inaccuracy?

These inaccuracies are an inherent consequence of mathematical calculations massivly used in 3D environments that deal with infinite float values ​​(like PI, a square root result, and so on) truncated to fit the limited float values ​​of computers.

In your particular case, I’m not comfortable enough with 3D and babylonjs to say that whether or not there is a guarantee to always have exactly y = 1 on the top face of your cubes even if you never move/rotate your meshes.

But, I think it’s a good practice to secure your code with the @Evgeni_Popov suggestion: this way you ensure that your code always works the same and you avoid a future debugging nightmare with code that sometimes doesn’t work.

Another argument for following @Evgeni_Popov’s advice is that… babylonJs is very addictive :smile: ! So, in the near future you will probably want to add some funny new features or animations to your game, something like “what if I created an animation like this: when the game starts, cubes are coming from everywhere and then stick together to build the ground” or other stuff, and in this case the y value of the normal will probably never be exactly equal to 1.