P O I N T - B A S E D A M B I E N T O C C L U S I O NTNCG14 ADVANCED COMPUTER GRAPHICS PROGRAMMING

Dan Englesson

Spring, 2011

Abstract

A two pass method for calculating point-based ambient occlusion was implementedon the GPU using GLSL and OpenGL, in thecourse TNCG14 - Advanced Computer Graph-ics at Linkoping University. The program canload in wavefront-object files and render themwith point-based ambient occlusion. The re-sult is a good approximation of a ray-tracedambient occlusion render but it is renderedwith a greater speed than with a ray-tracedmethod. A point-based rendering visualiza-tion method called ”Affinely projected point-sprites” was implemented and compared withthe normal way of visualizing objects with tri-angles.

1 Introduction

This project was done in the course , TNCG14- Advanced Computer Graphics at LinkopingUniversity during spring 2011. The topic ofthe project was free to choose so the chosentopic for this project became Point-based Am-bient Occlusion because it is being more andmore used in the movie industry to simulate

global illumination and ambient occlusion inmovies with a greater speed than with nor-mal ray-tracing methods which due to thelong rendering times is rarely used in movie-productions for global illumination.

2 Background and RelatedWorks

Point-based global illumination and ambientocclusion is relatively new in the movie in-dustry. In 2005 a prototype implementationof point-based ambient occlusion was imple-mented by Rene Limberger at Sony Image-works for the movie Surf’s Up and also afull point-based global illumination methodwas shortly thereafter implemented at ILM byChristophe Hery and used in the productionof Pirates of the Caribbean: Dead Man’s Chest[1].

In the book GPU Gems 2 there is a paperon Dynamic Ambient Occlusion and IndirectLighting by Bunnell [2] on the GPU with CGshaders. It is an iterative approach and useshierarchical trees for speeding up the calcula-tions. The algorithm used in this project washeavily inspired by this paper but was insteadimplemented in OpenGL and GLSL shaders.Work of this sort has also been done on theCPU at Pixar [3] which approximates clustersof distant surfels with spherical harmonicsand for medium-distant surfels a similar diskapproximation method to Bunnell is used, andfor the closest surfels ray-tracing is used.

Some work has also been put on visualizingthe surfels and in this project Affinely pro-jected point sprites [4] was implemented. It

1

is a simple method and has some flaws whenviewed at a extreme angles but yields goodresults. A related approach is EWA (EllipticalWeighted Average) surface splatting[5] whichis by far the best method to use but it is awhole project on its own and was thereforenot included in this project.

3 Implementation

The program was written in OpenGL for load-ing the Wavefront objects and storing the ver-tices as point-clouds in textures, and then sentto GLSL for calculations on the GPU. Themethod used in this project for simulatingpoint-based ambient occlusion on the GPUis a two path method where in the first passa point-cloud is generated and in the secondpass the ambient occlusion is calculated. Twomethods for visualizing the point-data wasalso compared, it was visualized with trian-gles or with affinely projected point-sprites.The comparison between these two methodsfor visualization was not the main focus of thisproject and will therefor be briefly discussed.

3.1 Pass 1: Generating the point-cloud

There are several ways of converting a meshinto a point-cloud, for example Turks pointrepulsion algorithm [6] which can be used togenerate an even point-cloud on the surfaces,or to simply use the vertices’ positions whichis the method used in this project. The verticeswere chosen to be the point-cloud since theywere already there and their normals and areacould easily be calculated, see equation (1)and equation (2).

Nv = ||k

∑i

N f (i)|| (1)

As =13

p

∑i

12|e1i × e2i| (2)

Nv is the vertex normal which is the nor-malized sum of the neighboring face normalsN f (i) and As is the area of the surfel which is

one third of the sum of the neighboring faces’areas which is calculated as half the magni-tude of the unnormalized normal. Here e1iand e2i are two edges spanning up the i:thface.

Every vertex, or for now on surfel, will storethe following:

