• 一步一步实现基于GPU的pathtracer(三):path tracing 简述


      全局光照这个名词在计算机图形学里已经不算一个新名词了,现在一提到拟真度,很多人基本上都会去想到全局光照,这个名词上世纪七八十年代就有了,好像是由一个叫Jim Kajiya的大神在他那篇已经被引用了不知道多少次的论文里《The Rendering Equation》里提出来的,现在很多全局光照算法基本上都是由这论文里面的一个公式推导出来的,可知其厉害之处了,其实主要思想很简单。

      但是说到全局光照,其实就是对自然界的光子在场景中的实际行为进行模拟,把模拟的结果呈现给我们而已,但是模拟的话就得考虑一个效率的问题。。。每秒钟射入人眼的光子就有上亿个,我们不能把上亿个光子的路径都画出来,那太浪费时间了,所以研究者们必须找到一个简化的方法,在不过于降低一张静帧图像质量的同时,把用于渲染该图像的所需时间降到最小,这里就牵涉到性能和拟真度这二者之间的权衡了。既然模拟上亿个光子没必要,考虑到最最简单的光路可逆,如果有一束光,从光源处不远万里,经过各种折射反射等过程射入到了我们的眼睛里,那么我们也可以假想是有一束“光”从我们的眼睛里射出,经过同样但方向相反的路径,最终回到光源处。这就是前文提到的逆向光线追踪,在这种方法下,我们就没必要模拟每个从光源处射出的光子了,直接从屏幕出射光线,不过这里的“光线”被称为“采样光线”更为恰当一些,毕竟是我们通过一束假想的光线,向场景进行采样,采样的结果就是屏幕中这个位置对应像素的颜色。对于一个1920*1080的2k屏,每帧就要发射1920*1080 = 2073600条光线,最终产生一幅完整的图像,但是这仅是该场景在这一时刻的一个成像估计,为啥叫估计?因为单帧的每一个像素的颜色并不能代表正确结果,光线漫布场景时是充满不确定性的,即便是场景中一个确定的位置,确定的时刻,连续生成的多帧图像都是不同的,这些帧都可称为这个场景在这个时刻这个位置的成像估计,但是把同一处像素的一堆估计值平均一下,平均结果就更能贴近理论值,这就跟概率论里的“多个随机变量的平均值,其方差会随着随机变量个数的增加而下降”的道理是一样的,那么多少个估计值就够了呢?答案是:只要像素颜色在连续n帧内稳定下来了,没有变化,就够了。n取的越大,相当于判定一个像素颜色收敛的条件就越严格,一般取100就好,严格的话可以取500,一帧中已收敛的像素占整个帧像素的百分比可以作为衡量整张静帧图像质量的一个参量。

      其实上面的一段话,就已经把path tracing的思想说出来了,path就是指的采样光线的路径,tracing就是我们要跟踪这条采样光线,看它在场景里面都发生了什么动作(反射,折射等等),并把这些动作都记录下来,最后算出一个颜色出来,整个算法其实就已经完成了。但是有一些难点在里面:

      1)如何跟踪?

      2)怎么记录光线与场景的交互?

      3)最终像素的颜色怎么算?

      4)“多个随机变量的平均值,其方差会随着随机变量个数的增加而下降”,但是如何让下降速率变得更快?(更快的下降速率意味着单像素收敛的速度越快,所需迭代次数越少,成像速度越快,实时性越好。)

      5)一些还没注意到的其它难点。。。

      即便有这些难点存在,路径追踪算法也算是全局光照诸多算法中一个比较简单的算法了,因为它原始暴力。。。但是,上述几个问题的不同解决方案,实际代表着不同的渲染风格,这也是计算机图形学的魅力所在。读者也可以试着用截然不同的处理手段,构建出一个类似卡通风格样式的非真实风格渲染,自由度极高,取决于您们的想象。

      (PS:如果读者们有兴趣,也有耐心等我更完的话,如果不出意外,应该可以得到如下的渲染结果,也算是一个渲染成品预览,这里就先贴出来供大家欣赏~)

     

     

  • 相关阅读:
    客商支付明细SQL_billdate
    两张表判断赋值,都是NULL惹的祸…
    DataGridView使用初步
    在SQL Server 2005中启用“SQL Server”身份验证
    .Net学习笔记——细节问题
    C#调用带返回值的存储过程
    利用ASP.NET一般处理程序动态生成Web图像
    Windows Forms数据绑定技术
    C#中产生SQL语句的几种方式
    风讯dotNETCMS源码分析—数据存取篇
  • 原文地址:https://www.cnblogs.com/time-flow1024/p/9974702.html
Copyright © 2020-2023  润新知