Friday, October 23, 2009

Assignment 4.3

Download, compile, and run

This worked on both Ubuntu 9.04 and OS X 10.5.8

tar jxf assign4.3.tar.bz2
cd assign4.3/cpusort
cd ../peel

For both binaries, 'q' will quit the program. Click and drag the mouse to
change the camera position.


In all cases, 4096 particles were used, screen size was 1280x720:
8 layer depth peel GPU / CPU particle system Depth sort on CPU Frames per second>
Yes GPU No 63
No GPU No 348
No CPU Yes 377

So, something has happened that has slowed down the GPU version. Previously I was seeing large speedups. For 4096 particles it was at least 3 times faster. Running traces on the code show a lot of time being spent in the driver. At first I suspected that the branching in the point sprite fragment shader for the depth peeling, which also happens in the non-depth peeling version migh have been slowing things down, but actual impace was about 14 frames per second, which doesn't explain the large discrepancy in speed that I'm seeing when compared to the previous assignment.

Screen shots

Depth sorted on the CPU:

The depth peeled version looks darker than the non-depth peeled and CPU sorted versions:

In all cases, notice how the hotter particles, the redder particles, are closer to the camera and occlude the white particles which are farther away.

Part one of the assignment is to depth sort the particles on the CPU and render them in the correct order. This is fairly simple since C++ has a sort() function and all that is required of the programmer is to implement operator<. I computed the depth a single time using a dot product to project the vector from the camera to the particle onto the vector from the camera to the depth plane.

Then that list was sorted and the particles were rendered in the new order:

Notice how the "hot" particles, which are closer to the camera, are always in front of the white particles. There are some occasional problems with roundoff and the render order is wrong. Here's an example of the render order being backwards:

This was the result of the first attempt. The depth order was smallest to largest, which means that closer particles were rendered first. Since I'm using back-to-front rendering, this didn't work out so well.

No comments:

Post a Comment