Transactions on Computer Science and Technology December 2014, Volume 3, Issue 4, PP.132-139
Implementation of Progressive Photon Mapping Parallel Rendering Based on CUDA Tianding Chen 1,2, Maoqian Li 1#, Qi Zhong 2 School of Information & Electronic Engineering, Zhejiang Gongshang University, Hangzhou 310018, China #
Email: limaoqian9267@163.com
Abstract It took a few hours to render high-quality images in complex scenes. So, it was a good choice using Graphics Processing Unit (GPU) accelerate the rendering process. We modified the implementation process of progressive photon algorithm, and let the algorithm runs entirely in the GPU by Compute Unified Device Architecture (CUDA) and ray tracing engine OptiX. So, we could take full advantage of the powerful parallel computing capabilities of GPU to accelerate the photon mapping implementation. Then we proposed the distributed rendering implementation of progressive photon mapping, while executing the improved progressive photon mapping implementation algorithms using multiple GPUs. The results show that the speedup increased to 5.7 after 1000 iterations rendering in six GPUs of distributed system, and it gets close to linear acceleration. Keywords: Progressive Photon Mapping; Parallel; Rendering; Compute Unified Device Architecture (CUDA); Graphic Processing Unit (GPU)
基于 CUDA 的渐进式光子映射并行渲染实现* 陈添丁 1,2，李茂前 1，钟琪 2 浙江工商大学 信息与电子工程学院，浙江 杭州 310018 摘 要：对于复杂场景的高质量图像渲染，可能需花费几个小时，而使用图形处理器（GPU）来加速渲染进程是一种很好 的选择。针对该问题，通过修改渐进式光子算法的实现过程，使得该算法能够通过统一设备计算架构（CUDA）和光线 追踪引擎 OptiX 完全运行在图像处理器（GPU）上；从而充分利用 GPU 强大的并行计算能力，加速光子映射的实现。并 提出了渐进式光子映射的分布式渲染实现方法，同时使用多个 GPU 高效率地执行改进的光子映射算法。实验结果证明了 采用分布式系统中 6 个 GPU 进行渲染，经过 1000 次迭代，加速比提高到 5.7，得到接近线性的加速。 关键词：渐进式光子映射；并行；渲染；统一设备计算架构；图像处理器
引言 一直以来，通过模拟光照行为来创建具有真实感的图形图像成为计算机图形学中最热门的话题，并且 基于物理模拟的相关全局光照（Global Illumination，GI）渲染技术也在不断发展[1]，众所周知的有辐射度方 法[2]、光线追踪方法[3]、光子映射方法[4]以及渐进式光子映射方法。 渐进式光子映射算法解决了光子映射算法中的内存限制问题且更适合于 GPU 中实现。随着 GPU 的快速 发展，可以利用其强大的并行与计算能力，使得渐进式光子映射在 GPU 上并行实现，以加速渲染速率。 Purcell 于 2003 年[5]提出了基于 GPU 的光子映射实现方法。他使用了基于网格的光子图算法，其中将光 子排序为恰当的单元格。由于当时在 GPU 上执行排序计算较慢，采用了模具布线方法引导光子到达最终目 的地。 *
国家自然科学基金项目（No.61172172） ，浙江省教育厅基金项目（Y201223500，Y201432227） ，浙江省自然科学基金项目 （LQ12F01005） - 132 http://www.ivypub.org/cst
Hachisuka[6]于 2008 年提出了渐进式光子映射，它解决了光子映射中内存限制问题。因为 GPU 通常相比 CPU 有较少的可用内存，这种方法是比较适合于 GPU 上实现的。 最近几年，出现了几种光子映射的实现方法，特别是 CUDA[7]发布后。Fleisz[8]使用 CUDA 实现了基于 GPU 的光子映射，并考虑了几种光子映射的实现方案。 Czuczor 等[9]使用 GPU 纹理内存来存储光子的撞击信息，并使用纹理过滤方法替代在 KD(K-Dimensional) 树基础上的相邻查找方法，而使用 CPU 来求取新的光子路径以及更新没有过滤过的光子图，但该方法的存 储以及搜索是很复杂的。 Zhou 等[10]提出了实时的 KD 树构建方法，并运行在 GPU 上。这种方法完全用广度优先的查找方法来构 建相关 KD 树节点，并充分地运用 GPU 硬件的并行计算性能，从而实时构建 KD 树。这为 GPU 光子映射算 法的实现提供了坚实的基础。 Wang 等[11]运用焦散与全局的光子图来存储光子。如果光子在与当前表面撞击之前的所有撞击都只经过 了镜面，则在焦散光子图中保存光子，可以直接估算这些光子的密度，其它光子都将保存在全局光子图中。 通过使用这种方法，它提高了光子不同类之间的独立性。 Knaus 和 Zwicker[12]提出了无记忆渐进式光子映射方法，它有效地解决了渐进式光子映射（Progressive Photon Mapping，PPM）中迭代之间的依赖关系。 Hachisuka 和 Wann Jensen[13]描述了基于 GPU 的并行渐进式光子映射实现，其中光子被随机地存储在哈 希表中，从而避免了任何类型列表的增加而造成方差的成本。 本文在以上研究的基础上，进一步研究基于 GPU 平台下渐进式光子映射分布式渲染实现。
渐进式光子映射在 CUDA 中的并行化实现
1
1.1 算法描述 1.1.1
光子半径与数量的更新
在本文中，采用新近的跟踪光子以更新像素辐射度估计。每个像素存储当前光子半径 R 、当前光子数 量 N 和累积功率 。初始时，令 N0 0 和 0 0 ，并将 R0 设置为相关场景的初始半径。 进行 i 次迭代的光子跟踪之后，并对于每个场景的撞击点 x ，找到距离 x 点半径 Ri 范围之内所有的光子。 假设这次迭代之前积累了 N i 个光子，则将刚才找到的 M 个新光子添加到 N i 中。注意，如果半径内没有光 子， M 可以是零。在某些受限的情况下，需要无穷小半径范围内无限的光子数量以得到正确的解决方案。 目的是减少半径 R 的同时增加光子数量 N ，当然所有增加的光子是在该半径范围内的。 假设 N i 更新后的值是 Ni 1 ，则它为， Ni 1 Ni M
（1）
是在辐射估计中控制 M 个光子分数的参数。如果光子映射的辐射估计是收敛的，为了得到正确的解 决方案，必须增加光子的数量。因此， 0 。此外，如果不想添加大于 M 的光子数量，可以使 (0,1) 。 近日，Kaplanyan 和 Dachsbacher[14]发现了缩小半径为 2 / 3 的渐近式最优方法，虽然 R0 的收敛速度选择 仍然很重要。 此外，还需要减少 Ri 的值。根据这样的假设，光子密度是在统一的半径范围内，文献[6]表明可以得到 Ri 1 的值
Ri 1 Ri
Ni M Ni M
（2）
由于平方根因子必须小于或等于 1， R 不能增加。在这点上，发现了新的 Ri 1 和 Ni 1 值，并确保了 N 增 加或保持不变的同时， R 减少或任何迭代都保持同一值。同时发现任何光子都在半径 R 范围内，即 M 0 ， - 133 http://www.ivypub.org/cst
但半径总是会减小。 1.1.2
辐射通量估计
估计 M 用于 M 个新光子的总非标准化通量，其给定为 M
M f r ( x, p )p
（3）
p 1
其中， x 是撞击点， 是光子的出射方向， p 是光子 p 的入射方向， r 是包含所有 N 个光子的球体半 径。 f r ( x, p ) 为方向 和 p 之间， x 点半径为 r 表面的双向反射函数。 p 是光子 p 的非标准化辐射 功率。从这个意义上来说非标准化意味着，在这个步骤中不通过发射光子的数目来划分，这是与常规光子 映射中的一个重要区别。 在任意迭代 i ，结合 i 和 M 可以得到 i 1 。需要把迭代之间半径 Ri 的减少考虑进去。通过假定球体 （半径与撞击点构成的）表面功率密度是均匀的，而功率的降低等价于面积的减少。因此，
i 1 ( i M ) 1.1.3
Ri21 Ri2
（4）
辐射度估计
前面的章节中已经描述了如何更新渐进式光子映射算法所需的统计数据。本节将介绍如何将这些数据 用于任意迭代 i 的辐射估计。辐射度估计是
Lˆ ( x ) f r ( x, ) L( x )cos d
1 N f r ( x, p ) p A p 1
i 1 2 Ri Nemitted ,i
（5）
其中， 表示球体表面， 是平面角度， 是光子的入射方向， p 是 p 的辐射功率， Nemitted ,i 是 i 次 迭代算法后从光源发出的光子总数。 Lˆ ( x ) 为 x 点外方向 的辐射率， L( x ) 为 x 点内方向 的辐射 率。 辐射率 L( x ) 随着 i 趋向无限而达到极限值：
i 1 2 i R Nemitted ,i i
L( x ) lim
（6）
辐射度估计与在常规光子映射中是一样的，除了通过 Nemitted ,i 将除法移到最后一步。每次迭代 Nemitted ,i 增加是必要的，所以确保所有迭代光子的发射同等重要。 Ri 和 i 值被存储在每个像素的数据结构中。 Nemitted ,i 是 i 次迭代算法后从光源发出的光子总数，因此
Nemitted ,i i Nemitted _ per _ iteration 。
1.1.4
新的渐进式光子映射
不好的是，渐进式光子映射（PPM）算法依赖于每个像素的局部统计数据（ Ri 和 N i ）的维护。这些值 必须从上一迭代传递到下一迭代，以防止各次迭代有任何可能性的并行化。由 Knaus 和 Zwicker[12]提出的渐 进式光子映射证明 PPM 可以不使用这些统计数据来执行。 他们采取了“概率方法”，研究每次算法迭代的误差 i 。使得 i 的方差通过一个因子而增加 Var( i 1 ) i 1 Var( i ) i - 134 http://www.ivypub.org/cst
（7）
展示了方差和平均误差的期望值， Var( i ) 和 E( i ) 都收敛到 0 。通过使用证明，迭代之间的方差与在估 计中使用的半径平方是成反比的， ri21 ri
2
Var( i ) i 1 Var( i +1 ) i
（8）
可以发现算法中每次迭代半径的序列。文献[12]表明新的半径减少方法等效于原始 PPM。由于这个新序 列，发现在任意迭代光子的数量是独立的，作者证实了半径减少的速率是独立的局部统计信息。因此，收 集统计信息不再需要了，这就简化了实现方法并降低了内存的需求。由于没有数据使得一次迭代进行进行 到下次迭代，这些迭代完全可以并行地运行。 新的无记忆 PPM 方法与图像之前的（随机的）版本进行了质量方面比较。视觉效果几乎是相同的，并 且没有任何噪声而产生的差异。这种新的固定半径减持计划提供了许多优势，本文采用了这种方法，从结 果可知它并没有明显的缺陷。 Knaus 和 Zwicker[12]指出了渐进式光子映射和常规光子映射之间的联系。渐进式光子映射是简单的常规 光子映射迭代执行，同时每次迭代的光子数量不变。在光子图辐射估计中使用的半径 Ri 序列是预先确定的， 由方程 8 给出。不需要在任何特定顺序中来执行这些迭代，但在这之前要估计并计算每次迭代 i 。 在渐进式光子映射辐射估计中，只有标准化结果的最后步骤不同于普通的光子映射。这个标准化占据 了任何迭代后发射的光子总数。很明显，这相当于所有辐射估计值的平均值。
1.2 算法的并行渲染实现 大多数现代的主板支持 2 或 3 个通过 PCI-Express 总线连接到系统的 GPU。利用系统上每个可用的 GPU 来加速渲染过程，这将是非常可取的。 1.2.1
使用多个 Nvidia OptiX GPU
OptiX 已经内置了对多 GPU 的支持，用户可以指定哪个设备应该被使用。OptiX 将安排可用 GPU 的发 射和分配负载。事实上，内核启动的细节对开发者是不可见的，没有低层的成本控制从而简化了开发。如 果启用了多个 GPU，缓冲区存储在主机上并在 GPU 之间共享。这将大大减缓任何多个 GPU 算法，它非常 依赖于读写缓冲区。该 PPM 算法使用光子缓冲区和加速结构。 此外，在 OptiX 中光线跟踪的启动是同步的，这阻碍了并行地启动多个发射。即使它们是异同步的， OptiX 不提供底层的控制来设置哪个设备将被使用。使用原始 CUDA 将会给我们带来必要的控制水平；然 而，放弃 OptiX 其它有用的功能将是一个重大的损失。 在 OptiX 中试图做单进程多 GPU 需要花费一些时间和精力。一种选择是做多线程，每个线程管理自己 的 OptiX 环境。然而，OptiX 线程是不安全的，所以这种方法是不可行的。 1.2.2
多分布式 GPU 渲染
下一个步骤是执行多进程分布式渲染。想法是每个 GPU 有一个单一的进程，并让多个进程使用套接字 进行通信。使用多 GPU 处理方法中，GPU 可以是相同系统的一部分，或者事实上它们可以是物理上分离的 节点。更进一步，分布式系统可以用来渲染 GPU 集群。 1.2.3
结构
可以将实现方法分成几个组成部分； 嵌入式引擎是一个支持即时 GPU 的渲染器版本。渲染引擎被嵌入在应用程序中，在这个意义上，没有 网络通信开销。 服务器响应来自客户端的请求，并在单个 GPU 中进行渲染。在多 GPU 系统也是一个 GPU 中运行一个 - 135 http://www.ivypub.org/cst
服务器进程。 客户端可以连接到多个网络上的服务器，并进行分布渲染过程。客户端有每个连接服务器的状态信息 图形用户界面和渲染图像预览。 这些不同的可执行文件有大量的共享功能，包括基于 OptiX 核心渲染器和部分用户界面。同时贯彻落实 渲染引擎和图形用户界面的共享库。QT[15]被广泛用于图形用户界面、多线程和进程间通信。文中使用的客 户端服务器间通信流程图如图 1 所示。 渲染服务器渲染器
渲染服务器
服务器 渲染请求
客户端
渲染结果数据包
渲染客户端
渲染服务器连接
客户端视窗
渲染结果接收器
图 1 客户端服务器间通信流程图
1.2.4
分布式渐进光子映射算法
在分布式渐进光子映射（PPM）中，可以得到所有迭代（ 0 , 1 ,..., k ）的平均值，其中每次迭代具有在辐 射度估计中指定的半径 Ri 。在该实现方法中运用的并行算法有许多优点； 迭代之间没有相关性，因此可以并行地渲染。 可以将几个迭代整合到一个单一包中，只要做一个适当的加权平均值计算。
实现中也出现了一些挑战； 客户端和服务器之间需要使用协议来沟通，以便执行渲染。 大量的数据会在实体之间进行传输。为了最大限度地提高性能，并保持每个 GPU 充分工作，网络延
迟将构成最大的挑战。 当用户移动摄像机或调整其它参数时，应尽快把这些变化考虑进去。
客户端可以连接到多个服务器进程，其中每个服务器在单 GPU 的控制下。在双 GPU 的一台计算机上， 2 个服务器进程启动后，并在指定的端口配置监听。客户端然后才可以连接到服务器。 当用户想要渲染图像时，客户端会传送渲染请求到所有连接的服务器。一个渲染请求包含必要的数据 来描述渲染任务：场景文件名、摄像机属性和图像的宽度和高度。该请求还包含迭代数目 N 和其相应 PPM 半径 Ri 。在一个单一的数据包中，为了后续的简化处理，该迭代总是连续的 j , j 1 ,..., j N 。可以使用 Qt 的数据流序列化和反序列化的数据网络传输进行操作。 当服务器接收到网络套接字中的渲染请求，它将执行请求中的每个迭代渲染程序，使用 Ri 为光子映射 半径。该数据包包含 N 次迭代。取这些渲染图像平均值，并返回结果渲染结果数据包。渲染结果数据包大 小是影像大小的浮点数 3 维数组再加上一些头字节。 当接收到一个渲染结果数据包后，客户端必须把这个数据包与其它合并，并更新渲染图像。为了确保 PPM 算法的正确性，对于任何迭代次数 i ，必须在光子收集中使用 R0 到 Ri 的半径序列。由于这是一个分布 式计算，结果很可能恢复无序状态。所以保持两个独立的缓存，前端和后台缓冲区，是必要的。 前缓冲区包含当前迭代 i 的渲染图像。后台缓冲区，从某种意义上说，代表了迭代次数大于 i 的计算时 - 136 http://www.ivypub.org/cst
间提前；等待与前缓冲区合并。每次收到渲染结果数据包的时候，最初都将它添加到后台缓冲区。一直保 持后台缓冲区排序迭代次数的数据包。将第一和第二两个相邻数据包进行比较，看看它们是否是邻元素 （包括连续迭代号码）。如果是这样，合并这两个数据包，并通过每个分组中的迭代次数进行加权平均。 最后，尝试合并前缓冲区和后台缓冲区中的第一个数据包。如果前缓冲区被更新，则该算法的迭代次数将 被转发，并且将刷新屏幕上的渲染图像。
实验结果与分析
2
2.1 实验环境 实验环境：操作系统为 Windows7 64 位；显卡为 Nvidia GTX 580；实验平台为 Visual Studio 2012， NVidia CUDA 和 OptiX SDK。
2.2 测试场景 在 2 个不同的室内场景中测试实现方案，场景如图 2 所示。
(a) 会议室
(b) 迪斯科厅
图 2 测试场景
场景的目的是为了演示全局照明效果；场景中光线到达的区域和角落，这是很难捕捉到的。后一个场 景包含了创造特殊体积效应的参与介质。不同场景突出了不同条件下的实现。表 1 包含了场景统计数据和参 数。 表 1 场景信息以及用于渲染图像的参数 场景 会议室 迪斯科厅
三角形数量 324000 70840
PPM半径 R0
分辨率
0.02 0.033
1280 720
1280 720
2.3 评估与分析 2.3.1
多重 GPU 渲染
本文的实现方法能够同时使用多个 GPU 执行渐进式光子映射算法，利用网络套接字实现了分布式方法。 首先，探讨同一系统中三个 Nvidia GeForce GTX 580 的性能。三个 GPU 同时运行时，应该将内存总线进行 压力测试。第三个 GPU 连接到一个较慢的 PCI-Express 2.0 插槽，并且还充当显示适配器功能。 实验中每次迭代发射 10242 个光子，分别进行 200 次和 1000 次迭代算法。单个 GPU 测试使用嵌入式引 擎渲染，而双路和三路 GPU 测量使用分布式引擎实现。表 2 包含了测量时间周期。表 3 是显示实现加速比 的表格。 由表 3 可知，在两个和三个 GPU 上，结果表明达到了接近线性的加速比。经过 200 次迭代后，分别达 到超过了 1.98 和 2.84 的加速比。经过 1000 次迭代，达到了资源更好的饱和度；使用两个 GPU 得到了 1.98 和 1.99 的加速比；使用三个 GPU 得到了 2.93 和 2.96 的加速比。由于三个 GPU 的 200 次迭代能快速执行， - 137 http://www.ivypub.org/cst
为了得到高效的速度，向服务器的首次渲染请求延时是轻微的，但是是很明显的延迟。由讨论可知，在同 一系统中使用三个 GPU，能够得到近似线性加速比。 表 2 多重 GPU 渲染性能 场景
会议室
迪斯科厅
经过200次迭代 迭代/秒 加速比 1.62 1.00 3.23 1.99 4.61 2.85 6.12 3.78 8.69 5.36 1.04 1.00 2.06 1.98 2.98 2.87 4.01 3.86 5.76 5.54
#GPUs 1 2 3 4 6 1 2 3 4 6
经过1000次迭代 迭代/秒 加速比 1.64 1.00 3.27 1.99 4.81 2.93 6.36 3.88 9.38 5.72 1.05 1.00 2.08 1.98 3.11 2.96 4.13 3.93 6.01 5.72
表 3 多重 GPU 系统的加速比 场景 会议室 迪斯科厅
2.3.2
1 GPU 1.000 1.000
经过200次迭代 2 GPUs 1.994 1.981
3 GPUs 2.846 2.865
1 GPU 1.000 1.000
经过1000次迭代 2 GPUs 1.994 1.981
3 GPUs 2.933 2.962
分布式渲染
本文提出的方法能使用 TCP/IP 将渲染进程分布到几台电脑上。本节将介绍并分析多 GPU 性能。使用并 连接三台电脑，有两个 GPU 是 Nvidia GeForce GTX 580，分别使用快速千兆交换机。两个 GPU 作为同一台 计算机上的客户端，所以应避免在这种情况下的网络传输。同时在另外的两台电脑上，开启四个服务器实 例，并使用 TCP/IP 将它们连接起来。 经过 200 和 1000 次迭代的测量时间控制，包括加速比于表 2 列出。表 4 呈现了 1000 次迭代以后的加速比。 表 2 和表 4 表明，并行使用六个 GPU 能够合理地得到接近理想的加速比。经过 200 次迭代后，6 个 GPU 可以提供 5.36 和 5.54 的加速比。经过 1000 次迭代，加速比提高到 5.7。由于测试中，6 个 GPU 的 200 次迭代是在大约 10-30 秒内执行的，还没有达到 GPU 的充分利用。 表 4 使用六个并行 GPU 的加速比 场景 会议室 迪斯科厅
1 GPU 1.000 1.000
2 GPUs 1.994 1.981
3 GPUs 2.933 2.962
4 GPUs 3.878 3.933
6GPUs 5.720 5.724
研究结果表明，采用分布式系统中的 6 个 GPU，能够得到接近线性加速比。因此可以得出，经过几百 到上万次的迭代，可以得到良好的加速比和多重 GPU 可加速简单场景的渲染。对于那些需要成千上万次迭 代的复杂场景的效率也接近完美。
3
结语 本文主要实现了基于 CUDA 的渐进式光子映射并行渲染。文中首先详细描述了算法的实现过程，光子
半径与数量的更新、辐射通量估计、辐射度估计以及新的渐进式光子映射。然后描述了算法的并行渲染实 现，包括渲染结构以及分布式渐进式光子映射算法。最后，使用该并行系统来渲染场景，包括多重 GPU 渲 染和分布式 GPU 渲染。实验结果表明，采用分布式系统中 6 个 GPU 进行渲染，得到了接近线性的加速，很 好地加速了场景的渲染。 - 138 http://www.ivypub.org/cst
实验中，由于采用的是多台电脑实现的多个 GPU 并行渲染，其算法可并行性一般，而为了处理多 GPU 的大量数据可以使用更复杂的负载平衡技术。例如，如果检测到延迟，调整每个分组的迭代次数以解决是 可行的。
REFERENCES [1]
Bin Zhu, Anbao Wang. The storage technology for GIS data realization[J]. Journal of Computers, 2011, 10(6): 2229-2236
[2]
A Doan, J F Naughton, and A Baid, et al. The case for a structured approach to managing unstructured data [EB/OL].[2011-1011].https://database.cs.wisc.edu/cidr/cidr2009/Paper_110.Pdf
[3]
Xiao Zhang, Xiaoyong Du, and Jinchuan Chen, et al. Managing a large shared bank of unstructured data by using free-table [C]// APWEB’10: Proceedings of the 2010 12th International Asia-Pacific Web Conference. Washington, DC:IEEE Computer Society, 2010: 441-446
[4]
R Vilaca, R Oliveira. Clouder: a flexible large scale decentralized object store: architecture overview [C]// WDDDM 2009: Proceeding of the Third Workshop on Dependable Distributed Data Management. New York: ACM, 2009, 25-28
[5]
T J Purcell, C Donner, Mike Cammarano, H W Jensen, and Pat Hanrahan. Photon mapping on programmable graphics hardware. In Proceedings of the ACM SIG- GRAPH/- EUROGRAPHICS conference on Graphics hardware, pages 41-50. Eurographics Association, 2003
[6]
T Hachisuka, S Ogaki, and H W Jensen. Progressive photon mapping. ACM Trans. Graph., 27-(5):130:1–130: 8, December 2008.
[7]
Nvidia Corporation. CUDA ToolKit HomePage. https: // developer. nvidia.com/cuda-toolkit, 2007.[Online; access- ed 08-June2013]
[8]
Martin Fleisz. Photon mapping on the gpu. Master’s Thesis, 2009
[9]
CZUCZOR S, SZIRMAY-KALOS L, SZÉCSI L, et al. Photon map gathering on the GPU [C]// EUROGR APHI- CS Symposium on Rendering. Oliver Deussen: [s.n.], 2005: 1-4
[10] ZHOU KUN, HOU QIMING, WANG RUI, et al. Real-time KD-tree construction on graphics hardware [J]. ACM Transactions on Graphics, 2008, 27(5): 1-11 [11] WANG RUI, ZHOU KUN, PAN MINGHAO, et al. An efficient GPU-based approach for interactive global illumination [J]. ACM Transactions on Graphics, 2009, 28(3): 1-8 [12] Claude Knaus and Matthias Zwicker. Progressive photon mapping: A probabilistic approach. ACM Trans. Graph., 30(3):25:125:13, May 2011 [13] Toshiya Hachisuka and Henrik Wann Jensen. Parallel progressive photon mapping on gpus. In ACM SIGGRAPH ASIA 2010 Sketches, page 54. ACM, 2010 [14] Anton S. Kaplanyan and Carsten Dachsbacher. Adaptive progressive photon mapping. ACM Trans. Graph., 32(2):16:1-16:13, April 2013 [15] Qt. The Qt framework. http://qt.digia.com/, 2013. [Online; accesse 29-April-2013]
- 139 http://www.ivypub.org/cst