Last edited 18dec09 by Curtis Woodruff
Find this document at http://new.math.uiuc.edu/math198/MA198-2009/woodruf1/
Bouncing Around
Curtis Woodruff, Jeffrey Zhou
Math 198
Abstract
In this project, OpenGL and C will be used to allow a user to view a ball bouncing in a 3-d environment. For a computer, one will control this viewpoint via the keyboard, however when used in the cube, the user will be immersed. In partnership with Jeffrey Zhou, the ball will be operating with kinematics and a running clock in the environment. I will be in charge of the ball, and Jeffrey will construct the 3-d environment for the ball. Together we will add collision detection with the environment and even other balls.
Here is a screen shot of the first edition of the program with no actual ball, just a line showing the path of a bouncing object. Interestingly, the exact code used in this version is in the final versions of the program. Beside it is much more advanced final version.
Current Features
To place the spheres (balls) in the environment, we calculated paths, tested for collisions, and rendered graphics. Here is a brief overview of each process.
Paths-
Paths are calculated from initial positions, times, and velocities (and acceleration, but that is constant). These are all reset upon each collision. Each frame, a new time is retrieved for each ball, and a "dt" is calculated. With these inputs, a simple kinematic equation can be used to calculate current positions based on the initial position.
Collisions-
Flat plane collisions are calculated when the ball's position exits the bounds of the box. Each axis must be tested separately. Upon detection, the final velocity (of previous path) of the ball is calculated (for each axis), and the ball is reset in a new kinematic path. Its initial position is that of the previous frame (this is the safest "re-spawn”); the initial time is the time of collision, and the initial velocities are the final velocities of the previous path. However, in the axis of the collision, the velocity is reflected and dampened (multiplied by -1 and a percentage, like .9).
Ball collisions were simple to detect, yet harder to adjust the velocities, but all needed values are calculated from the previous kinematic path and applied to the new path. By comparing the current positions in the 3-d distance formula with the sum of the radii, the detection is quite simple. Below is the math involved in calculating the initial velocities of the new path. Note the "impulse magic thing". This is difficult to describe, but it is essentially a constant that helps deduce the final velocities.
Curved floor collisions are quite special. By running an r-theta loop, we plot a spiral of points beneath the profile of the sphere starting at the center to the x-z plane. The y values are then calculated from the floor equation. Then, the 3-d distance formula checks for collision with the sphere (distance should be less than or equal to the radius). The same math as the ball collision is used for the reflection off the floor, however mass is eliminated from the equation. The normal vector is the vector from the center of the sphere to the collision point on the floor.
Graphics-
Professor Francis suggested that we draw our own loxodromic spheres instead of using the solid sphere from the glut library. This was implemented in the FinalA and FinalB versions of the program. The math required to draw these spheres is below. A GL_LINE_STRIP was used to connect the points, producing the coiled appearance. The rest of the environment was drawn with GL_LINES or GL_LINE_STRIP and is rather uninteresting compared to the spheres.
Improvements-
We have tinkered with this program for a while now, and there are only a few improvements needed. First, there needs to be on-screen instructions. Also, we plan on combining the flat-floor and curved-floor versions into a single version. The stability of the curved floor version is still questionable, especially on slower computers. Perhaps our r-theta loop for floor detection can be shortened. The program can almost run in the CUBE at this point, but that code is not available. However, the C code can easily be made functional in such a setting.
Progress Updates
Friday, November 13, 2009
I currently have a program that has multiple boundaries for collisions and a large point to simulate the sphere. This is in 2 dimensions, and there are inputs for x and y position, velocity, and acceleration. Also, there is a version in the works with 2 balls and collisions, however the collisions are still an issue and will be corrected shortly. Also, I have begun to debug the old Bounce program and fix its collisions too.
This program, called "testbounce.exe" is in 2d, has only 1 ball, simple wall collisions, dampening, and acceleration in the negative y-axis (down).
Saturday, November 14, 2009
I have fixed the 2-d collisions and uploaded that to the public folder. The next step is to add a third dimension to the current code.
This program, called "testcollision.exe" is the final 2d version with poor but functional collision detection, gravity, and optional dampening and acceleration for each axis, although recompiling is necessary to alter the settings.
Wednesday, November 18, 2009
The new version is called "platform.exe". The nice 3-d environment was created by Jeffrey, and z variables for initial positions, active positions, velocities, and accelerations were added. Also, collision detection is based on the radii of the spheres, not having the same position as in testcollision.
To navigate this environment, you will need these controls for this and all future versions:
movement--w,a,d,s
height--r,f
turning--i,j,k,l
Thursday, November 19, 2009
Now we have "platform2.exe". I have changed collisions from a collision delay (a frame counter to allow escape from the range in which collisions are detected) to reinitializing position to the previous position. This greatly helps when dampening is added and the balls begin to roll quite slowly. However, when the balls collide at very slow speeds, they still occasionally "freak out." This will be mended when true collisions are implemented instead of the current system of an ideal collision with radius zero.
Saturday, November 21, 2009
In "platform3.exe" we fixed the new prevpos variable (actually an array) and now every collision reverts all coordinates to the prevpos for the xi,yi,zi's and the position that is displayed (and hence saved as the new prevpos). This forbids the balls from being reinitialized past boundaries and keeps the running prevpos array as a guaranteed "safe spawn". Also, grid lines for all sides have been added, and we also added "smart lines" that help the user track the balls better. This just makes easier viewing on a computer monitor and will most likely be removed for CUBE interface.
Saturday, November 21, 2009
This is a quick update, but for "platform4.exe" I applied some conservation of momentum and energy to give the balls true collisions. Varying mass and radii are all accounted for, with a constant density based on the radius. The densities can be changed, but it would quite strange to see a small ball of radius 1 bullying around one 12 times its size.
Sunday, November 22, 2009
By making the ball-ball collision the first to be detected in an IF statement and the wall collisions in an ELSE statement, there can no longer be collisions with balls at the same time as the floor. It essentially waits until the balls aren't colliding to worry about that. This is very stable, even at very low speeds (the roll-outs). In fact the only way to get a glitch is to run the balls so fast that they hit different walls every frame, and the position is continually reverted to the last "safe" one. These programs are "platform5.exe" and "platform5b.exe". The first applies acceleration and dampening to a corner, creating the highest chance of glitches. The second is the usual setup of downward acceleration.
Monday, November 23, 2009
In "platform6.exe" we finally added an uneven ground plane and proper collisions with it. Interestingly, the collision calculation was easy, and we essentially stole it from the ball collision, but detection was really difficult. This works better with larger balls, given the approximations used to detect the collisions.
Friday, November 27, 2009
In "platform7.exe" and "platform8.exe" a "dt" and "dt2" term was added into all of the kinematics equations. This fixed a very obvious mistake that our program had. In every recalculation of trajectory (upon each collision), the time variables were reset, but those same variables were directly used in the following collision calculations, (in that frame). With the new terms, calculated before all the collision detections, the time resets do not affect the following calculations. 7 is the flat floor version and 8 is the curved floor version.
Saturday, November 28, 2009
The final platform release for PC is "platform9.exe". This removed the "prevpos" variable for resetting the spheres after the collision detection with the floor. That variable was causing very glitchy rolling once the dampening slowed the balls, or in instances when they skimmed in and out of the bowl indentation. Instead, the balls are reset to the surface by using the unit vector for the floor collision and the radius as the magnitude. This is and "unsafe" spawn, so that new initial position is not saved as a "prevpos", but is still used as the initial position for the ball until the next collision.
Friday, December 4, 2009
Just kidding. Now we have loxodromic spheres so that the spheres are more visible in the CUBE. Also, the collision detection for the curved floor version has been updated. Instead of testing a grid of points beneath each sphere, we test a spiral of points radiating out from the center. Note that this tests the coordinates of the floor beneath the sphere, and then tests the distance between those points and the radius of the sphere. We also removed the indicator lines. Enjoy "FinalA.exe" (flat floor) and "FinalB.exe" (curved floor)!
Code and .exe's
The code for my program and all updated versions is located in public.