Point-Based Approximate Color Bleeding

Alex Ehm

CSC 572 - Spring 2017

Final Project

What is Point-Based Approximate Color Bleeding?

Point-Based Approximate Color Bleeding is a global illumination technique, that uses a point cloud (surfels) to compute the global illumination part in a scene.

Point-Based Approximate Color Bleeding uses a two pass approach. In the first pass, the point cloud is generated from the scene. In the second pass the scene is rendered using the surfels (which are stored in an octree) to compute the color bleeding.

The original paper was published as a technical memo by Pixar and can be found here.

What are surfels?

Surfel stands for "surface element". Basically a surfel is a disc at a certain position. Each surfel has a position, radius, normal and radius. A surfel cloud is therefore a alternative way to represent surfaces. In Point-Based Approximate Color Bleeding surfels are used to store the direct illumination information that is created in the first pass.

The following images show the surfels of my cornell box scene. The picture on the left shows all surfels rendered as spheres, which makes it easier to see the single surfels. The right picture is a rendering of the actual surfels, and therefore shows a representation of the direct illumination of the scene.

Implementation

The implementation of this project was done in C++. As only raytracing is used, there was no need to use OpenGL.

First pass - surfel generation

To generate the surfels of the scene the whole scene is ray-traced in a coarse resolution, and for each ray-object intersection a surfel is created. Contrary to ray tracing for rendering it is important to make sure that also ray-object intersections of hidden objects or surfaces are taken into account and produce surfels, as these objects do also contribute to color bleeding. The surfels are then organized into an octree as spatial data structure.

Second pass - rendering with color bleeding

For the final rendering of the scene, the scene is again ray-traced. At each ray-object intersection the color bleeding is then computed. The original algorithm uses 3 different methods to compute the color-bleeding dependent on the distance of the surfels. Close surfels the surfels are ray-traced, mid-distance surfels are projected on a extremely coarse cube-map, and distant surfels are approximated as one surfel using spherical harmonics and them also projected onto the extremely coarse cube-map. In my implementation I used the ray-tracing approach for all surfels, as the implementation of the other both approaches was simply out of scope for this project. The surfels are ray-traced from the ray-object intersection point in a monte-carlo like manner.

Results

As it can be seen in the following images, the color bleeding works as it should. But as I only used ray-tracing for the computation of the surfel contribution to the color bleeding, and additionally did also not limit the distance a surfel can be from the current point to still contribute to color bleeding (distant surfels just contribute less), the program runs extremly slow.

It can easily be seen that the second rendering with more surfels already looks much smoother than the first one with less surfels. Given the small amount of surfels used for the rendering the color bleeding is of comparatively high quality. Rendering with more surfels would be possible and produce good results, but would take so much time with my current implementation that I did not render any images with higher surfel density.

Take aways

A good spatial data structure is crucial for complex and time intensive rendering applications like this. Although my program still runs very slow because of the previously described reasons, it runs a lot faster with the octree compared to without.
Thoroughly test your spatial data and the algorithms for building and querying it.
Spent some thought on design details for your spatial data structure. In my octree surfels that don't fit to any child because they overlap the boundaries, are kept in the parent node. By now I made the realization that it might have been better for the runtime if only leaf nodes actually hold surfels, and a pointer to the surfel would have just been stored in any nodes it overlaps.
Ray-tracing something like surfels adds up quickly on runtime, as for every ray-intersection with the scene, all surfels that are returned by the octree traversal need to be tested for each ray that is casted from the intersection point.

Future work

The most important future work would be to not only raytrace surfels, but also implement the 2 other approaches for mid-distance and distant surfels, as proposed in the paper.
At it's current state my program only supports planes and spheres, as that was necessary to create a cornell box. It could be fairly easy extended to load in obj-models, all that has to be done for that is the implementation of a ray-triangle intersection.
The ray-tracing is done in a single thread at the current state of the program. As the computation is done independently for each pixel, this could be multi-threaded.
Implementing support for transparency or actual reflection.