Listing 1: Surfel structure

s t r u c t S u r f e l {vec3 p o s i t i o n ;vec3 normal ;vec3 area ;( vec3 c o l o r ; / / f o r GI on ly . )

} ;

All surfel positions are stored in a Tex-ture Buffer, and their corresponding normaland area are stored into two separate TextureBuffers and sent to the fragment shader forambient occlusion calculation.

3.2 Pass 2: Ambient occlusion cal-culation

Ambient occlusion gives darker areas at partsof the object that is partly visible to the sur-roundings. It calculates the percentage of thehemisphere at the point that is not occludedby nearby surfaces, see figure 1.

Figure 1: Ambient occlusion visualiza-tion. The vectors occluded are seen asred arrows, and the vectors not occludedare seen as green.

Instead of spawning rays at a given pointp over the hemisphere as seen in figure 1, thepoint-based method projects all visible surfelsE(i) that lies above the hemisphere on to thesurfel R . Equation (3) describes the ambientocclusion calculation over almost the entirehemisphere except for surfels that lie near thehorizon of the same plane which the receiver,Rin figure 2, lies in.

2

os =k

∑i(1− 1√

AE,iπd2 + 1

)(NE,i · ri)(4∗ (NR · ri))

(3)The calculated occlusion value os for a given

surfel s is the sum of the all surfels that lieswithin the hemispheres’ view weighted ac-cording to their distance squared d2, the emit-ters area AE,i, and the angles between the nor-mal of the receiver and the direction r and theangle between the emitter and direction r, seefigure 2 for visual comparison.

Figure 2: Ambient occlusion calculationbetween two surfels, R is the receiver andE the emitter that cast shadow onto R.

During this process the bent normal can eas-ily be calculated by subtracting the directionsof the vectors that are occluded by a nearbysurface, so the bent normal will become thedirection to where it is least occluded, see fig-ure 3. The bent normal is very useful to simu-lating global illumination from surfels or en-vironment maps, which is not included in thisproject but it is fairly easy to go from point-based ambient occlusion to point-based globalillumination. To be able to simulate global illu-mination with point-clouds, the color of eachpoint/surfel needs to be stored as well.

Figure 3: Bent normal, the least occludeddirection. The blue arrow is the normal,and orange is the bent normal.

3.3 Over-occlusion compensation

The resulting ambient occlusion from equa-tion (3) is sometimes too dark in some areas,because when calculating the ambient occlu-sion all surfels are taken into account eventhose that are occluded by other surfels muchcloser. Therefore surfels receives more surfelsthan they should and the result is over-darkenareas, see figure 5(a) in section 4. There areseveral methods to reduce this problem, onemethod, which is an iterative approach, men-tioned in [2], is to do the same calculationsas before in equation (3) in a second pass butfor each surfel multiply it with the last ambi-ent occlusion result calculated for that specificsurfel. After some iterations the result willlook similar to a ray-traced ambient occlusionresult. The more passes the better approxi-mation. Another way is to scale the ambientocclusion value by a scale factor to make theambient occlusion brighter. However by scal-ing the ambient occlusion, cracks and tightcorners will also become much brighter whenscaled as well, which is not desirable. Twomethods that takes into account tight cornersand cracks which was mentioned in [4] wasto divide the hemisphere into n patches andeach patch can at most occlude 1/n. The sec-ond method, which was implemented, attenu-ates the occlusion from those surfels that aredistant , in other words, a maximum distancevalue is set so distant surfels does not con-tribute. A result of this method can be seen insection 4, figure 6.

3.4 Visualization of the point-cloud

Since the point-cloud was generated by thevertices of an object, one method was to sim-ply visualize the model with triangles and in-terpolate the ambient occlusion values storedat each vertex across the triangle-surfaces.This was the most straight forward way ofvisualizing it and therefore became the stan-dard visualization in this project. An othermethod implemented for comparison wasaffinely projected point sprites [4] which is

