# A Corner-Highlighting Method for Ambient Occlusion
## 4 Results  
To test our algorithm, we rendered several scenes with the ambient occlusion post-processing pass on a custom C++ OpenGL engine. Any type of screen-space derived ambient occlusion variant is compatible with our algorithm. Among many promising ambient occlusion methods, we chose _AAO_ (Alchemy Ambient Occlusion), a widely used screen-space ambient occlusion method in many video game rendering engines. The _screen-space ambient occlusions_ with and without our highlighting method are both implemented to be compared. Our target was to achieve identical rendering results with the original pipeline but with improved rendering performance. Tests are done in Windows 10 PC with NVIDIA GeForce GTX 1070 graphics card and Intel Core i7-6700K 4.00 GHz CPU. We report the results of rendering three different scenes:  
* _Small Desert City_, outdoor alleyways with moderate occluded corners. * _Cartoon Temple Building_, inside of a temple filled with rectangular blocks. * _Corridor_, science-fiction themed corridor where concave vertices are not properly handled. Figure 5 shows the rendering results in the top-to-bottom order. For comparison, we excluded shared operations such as _bilateral blur_ and _lighting_. We sampled 4 nearby pixels per pixel for computing ambient occlusion without down-sampling. Each scene is  
rendered in static for 10 s with the screen resolution of 1080 \(\times\) 720. Table 1 summarizes our performance results of rendering scenes shown in Figure 5.  
The first row depicts the basic Phong shading rendering results to show the composition of the scene. The second row depicts the _highlighted corners_ generated by our algorithm for each scene. Areas highlighted in grey imply that they have a high potential \begin{table}
\begin{tabular}{c c c c} \hline \hline  & & **Prev. AAO** & **Our Method** \\ \hline \multirow{3}{*}{**Small Desert City**} & total triangles & 536,326 tri & 1,072,672 tri \\  & avg. rendering time & 1282 \(\upmu\)s & 782 \(\upmu\)s \\  & worst proc. time & 1309 \(\upmu\)s & 1086 \(\upmu\)s \\ \hline \multirow{3}{*}{**Cartoon Temple**} & total triangles & 17,678 tri & 35,356 tri \\  & avg. rendering time & 1098 \(\upmu\)s & 926 \(\upmu\)s \\  & worst proc. time & 1274 \(\upmu\)s & 1237 \(\upmu\)s \\ \hline \multirow{3}{*}{**Corridor**} & total triangles & 291,517 tri & 583,034 tri \\  & avg. rendering time & 1308 \(\upmu\)s & 631 \(\upmu\)s \\ \cline{1-1}  & worst proc. time & 1322 \(\upmu\)s & 923 \(\upmu\)s \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Performance comparison of the results. Figure 5: Comparison of ambient occlusion results in three distinct scenes. to be occluded. The third row shows the results of our method, which operated only on the highlighted areas from the previous row. The last row shows the results of the _original AO_ implementation. Bilateral blur was active for generating these images but was omitted when measuring the performance. For the scenes of _Small Desert City_ and _Cartoon Temple_, we can observe that corners are properly highlighted. These two scenes are composed of multiple flat walls, leaving only a portion of the place to be occluded. While the result ambient occlusion image generated with and without our algorithm is nearly identical, the one with our algorithm was 15% faster. Although of these positive results, there are drawbacks to our method as mentioned previously. The accuracy of our algorithm greatly lessens when concave vertices in the scene are not properly prepared in advance. Room model objects, for instance, are generally faced inwards, which eventually leads to generating several concave corners. Such case should be handled differently when integrating its normal vectors. The result of the last scene Corridor pinpoints this problem. Unlike the previous two, this scene was not prepared in advance and uniformly computed integrated normal vectors for all model objects, including the room.