Devblog 11 - Marrying the building system with the terrain - Part 1

In minecraft the construction system is very simple, since any face of a block works. In our case it is not like that.If you remember, to generate the terrain, we have joined the bricks into a single mesh / model. So when we click to build on that model, we know that the player is looking at a piece of land. But not at which brick exactly.

Posted by on

In minecraft the construction system is very simple, since any face of a block works. In our case it is not like that.
If you remember, to generate the terrain, we have joined the bricks into a single mesh / model. So when we click to build on that model, we know that the player is looking at a piece of land. But not at which brick exactly.
When the player clicks to build, we will have to:
1. Determine what part of the terrain you are looking at.
2. If you are looking at a horizontal or vertical surface (to see if it is a top / bottom face or a side).
3. Determine which stud you are looking at.
In order to know if you are looking at a part of the terrain, we will need the terrain to have colliders.
Luckily this part is "magic" since Unity takes care of it (and it sure won't be the most optimal xD). We add a collider to each chunk and then by code we tell the collider to use the mesh of the chunk in question:

The automatic generation of the collider is quite noticeable. During the generation of the terrain, everything slows down.
Now we can step on and detect the terrain. We proceed to determine what we are looking at.
When we raycast, in addition to the name of the object, we exactly know which triangle of the mesh has intersected.

With the name of the object, we already know what part of the terrain it looks at. It remains to determine if it is a horizontal or vertical surface and for this we will use the triangle.
As you will remember, each triangle is made up of 3 vertices. If the "y" of all of them is the same, it means that they are horizontally aligned but that is not enough. We want to take studs into account and the trick we can use is that they are circular, which means that none of their vectors will be the same since they will all have a slight difference.

Perfect, we now know that you are looking at the top or bottom of a terrain brick. Only the stud is a mistery now.
Each part of the terrain can have a very different shape:

But it is something that, if you realize it, we do not care. Each chunk of terrain is still a grid of studs, only that some are at different heights.

We can imagine that they are all flat to do the calculations.
This way we can use the system that we already had programmed to determine which stud it looks at. Or so I thought.
It turns out that the center of each terrain is wrong. That makes all the calculations have a deviation.
The correct thing to do would be to understand why there is this deviation. (To my understanding it is because of the difference that we are talking about an integer three-dimensional matrix and at the last minute I make adjustments to make it decimal.)
I'm on the fast track and what I do is determine what deviation there is from the center and correct it.

Fixed the deviation, we have to do another retouch. Until now, the construction system expected that each grid of studs had its own collider, which indicated its dimensions in its name.
This does not happen here, as I have commented, we have only 1 collider for each piece of land and this is rarely flat. Luckily it won't be a problem. Why? Because each chunk / piece of land has literally the same dimensions: 16x16 2x2 bricks. That is, it is a 32 x 32 stud grid.