3

a splatting technique used to project the sur-fels onto the screen according to its normaland area. This was done by using OpenGL’spoint-sprites which gives view-spaced alignedsquares with their centers at its vertex posi-tion pi. A depth offset dz from the center pito a pixel (x,y) on the point-sprite, that is r · rin size, where r is the radius, can be calcu-lated with the linear equation in equation (4),where n = (nx, ny, nz)t is the vertex normaltransformed to camera-space.

dz = −nx

nzx−

ny

nzy (4)

To be able to render the point-splats as el-lipsoids one had to check if the pixel (x,y) laywithin the given radius r by calculating the 3Ddistance to the center,||(x, y, dz)|| ≤ r. If thepixel lay outside the radius it was killed withthe comand discard in GLSL. The result wassurfels that looked like they were followingthe curvature of the object according to the ver-tex normal, see figure 8 and figure 9 in section4 for a visual comparison of the point-spritesand affinely projected point-sprites.

Since the size of each point-sprite inOpenGL is defined according to the pixel sizeon the screen, the surfels looked like they be-came larger when zooming out from the object.By taking the position of the camera into ac-count the size of the surfels could stay trueto the object instead of growing when zoom-ing out. Equation (5) shows how to calculatethe size of the surfel that does not vary whenviewed from different distances.

ssize = Rhw

||c− p|| (5)

Where R is the radius of the surfel, hw is theheight of the window, c is the camera positionand p is the surfel position. Basically the de-nominator is the z-depth value of the surfel.

4 Results and Performance

Here follow some results of the point-cloudrenderer and performance benchmarks. Dif-ferent results of over-occlusion are presentedas well as a visual comparison between thepoint-sprites used in OpenGL, the affinely pro-jected point-sprites rendering technique andthe straightforward way of rendering trian-gles.

Figure 4: Rendered result of the point-based ambient occlusion method, ren-dered with triangles.

Figure 4 show a typical rendered framefrom the program, rendered with triangles.

4.1 Over-occlusion compensation

In figure 5(a), on the next page, the ambient oc-clusion is somewhat over-occluded. By reduc-ing the amount of occlusion by scaling it witha constant value smaller than 1, the ambientocclusion render gets brighter. It gives quickand good results at 40-60 percent of the origi-nal ambient occlusion value, see figure 5(c),(d).However it reduces the amount of occlusioneverywhere not taking into account cornersand cracks that should still stay dark. Com-pare especially the small pebble at the rightfoot in figure 5(c)(d) and figure 6 which isrendered by not taking into account distantsurfels. One can see that the pebble in figure 6has darker shadows beneath it than in figure 5.The shadows at the feet are more distinct infigure 6 than in figure 5 where they are moresoft.

4

(a) (b) (c) (d)

Figure 5: Different amount of ambient occlusion applied to the surfels. In (a) the amount ofambient occlusion is the raw ambient occlusion value that is obtained from equation (3), (b) is 80percent of (a), (c) is 60 percent of (a) and (d) is 40 percent of (a).

(a) (b)

Figure 6: over-occlusion reduction ap-plied by having a distance threshold. (a)distance threshold(th), th = 1.99 and (b)th = 0.99

A combination of both can be suitable aswell to lighten up dark areas such as cracksand corners that are too dark. Figure 11 showsthe hybrid method in (a), and in (b) the dis-tance attenuation method was only used. Thedistance was set to 2.0 in both images wherein (a) the ambient occlusion value was scaledby 0.5 and in (b) the ambient occlusion valuewas not scaled. Note the dark areas in (b) isbrighter in (a).

(a) (b)

Figure 7: (a) A hybrid of scaled occlusionand distance attenuation. In (b) only dis-tance attenuation with the same distanceas in (a).

4.2 Affinely projected point-sprites

