Devblog 3 - Fixing the rotation system

After reviewing the rotation system, the first thing I have noticed is the axis of rotation. This should be the exact center of the stud, but as you can see here, it is currently the center of the brick.

Posted by on

After reviewing the rotation system, the first thing I have noticed is the axis of rotation.
This should be the exact center of the stud, but as you can see here, it is currently the center of the brick:

With this we will not achieve more than to rotate it on itself, when what we want is for it to rotate like a door.
The problem was how I calculated the center of the stud (not the brick). I did it based on the fact that 0,0 (x, y) was one of the sides of the brick and that's not the case. 0,0 is the center. So the right thing would be

That translated into code becomes:

If you are a little smart you will have noticed that I'm making a new mistake. This calculation only works exactly for 2x2 GridStuds. Example:

And in fact I am a bit stupid. I previously have already calculated elsewhere what stud is based on the area that each one occupies. I can go there and add more 2 lines to calculate the center for me.

(The only new lines are stud.center.x and stud.center.y)
After changing this, I took a 1x1 brick and went to put it hoping it was right at 1 stud.... Result:

Wrooooooooong.
The above is now perfect, so I keep digging and find another bug.
If you remember, I made the constructor something "smart" and if it detected the same model or the same number of studs, it would center it so that it would be one on top of the other.
The problem is that it was not looking at the number of studs, but the amount of GridStuds that are in those 2 models. And of course, these 2 pieces have only 1 grid each, so it was within the condition.
That's it, right? Aaaaalmost:

The calculations part could no longer be wrong, so the fail was somewhere else and I suspected it was in the GridStuds. (And so it is).
To indicate the measures that each GridStud occupied, I edited the scale of the cube instead of editing the dimensions of the collider.
For those of you who don't use Unity (to understand the error):
All objects in a scene have a component called Transform. Transform contains the location data, namely: position, rotation and scale.

Normally the scale is not touched, but if you touch it, you must bear in mind that you are altering all the vectors / positions that you generate from it.
In the collider component you can touch its dimensions:

So when you are adding collisions to an object using the collider, it is normal to edit the collider dimensions , not the object itself.
I did touch the scales, hence the deviation from the center:
Meh, I have to go over all bricks to put it right.

Self-applause for fixing all fails.

Now it's time to make the piece rotate using that position as a pivot point.
In Unity you cannot (or I have not been able to find how to) change the center of an object on runtime, so we will workaround it by creating a temporary empty object in that position and we will set the piece to rotate with the necessary deviation as child.

It's a bit tiresome because it implies indicating for each model what its pivot vector is and I can't think of anything to do it automatically and efficiently. But the result is unbeatable.

I can finally do the arch!
When doing this, I've seen another little thing that I did not take into account... The bricks can also be connected from below. I wanted to put a block in the middle of the arch, but said option is not supported by the current system xD

Before addressing that issue, I will revisit a detail of brick's preview:
Currently, when you put the brick in an impossible / collision position, it suddenly disappears:

It's hard to understand what's happening from player's perspective. It seems a bug.
I think that, rather than hiding it, I should show it but in red semi-transparent color.