Weekly Update (3/30)

This week I finished the camera collision FINALLY. The problem I was having was that if the character was in a FreeMoveZone with puzzle elements (walls and blocks), I was getting that most of the time the camera was colliding with walls and/or blocks even when I knew that wasn't the case. I went back and examined the code thoroughly for the (insert large number here)th time, and I discovered that I was just checking for an intersection with a Plane object, which extends to infinity; I never actually checked if the collision occurred on the bounds of the object itself. So after fixing that, the camera collision works as expected, it only collides with FMZ boundaries if there isn't a FMZ behind it. There are spots where it will, but that is because the boundaries of the adjacent FMZ don't extend as far as the one the character is currently in, so the code only detects one collision instead of two collisions.

The way my code works is like this:
I create a list of Vector3s that will hold the vertices of every relevant object at that time. The relevant objects being the current FMZ and everything inside it, as well as the adjacent FMZs. I also keep track of where in the list does the object type change. What I mean by that is I add the vertices of all the blocks first, then a create an integer that holds the count of the list at that time, so that will denote when the WALLS start, and I do the same after the walls, because then I add the FMZ vertices to the list. I also keep track of how many vertices are in each type of objects. For example, walls have 6 vertices each, while the blocks have 36. This is important because when I check for collision, inside the loop I have another index variable that loops through how many indices the current object type has. That way, for example, if the camera is colliding with a block, it may be colliding with the front AND back faces, but since it is the same object, after it detects collision with the front side, we don't care that it is colliding with the back.

After I find all collisions, I sort the lists based on the collision distances. I then check the first collision object type. If it is a Wall or a Block, we stop there and update the camera position accordingly. Otherwise we see if there are an odd number of collisions. If so, this basically means that we are colliding with the boundary of the current FMZ and that's it, and therefore update the camera position. An even number of collisions (where the first collision isn't a wall or block of course) basically means there will be only two collisions. The first being the current FMZ boundary and an adjacent FMZ boundary. In that case we don't want to change the camera's position at all, because the player should have no knowledge of FMZs or portals, and if the camera collides with what seems like an invisible wall that they can move through, there's obviously something wrong.