By comparing the OpenGL point-sprites in fig-ure 9 with the Affinely projected point-spritesin figure 8 one can clearly see the differencein these two images. The Affinely projectedpoint-sprites visualizes the spheres much bet-ter than the ordinary point-sprite method inOpenGL, especially at the contours. Howeverthe images are taken from the same angle, butthe floor is missing in figure 8. This is dueto the fact that equation (4) is a parallel pro-jection, which does not take into account theangle between the splat normal and the view

5

Figure 8: Affinely projected point-sprites,note the roundness of the point-spritesand how they follow the spheres curva-ture.

ray and therefore the splats becomes too thinand will not be rendered when viewed at ex-treme angles.

Figure 9: OpenGL point-sprites, visualiz-ing two spheres and a ground-plane

In figure 10 the Rex model is visualized withthe affinly projected point-sprites method.With some additionally Phong- or Gouraud-shading the model would look quite good,because now the sprites does not blend witheach other so one can see distinct surfels.

In figure 11(a) the rex model is renderedwith the triangle method, and in figure 11(b)the model is rendered with affinely projectedpoint-sprites. However in figure 11(b) the sizeof the point-sprites had to be reduced in orderto be able to render. It is due to the fact thatthe size of point-sprites can not be too largebecause the a larger point-sprite the more fill-ing has to be done in the fragmentshader. Amore complex model can be rendered withpoint-sprites if the radius of each point-spriteis reduced. A more detailed investigation of

Figure 10: Affinely projected point-sprites, visualizing the REX model.

these two methods is performed in section 4.3,were benchmarks is made according to theradius, and number of vertices.

(a) (b)

Figure 11: (a) Rendered with triangles (b)Rendered with affinely projected point-sprites

4.3 Performance

Figure 12: A graph over how the framesper second is affected only by the point-sprite radius

In figure 12 one can see how the radius af-fects the frames per second as the radius of thesplats are increased. It shows that the frame

6

rate drops dramatically just by increasing theradius by a small number. This is a huge bot-tleneck, since the splats needs to be quite bigto fill the entire object. To reduce this problemone can have more points but a smaller radius.However by increasing the amount of verticesthe frames per second drops by itself a lot, seeTable 1. In Table 1 the radius stays the samebut the amount of vertices are increased as itis rendered with ambient occlusion on.

Table 1: A comparison between theamount of vertices rendered with trian-gles and with affinely projected point-sprites

Vertices Triangles point-sprites(fps) (fps)

81 200 200289 142 2001089 36 264225 6 2

16641 0.48 0.1

Figure 13: A graph over how the framesper second is affected by the amount ofvertices in the scenen.

Figure 13 is a plot of Table 1 and with Table 1combined it shows that the fps decreases dras-tically when increasing the amount of verticeswhen ambient occlusion is turned on. It alsoshow that rendering it with triangles gives alittle more fps, but they do follow each otherclosely. However when rendering with thepoint-sprites the radius needs to be bigger tocover all the area of the object. This will re-duce the fps even more when point-sprites areused. A comparison between rendering withtriangles and rendering with affinely projectedpoint-sprites that has a radius that cover the

entire surface is shown in Table 2 for differentamount of vertices.

Table 2: A comparison between the surfelradius and the amount of vertices ren-dered with triangles and with affinelyprojected point-sprites

Vertices Triangles point-sprites radius(fps) (fps)

81 200 30 0.46289 142 7.3 0.241089 36 1.7 0.124225 6 0.37 0.06

16641 0.48 0.1 0.03

Table 2 clearly states that the affinely pro-jected point-sprites can not be compared tothe triangle method since the difference inframes per second has a mean difference valueof about 69 frames per second, which is quitea lot.

4.4 Comparison between my ren-derer Iris, and Blender 3D’s ren-derer

(a) (b)

Figure 14: (a) Rendered with Iris, 11s (b)Blender internal with ray-traced ambientocclusion, 20s

The open-source program Blender 3D hasalso implemented point-based ambient occlu-sion and has as well ray-traced ambient occlu-

7

