Computer Graphics 266

Lab 3:

Implement a system to generate the motions of rigid bodies using physical principles. Include the effect of gravity and collision between objects. You may make some simple approximations for rotational dynamics. For collisions, reflect the velocity. Collision detection becomes easy if you consider a bounding sphere of the objects in the scene.

Description:

Collisions between balls are calculated using an impulse force. The advantage of using impulse is that it takes into account the mass and incoming velocity of colliding objects. For collisions between balls and walls, however, I simply reflect the velocity normal to the collision.

All physics-based calculations are carried out using "real-world" units (32 ft/sec*sec for acceleration due to gravity, and an appropriately sized room and appropriately weighted balls such that the results look fairly reasonable). These units are then converted to arbitrary Renderman Interface units for rendering.

Features of the system include:

• Acceleration due to gravity
• Collision detection and collision response among balls
• Collision detection and collision response between balls and walls
• Parametrization of ball attributes, i.e. initial velocity, size, mass, and motion start time
• Parametrization of simulation attributes, i.e. number of timesteps, timesteps per second, frame rate, and corversion factors between "real-world" units and Renderman Interface units

Examples:

Here are three versions of the same simulation, with balls of different sizes. I gave all the balls equal density, and then calculated mass based on that. As these simulations show, changing the radius of the ball changes the direction of contact as well as the mass of the ball. Both these factors affect the outcome of the collision.

Issues:

Implementing the system was fairly straightfoward, but tweaking it took quite a bit of guesswork in dealing with various issues:

1) Resting contact: I dodged the issue of resting contact by having my balls fall off the edge of a cliff as they approach the camera. But in my test simulations where the balls don't fall off the edge of a cliff, the balls acquire a very unnatural wobbling motion as they slow down, doing endlessly tiny bounces instead of coming to a rest.

2) Coefficient of restitution: I chose a very high coefficient of restitution because of the above-mentioned issues with resting contact. However, an unnaturally high coeffecient of restitution also produces unrealistic motion.

3) Strobing: BMRT doesn't do motion blur, so I had to live with the strobing effect of fast-moving objects. I tried to mitigate this by slowing down the animation a bit, but that carries the tradeoff of making the simulation less realistic.

4) Object interpenetration: I dodged the issue of having to back up the simulation in the event of object interpenetration simply by using very small timesteps. 90 timesteps per second with a framerate of 30 fps seemed to work fine for collision detection.

5) Numerical approximation: I used Euler's integration method to calculate position based on acceleration and velocity (multiplying the acceleration at the beginning of the timestep by delta t). Better approximation methods exist, but I used small enough timesteps that this didn't seem to affect the accuracy of the simulation.

6) Computational inefficiency: My system is not optimized. There are a total of eleven balls in the first animation on this page, and it runs for 8 seconds. This causes a noticable slowdown in calculation as compared with a shorter simulation of two or three balls. My collision detection algorithm is O(n^2), with each ball being compared with each other ball at each timestep regardless of where they are on-screen. However, since I wasn't trying to produce a system that works in realtime, this inefficiency doesn't really matter.