back to main

Update 11/17/09

The math involved with basic movement is mostly kinematics. Collisions will depend on normals and momentum, and the most difficult part will be calculating this for multiple balls. Once that is figured out, the movement variables should be easily plugged into a camera function creating the first person perspective. The example program bnc.c has an incomplete collision function, so Curtis Woodruff has decided that starting from scratch will be the most effective way to grasp a handle on this project while learning C code. He has managed to create a 2D program that simulates bouncing with points and collision bounds. More information can be found at his site here. Taking some hints from Mark J. Kilgard's dinoshade.c which has a very interesting camera control , I have begun work on platform.c which should make free looking the bouncing environment possible. Converting some of camera.cpp by Matt Wraith which was originally in C++ to C established the navigation skeleton for the program.

From the above image, platform.c is obviously a wire cube with a solid sphere inside of it. It also has grid lines and a small white point in the middle. This point is the "reticle" for the camera which was inspired by first-person-shooter controls. For simplicity and the fact that I usually use a laptop, controls were all keyboard instead of mouse commands. The gridlines and reticle are used to help orientation, and the verticle angle is limited to 45 degrees above and below the horizontal for the same reason.

  • W, A, S, D = up, left, down, right movement
  • I, J, K, L = up, left, down, right camera angle
  • R, F = up, down verticle movement
  • Q = quit

    Update 11/21/09

    Curtis Woodruff merged his 2D boucing and collision program with my camera and environment program. The third component of z was easily added in, but as before, the balls occasionally got stuck or disappeared. Ignoring that for awhile, the radii of the balls were made adjustable so that in the future, variable mass and collisions could be made. The issue that the walls of the balls poked through the walls was also addressed so that instead of acting like a point, each ball has a bounding cube. After running the program with multiple adjustments we determined the cause of the "stuck ball." Most notably, when the dampening was positive, meaning the balls gained "energy" after each collision, the balls tended to get stuck a lot more often as the velocities increased. Having previously talked about the difficulty of multiple simultaneous collisions, we concluded that when more than once within the frame tolerance that Curtis set up, the balls would infinitely switch velocities causing them to stop. This explained why the corners and edges were the sticky places. And "if, or" statement was used to accommodate for double and triple collisions, and at the same time, we managed to cut down the code length. Curtis Woodruff should have an updated version soon with the fixes in place.

    Being break, we plan working on more individual parts, but we will still be in contact. I plan on adding gridlines for all the wall of the cube while attempting to fix the camera controls. While not absolutely necessary, making multiple commands at once possible would be very nice. Currently I believe this is a Windows problem because usually simultaneous keystrokes are not allowed. In the final project, also, only angle will be controlled as the movement will be bound to the bounce/collision code. Backtracking a little bit, when we ran the program to determine the origin of the sticking balls, we also found that the fake collisions we had were very noticeable in certain instances. For that reason, we plan to change some equations for momentum and change the collisions bounds into a sphere.

    The plan for this is to use the basic 3D distance formula to detect when the centers are near enough for collisiion and then use a slope formula to determine a normal for the resultant path of the collision. We will most likely have to simulate a center mass and initially make collisions completely elastic so that both conservation of energy and momentum are applicable. If this is successful, Curtis will reconfigure this for dampening and I will work on a curved bottom surface. This will most likely heavily draw from some samples from DPGraph. We should make enough progress by the end of break to have a presentable program.

    Update 11/21/09

    Platform5.c is uploaded. Rather unexpectedly, both momentum and the bottom surface were figured out. The basis behind the new momentum is both conservation of kinetic energy and momentum. Mass is determined by the size of the ball which assumes each has the same density. The bottom surface is simply a function plotted with GL_LINES since a solid surface would be ineffective as there is no lighting to help determine depth. While inefficient, this method gets the job done.

    .

    The next step is to figure out the bouncing in relation to the surface now that it is curved. We may have to differentiate the function to find a normal, but we may be able to apply our momentum/kinetic energy equation but having our surface acting as a bunch of spheres of infinite mass.

    Update 11/23/09

    Well I am sure that the avid fans of the "platform" sereies will be pleased to hear that the latest edition, platform6.c, is up. The ground collisions was put together with the previously used momentum/energy equation with infinite mass walls. The detection method tests multiple points on the surface to find the proper point of impact, so it can be somewhat imprecise and runs choppy when the balls begin to roll. We've also found that large balls seem to work the best and that small balls (.01 in radius) tend to fall through. Currently we are sorting out the kinks. Platform6b will not be up until after break as we are having issues sorting out camera position and movement. This is also the reason why we have not changed the initial camera spot which is not horrible but somewhat frustrating.

    Update 12/02/09

    Platform9.c which fixes most of the collisions but occasionally freezes is up. Platforms 7-8 can be found on Curtis Woodruff's public folder. Number 7 is the most stable version so far, but as of now, we have an essentially finished project. We now are in the process of refining the spheres so they are no longer solid balls. George Francis has proposed both lighted spheres and a loxodromic sphere.

    Update 12/09/09

    The platform series is essentially finished and FinalB.c is our completed PC version. The loxodromic spheres were utilized and the quit button was changed to "esc" from "q." Also, a nifty little thing was added that displays the test points used in determining the ground plane collisions. Using what we used for the loxodromes, we also modified the test points to originate in the same spiral pattern from the center to remove the one-sided preference of the collisions.

    Modification for aszgard also have essentially been completed, so ballball.cpp, as we are calling it now, should be able to run in the cube. Crashing does occur, but not enough that it interferes with demonstrating the basic characteristics of the program. I personally want to improve the both the PC and CUBE programs by adding a restart button as well as variable dampening controls. We also need to include a locked text that details controls and instructions.

    Update 12/18/09

    Final update before submission. Due to time constraints, the final touch ups were never completed. As consolation, I offer an old program never intended for release, platform6x.c which has my personal "disco floor" for those boring nights staring at a computer. Interestingly enough, the pattern is from one of my old DPGraph files called "shells," which I never expected to come in handy. Any questions can be emailed to me; my email should be on my main page. Well, so long my avid fans.

    Related materials can be found in the public file.

    back to main