Pushing and Popping, Huffing and Puffing, All to No Effect

For the past several days, I have been working on fixing my sphere to sphere collisions. I kept on finding logical inconsistencies and tweaking my code, each time thinking "there's the rub! That should do it!" But, alas. Today, while debugging for the gazillionth hour and looking at my bounding spheres' centers, I noticed that they were inconsistent numerically with what they were supposed to be geometrically. I realized that I had been calculating the sphere's centers with respect to the local origin of the object rather than the world, so I fixed the problem and now the spheres' centers are correct. However, this did not fix the problem of c always being negative where


c =  distBetSpheres.dot(distBetSpheres) + sumOfRadii * sumOfRadii


GRRR!


To be honest, I also don't quite understand why I am squaring the sum of the radii. I understand how this is derived mathematically, as the orange collision book does a very good job of explaining this part, but I don't understand what this means graphically. I fully intend to ask Keenan tomorrow during our morning meeting.


It turns out that the radii squared are always significantly larger than the magnitude of the vector between the spheres squared, and I don't know why. This frustrates me to no end, especially considering that it's probably an issue that's really simple and that I am overlooking, and when pointed out to me, will make me feel like I do not belong in this field, yet again. Don't get me wrong, I love it. I just really don't want to end up shooting myself in the foot here. 


In order to debug this better visually, I decided to represent the bounding spheres as wire glut spheres while the objects are not colliding, and solid spheres when they are. Also, I was beginning to doubt the legitimacy of the math in my function, namely the c being ridonkulous (I know it's not the c's fault, I reckon it has to do with 2 different scales between the radii and the world coordinate system, or something really obscure). In order to move the process of testing along, I wrote another, simpler function for detecting sphere collisions. This one does not return t for the time of collision, but just returns true or false. All that I do is check if the sum of the radii of the spheres is >= to the distance between their centers. I then set whether they are colliding accordingly. 


Two issues immediately cropped up. 

1. A collision is detected very early. Mathematically, it makes sense as the numbers work out. Graphically, it makes no sense as the spheres are nowhere near touching. This means that something about my radii or sphere center calculations is off. What though? If I fix it, it should also fix the function that returns t and then c won't be all wonky!
2. The glutSpheres for both my cube and pyramid were drawn on top of the pyramid. So, on the screen, I had a lonely little cube with no bounding sphere floating around, and a spinning green pyramid flying across the screen, hogging both bounding spheres. I encapsulated each sphere creation call in glPushMatrix() and glPopMatrix(). I tried calling glTranslatef. Nothing. I even passed ridiculously large values to glTranslatef and yet there it still was, a green pyramid, with two spheres floating around it. This leads me to conclude that the glColor* issue that I had mentioned in my previous post is related to this, that any gl* calls that I make have no effect. I wonder why this is happening. I suspect that it could have to do with the fact that they are somehow being overridden by my other actions, or because I haven't been using glPush and Pop so far, resorting to my own matrices. I don't know enough about OpenGL to know if it has any special idiosyncrasies that I might be missing, or neglecting to respect.  Nonetheless, it is a frustrating conundrum that I plan on resolving tomorrow at the Keenan meeting.

So now, I can report that even though my graphical results look much worse than before, I am actually mathematically closer to having the problem solved. At least I know the issues now.