I recently got the chance to help another of the final project teams with their collisions.
After focusing on the collisions for our game for so many weeks, my mind now thinks in rays, triangles and spheres.
The two things I found that they were missing was, in their sphere swept test, they were going through some geometry, since the "nearby triangles" they were getting was based on the first position of the player and the last, no middle positions. I told them that building a big sphere around the start and end spheres, and get the triangles based on that one would fix their issue.
Personally, I would have done moving sphere to triangle collisions (like in our game), but hey, whatever works for them! At least they got it working now and that's good.
The other problem they were having was that they were basing themselves on a point to get the nearby triangles on their BVH (Bounding Volume Hierarchy) while their player actually has its own AABB and a couple of spheres. I would've done AABB to AABB collision since those are super fast and easy, but their sphere swept test required something different. I told them they should have, instead of a "point in AABB" check, to do a "sphere in AABB" check (which was basically just expanding the faces of the AABB by the radius of the sphere).
Of course, I still prefer moving sphere checks since they wouldn't give us as many false positives as having to check a huge sphere covering the whole player trajectory to get triangles and then check against them.
That's one of the things I would suggest they change if they have some extra time. But right now, I'm happy that their project is working!

Proof of Concept

Today we're presenting our Proof of Concept (I'm not calling it "POC" cause I hate using acronyms).
What we currently have is semi-working collisions (if the triangles are too big, the player falls through) and, since the player aligns to the triangle he's currently on and the level is always moving, you can imagine how twitchy it looks. We need to find a way so that he's not always completely changing his rotation even with a slight movement.

Here's a teaser screenshot (EDIT: TWO screenshots!!):




As you can see, our Frames Per Second are really low... Our collisions are just too complex.
The good thing is, this is debug mode, so in release mode it's still over 60 fps (one of the few acronyms I use).
The vertex and triangle count are 0 because there are no nearby triangles (it only shows those triangles that are near the player, so that we check collisions only with those).
Anyway, here's hoping we fix those collisions soon.

Collisions

Our collisions have been quite broken for a while. Specifically, the triangle to AABB collision.
We tried figuring out different methods that would work for every case (especially, those where triangles are much bigger than the AABB). We even tried building AABBs around each triangle and then doing AABB to AABB... An expensive, sloooow way but which always worked (at least, it wouldn't give false negatives).
And it still didn't work.
This made us realize that the problem had to be somewhere else.
I rewrote some collision functions, like moving sphere to triangle... Just trying to find where the error was.
Apparently, the error wasn't really in the collisions. It was in the way the velocities and the player were being handled.
So, hopefully, we will be able to start adding new functionality soon.

Why the orientation wasn't working...

Ok, so, after I told Bruce my idea of how to orient the player, he implemented it and it didn't work mysteriously.
Instead of trying to figure out why it didn't work, we decided to try out different ways of doing the player orientation.
Two days later, after 5 or so different ideas hadn't worked, we decided to go through the code... It had to be something else that was messing things up.
Right now, I wish we had done that since the beginning...
After two minutes of looking through the code, I realized we were getting wrong normals for the surfaces...
I felt like a total n00b for not finding out that error earlier... But, to my defense, neither Bruce and I had done the module which handled the normals.
Apparently, the normals were created at the beginning and then NEVER updated...
And, considering this is a game were the level is constantly moving, that's a HUGE mistake.
So, I did a function that just re-calculates the normals. However, this now caused more problems, since the previous collisions were made to work with the WRONG sets of normals... That's what people who hack through code usually do...
This issue has taken us longer than we wanted. At least I finished my tasks early so I can now spend time helping solve this.

Climbing and Walking

As I was working on the code today, I was trying to make the player start falling when he wasn't colliding with anything.
The problem, however, is that some collision functions are still a little broken, so I had to work on something else.
Bruce was working on the transition between walking and climbing states. Since the player will be colliding with both the ground and the floor at the same time, we don't want him to start going crazy because, every frame, he would be changing from walking to climbing and back to walking.
He wanted to find out a way so that when the player went from one surface to another, he would face away from the wall.
I thought about it and gave him this idea:
Make the player's forward vector equal to his previous Y axis. Then, rotate himself around the X axis an amount so that his Y axis becomes parallel to the new surface's normal.
Here's a drawing that describes my thought process:




EDIT: After checking this, we realized that, in some cases, rotating around the X won't work, sometimes the rotation would need to be around the Z axis, for example, if the player hits the wall by strafing sideways.

Almost back to coding

So, today was a day spent salvaging things.
My friends Bruce, Z, Kayla, Luis and his wife helped me out.
We went through all the debris and rubble and we found my old nes and snes games. Some of them are totally destroyed. I was lucky to have insurance, so I hope they will replace my things.
Unfortunately, the emotional value some things had can't be replaced...

Here's a picture so you guys can see I wasn't kidding about the fire.

(this is after the cleaning company helped me salvage big things... Trust me, it was WORSE)

Anyway, I've been working on some functions that will allow us to draw little spheres simulating a parable based on the different angle/speed when doing the long jump. The only thing we need to put into the functions would be the horizontal and vertical speeds (which can be gotten via some other functions that I did that take the speed and the angle) and the elapsed time, that way, say, if we call that function 20 times with elapsed times with a certain interval, we will be able to draw the position the player will be in in those intervals.

The question is, how many of these times should we send? And what should the intervals be?
Testing, testing and more testing.

We didn't start the fire...

Thanks to some extremely careful neighbours, there was a fire on my building today, burning my apartment and effectively rendering me homeless for the time being.
I want to thank my friend Kayla for helping me out a lot and my friend Bruce for giving me a place to crash.
So, I hope you guys don't mind if today's post is not as long as the other ones, but I hope you understand that today has NOT been a good day.
Anyway, jumping on the game is done. I couldn't implement it in the project since Alienbrain was too busy, but it's basically just adding the file and doing some changes in the player and it will work beautifully.
Bruce and I have been doing some collisions, maybe we will be able to get more things done since I'm his temporary room-mate!