# Implementing Many-Lights Rendering with IES-Based Lights
## 5 Results and Discussion  
Figures 3, 4c, 6 and 7 show some renderings obtained using the proposed approach on the two test scenes. The results seem to confirm the initial hypothesis: the original RSM technique can be extended to consider point lights, and the photometric data described in an IES file can be effectively integrated in the Many-Lights pipeline, not only in the direct  
Figure 5: Reflective Shadow Map components and IES light mask for the light source in Listing 1 in the _Crytek Sponza_ scene. Figure 4c shows the final render using these components. illumination component (as usually considered in real-time applications), also playing an active role in the indirect illumination computation. Figure 6: Rendering results of the _modified Cornell box_ using 100 (**left**) and 400 (**right**) samples per fragment. In the image on the left, noticeable rendering artifacts are present on the ceiling and on the front face of the taller box. The scene uses the light source described in Listing 1. Figure 7: A render of the _Crytek Sponza_ scene using the proposed technique. The scene uses the light source described in Listing 1. As in Figure 4c, the color bleeding effect is evident on the floor. The two test scenes present only diffuse surfaces; as a consequence, the main GI effect introduced by the Many-Lights technique is color bleeding. The presented results show an evident and realistic color bleeding effect: this is particularly noticeable on the solids and the _Stanford Lucy_ model in Figures 3 and 6, and on the floor in Figures 4c and 7. Regarding the computational performance, the implemented technique is more expensive than the original RSM method. This is obviously caused by the use of several cube maps for each light source in the scene, while the original method used standard 2D textures. As a consequence, our method requires six times more memory to store each RSM component, and an additional cube map for the IES mask. Moreover, all the cube maps require recomputation in the case of dynamic objects moving in the scene. However, the technique is view-independent in the case of static scenes: moving the camera does not require recomputing either the RSMs or the IES masks for light sources; it only requires an update of the camera G-buffers, and thus of what is rendered to the screen in the last pass of a standard deferred rendering pipeline. Given \(N\) IES lights and taking \(M\) samples from their RSMs, \(N\times M\) texture random accesses are needed to render a single fragment. In our experimental evaluation of the proposed technique, we found that the best visual results are obtained with 400 samples taken in each RSM for each fragment. Fewer samples lead to evident visual artifacts. Figure 6 shows a comparison of the results obtained on the _modified Cornell box_ scene using 100 and 400 samples per fragment. When using fewer samples, rendering artifacts are visible both on the ceiling and on the front face of the taller box. Performances in terms of achieved framerate on our test machine (Section 4.1) when setting the rendering resolution to \(800\times 800\) pixels are summarized in Tables 1 and 2. Analysis has been performed on both test scenes considering a single light source and 100 and 400 samples per fragment. The application maintains an interactive framerate with a maximum of 4 lights in the scene. We forced a full recomputation of the RSM buffers at each frame, simulating a dynamic scene. By using _NVIDIA Nsight_[39] to debug the state of the GPU, we discovered that computing indirect illumination is the most computationally expensive step. Indeed, repeatedly sampling the RSM cube map is an actual bottleneck. The application of an additional screenspace interpolation approach, as proposed in [8], could also be extremely advantageous in the proposed version of the RSM technique, offering relevant speedups while preserving a good final image quality.