Download, compile, and run
This worked on both Ubuntu 9.04 and OS X 10.5.8
wget http://riskybacon.com/classes/cs531/assign4.3/assign4.3.tar.bz2
tar jxf assign4.3.tar.bz2
cd assign4.3/cpusort
make
./cpusort
cd ../peel
make
./peel
For both binaries, 'q' will quit the program. Click and drag the mouse to
change the camera position.
Timings
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