sion. The test was performed on a ASUS G53Swith a four core Intel i5 processor and GeforceGTX 460M as graphic-card. In figure 14(a) theviking model was rendered with Iris, and (b)was rendered with Blenders’ ray-traced inter-nal renderer with 16 samples. The viking in (a)took 11 seconds to render and (b) took 20 sec-onds to render without any anti-aliasing foronly ambient-occlusion comparison. Blendersinternal renderer works only on CPU, but it isthreaded. Figure 14(a) approximates the ray-tracing method quite well, but can be tweakedeven further to resemble (b).

Table 3: A comparison between the myrender Iris, and blender’s internal ren-derer that both has ray-traced and point-based ambient occlusion.

Iris Blender Blenderpoint-based ray-traced point-based

1pass/2pass11s 20s 10s/40s

Table 3 shows the time it took to renderthe viking with ambient occlusion in Iris andBlender internal with ray-tracing and withpoint-based ambient occlusion. One sees thatthe blender renderer with one pass of point-based ambient occlusion is faster than the onerendered with Iris and is still computed on theCPU and not with the GPU. Probably or mostcertainly an octree data structure is imple-mented in Blender to reduce the calculationsfrom n2 to nlog(n) which gives a huge differ-ence in computational time, see figure 15.

Figure 15: A graph over the computa-tional time it takes for a n2, seen in red,and a nlog(n) system, seen in blue.

5 Conclusion and Futurework

The point-based ambient occlusion approachapproximates a ray-traced method quite welland at a greater speed than a ray-tracedmethod, see figure 14 and Table 3. Al-though the rendering time is compared with athreaded ray-traced renderer on the CPU withthis rendering method on the GPU, conclu-sions can still be drawn that the this methodstill renders faster than the threaded ray-traced method on CPU with an octree datastructure, which means that it would outper-form the ray-tracing method if an octree datastructure was implemented. Creating an oc-tree data structure for all surfels would be themost significant speedup which will reducethe calculations from n2 to nlog(n) and there-fore the most important part to implementnext in the future. An other performance boostwould be to implement Vertex-buffer objects(VBO) so it is directly uploaded to the VRAM.Since the size of the surfels when renderingwith affinely projected point-sprites is a bigbottleneck when it comes to performance, seefigure 12, the best idea would be to increasethe amount of surfels an reduce the radius tocover the entire object, the ratio in fps betweenthe triangle visualization and the point-basedis reduced when the radius gets smaller andthe amount of vertices increases, see Table 2.

Two more over-occlusion reduction meth-ods would also be good to implement, theiterative shadow reduction algorithm and thepatch method to complete the list of over-occlusion reduction methods. They seems towork a bit better than the ones implemented,but takes longer time to calculate.

Lastly one would implement global illumi-nation but one then have to bake/store a point-cloud with direct illuminations, and there-fore a color component needs to be added tothe surfel structure. The direct illuminationmethod needs to be written as well. It is quitea little step to go from point-based ambientocclusion to point-based global illuminationbut one has to stop somewhere and thereforeit was decided to not implement it for now.

8

References

[1] Per H. Christensen. Point-based globalillumination for movie production. Sig-graph 2010 course: Global illuminationacross industries, Pixar Animation Stu-dios.

[2] Michael Bunnell. Dynamic ambient occlu-sion and indirect lighting. GPU Gems 2,Chapter 14, 2005.

[3] Per H. Christensen. Point-based approx-imate color bleeding. Pixar technicalmemo, Pixar Animation Studios.

[4] Markus Gross. Point-based Graphics. Mor-gan Kauffmann publishers, 2007.

[5] M.Paulin G. Guennebaud. Efficient screenspace approach for hardware acceleratedsurfel rendering. Technical report, CNRS-IRIT, Universit Paul Sabatier, Toulous,France.

[6] Greg Turk. Generating textures on arbri-trary surfaces using reaction-diffusion.Technical report, University of North Car-olina at Chapel Hill.

9