Adam and I wrote most of the header files for the initial design. These include Triangle, Room, and ball.

-- JonathanSamples - 26 Feb 2004

I implemented all of the classes. These include Triangle, Room, Ball, and Path. At this point I havent been able to run it because of compiler errors. I submitted it anyway so that the guys could have something to work with.

-- JonathanSamples - 28 Feb 2004

Today got all of the compiler errors out so now we have something that runs. I also, go the interface running today. At this point it uses the idle method of glut and that should be satisfactory for the initial prototype however it will probably not be very good once we get into the game design a little deeper. Also, at this point the ball does not change velocity. Since we are not required (at this point) to have it do so I didnt implement this yet.

-- JonathanSamples - 29 Feb 2004

I changed the interface so that it now has some reference lines so that you can actually get a 3D feel. I also changed the perspective so that it is not right on so you can actaully see the contour lines. Also, in room now instead of calling the collideVertices function once and having it figure it out for all three I just call it three times passing a vert each time. I think I will do the same for edges probably.

-- JonathanSamples - 01 Mar 2004

I had hacked the glut include and just had the libraries in a local folder so now I changed it so that the libraries are in their correct places and the dlls are in theirs. I did this so that our code will work on the lab machines.

-- JonathanSamples - 01 Mar 2004

I was able to make the view point to spin and really give the viewer a 3D point of view. Also, implemented most of the collide edge function but dont have the solveQuad function working for me yet.

-- JonathanSamples - 01 Mar 2004

Adam and I worked the bugs out of both the collide edge and collide vertex functions. As well as fixing the solveQuad function. So now we have working tests for both of these cases. For the edge collision we have the ball start on the positive x-z plane and move -z toward the edge on the x axis. For the vertex we have the ball start on the neg x axis and move in the pos x direction to hit the vertex at the origin. We are still waiting for joe to put his function in. We do have a test for his function but as of now it doesnt pass it because he has not implemented the collide face function. As of now we just have the ball stop whenever it detects a collision. We do not give it a new velocity except the (0,0,0) vector.

-- JonathanSamples - 01 Mar 2004

This morning checked on the code to make sure joe had implemented his function and he had but he was unable to compile or debug on the lab machines because of the weird error with the glut.h file and how it redefined exit. So I had to compile and tell him what the results were so it was sorta the worst and most indirect method of debugging I have ever been a part of. I had to fix the fact that the test we had, had the ball colliding with a triangle in the x-y plane to one that collided with a triangle in the x-z plane. Then the verts were in the wrong order so I fixed that. Finally, it still wasnt detecting collisions and I was able to narrow it down to one particular peice of the function that was returning prematurely so I just commented it out and then we were able to detect face collisions. This is just a hack though and joe will need to get it rectified as soon as possible. I also compiled the release version and posted it on the wiki. Although it is doing something strange. Before when we posted executables they just would promt you for download or open immidiately but now it tries to run the program in IE. So you have to right click on the link and "Save as" to download it.

-- JonathanSamples - 02 Mar 2004

Tonight I started on the second prototype. I got the new files necessary for normalization and for matrix operations on Tuples. I added them to CVS. I had to taylor some things in them however. I implemented [] indexing for trinagles so now we can use that syntax instead of getV1 and the like. The reason I did this was because the new code uses such syntax and I didnt want to mess with Z's code too much. I also changed the interface so that now we can input ball posiiton and velocity while the program is running. Oh ya I also changed the getRed... functions to just a singe setColor function. The other way is just stupid.

-- JonathanSamples - 06 Mar 2004

I implemented a test program for edges. I did it as she recomended. Implemented random ball and edge generation. It is edge generation on the x axis so it is not that radom of an edge. We ran it a lot of times and it only failed about one out of 20 and we think that is due to numerical inacuracies because on the first step every time it gives a theta of 1 which will not collide but then on the next step in returns a theta of -.00008 or something like that when it should be 0. So we need to implement a fudge factor in order to compensate for that. We also found a bug in edge detection while implementing the test. It looks like we forgot some parenthsis so that the factor of two in the linear term of the quadratic only had half of it being mulitplied by two instead of both of the terms.

-- JonathanSamples - 8 Mar 2004

Today I went in to get help from Z. For some reason, even though all of the tests we ran passed, or pretty much all passed. When I actually run it using the interface it stops the ball permaturely for edges. So we found the bugs, yes there were two. First when calling collideEdges we were passing the wrong vertex as the end vertex of the edge so when computing if the collision occured on the edge and not just on the x axis it would return a wrong value! The second bug was in the final if statment--it didnt have an else so when that test failed, it didnt do anything and then when it jumped out of the above nested if it would skip over the else and so would just return 0 every time. I though the compiler would complain about not returning anything but it looks like VC has a default. That is anoying. But now its all working correctly.

-- JonathanSamples - 11 Mar 2004

Ok, today I implemented the standardization. So now we use standardize in the constuctor of triangle to set the standard triangle pointer and the transformation matrix members of the triangle class. So the vertex and the face collisions work as far as I can tell. I havent done any extensive testing yet because we dont have any kind of collision response yet so the ball just stops whenever it hits something. I also implemented the edge standardization. I dont know why it was having linker problems but when the edge standardization was declared as a global function it didnt compile so I just made it a member function of trinagle. It doesnt affect anything but now it links. Go figure. I call the edgeCollision detection function once for every edge (so three times) before each time I set some variables that need be reset for each edge since there is a different standardization for each edge. So you have get a new transformation matrix and then transform the velocity and ball path each time. I have tested all vertices, the face and all three edges of one triangle but from only one angle each but i think it is working. Also, collision for faces only works for one side of the triangle, I believe that is how it is supposed to work. So we are kinda caught up.

-- JonathanSamples - 25 Mar 2004

Today, helped Adam debug the collision response. For some reason the new move function that he created to use vectors to move the ball instead of just an absolute position was screwing up somehow when the ball only had velocity in the Z direction. But we got that fixed. Also, tried to help Joe debug the file input. It worked for about five minutes then it didnt anymore? He said it was a problem with Visual Studio but... I integrated the timer so that it wont run ridiculously fast in the lab and normal on my machine so now it should run normally on both. I also implemented a camera of sorts that can be controlled by using the 'w', 'a', 's', 'd' keys to either circle around the ball (a,d) or to move closer or furthrer away from it(w,s). It works ok for now but I think we will want to be able to just move in any direction so I need to figure out how to do that. So it looks like we should be good to go for the demo on thursday. Oh ya, response is working but the ball still sinks into the triangle once it's velocity gets small enough.

-- JonathanSamples - 30 Mar 2004