Assignment 2
Home Up Links Research Pictures

 

I used SWIFT++ in this assignment to perform collision detection.  The objects collide with each other and the 6 walls of their confine.  The reaction to collision is quite simple.  The distance between their centers of mass is calculated.  The component of the vector with the largest magnitude is selected as the primary direction.  If a colliding objects is heading towards the the object it is colliding with in the primary direction, then this component of its velocity is reversed.  This doesn't always look great (in particular when an object is moving along the x-axis and bumped by an object moving in the z-axis), but the assignment focused on the collision-detection.  There was another interesting effect, when the several objects approached each other they would often appear to slow down as their velocity components oscillated between positive and negative. 

Here is a screenshot.

There is some subtle bug in the rendering code that is messing up the z-ordering.  I tried a billion things and couldn't figure out what was wrong.

Three types of objects, spheres cube and triangles, are bouncing around in their cage.  Each has a random angular velocity (axis and angular speed) which never changes.  The angular motion is imperceptible for the spheres, but is applied regardless for the timing results that follow. They started at a random position and with a random velocity that remains constant until a collision occurs.

When running timing tests, all objects were rendered as points so that a constant rendering time could be maintained for all objects.  To be more accurate, rendering could be turned off entirely, but the amount of time spent rendering

Surprisingly, the complexity of the objects has little impact on overall performance.  In fact, the highly tessellated but somewhat smaller spheres performed (marginally) better then the cubes.  This indicates that the complexity of the geometry is not as important as the size (relative to the average separation distance).  The hierarchy is able to ignore most of the geometry because most actual objects are not examined.  The simplest object, the triangle performs almost identically to the cubes.  It is no larger in spatial extent than the cubes.  I wondered whether the triangles would perform poorly because their 2dimensional nature might make the prune-and-sweep run slower since the projections onto the axes can be arbitrarily small.  This could allow larger numbers of bounding box points to become out-of-order between frames.

Again, we see that the importance of object size.  When the cubes approach a size at which they cannot avoid contact the time increases extremely fast.  The same happens with the spheres and triangles.  Because they are area objects, triangles scale a bit better than similarly sized cubes.

 

Great savings can be had if the objects in your system are of nearly the same spatial extent and have aspect ratios close to unity.  Space can be subdivided uniformly with cells just larger than the largest object.  This guarantees that no object can overlap at most eight cells.  Furthermore, because the objects fill up most of a cell, there cannot be many objects overlapping each cell.  This greatly reduces average computational cost.  Furthermore, given the exact geometry it is likely that even the worst case scenario could be linear since each object needs to be checked with at most N other objects (provided you can find the worst configuration of objects).   We can classify each object by simply looking at which corner of the subdivision the center of mass is closest to and check the eight cells that meet there.

I implemented a prototype of this.  Rather than modify SWIFT++, I used it's deactivation feature and deactivated pairs of objects not in neighboring cells.  My algorithm for creating the subdivision was not particularly efficient and rendered SWIFT++'s prune and sweep redundant.  Therefore, to perform timing analysis I did not measure the time to create the subdivision and measured the normal prune and sweep.

 

I was surprised to find that adding this algorithm had almost no effect except at the upper high end where it took longer.  (The rest of the "modified" data points in the graph are hidden under the "original" ones.)  My best guess as to why is that the prune and sweep phase effectively takes advantage of the benefit this algorithm could give.

Code and Binary
The binary requires the three .tri files.  't' adds a triangle, 's' adds a sphere, and 'b' adds a cube.  The camera controls are standard GLVU.  The camera starts in the center of the cage, you probably want to zoom back in "drive" mode (select by right clicking or hit 'x') .