任何对LightCache有迷惑朋友就在此贴解决吧.doc

OK,任何对LightCache有迷惑的朋友就在此贴解决吧 提到lightcache方法,不得不说,这是个另人激动的创新,也是VRay之所以到今天大受欢迎的原因所在,这是由ChaosGroup小组专门为Vray开发的GI逼近解算方案,即使是以后VR1.6的实时渲染视图,都是依靠lightcache方法的深度优化,其主要就是优化了PPT部分.关于1.6的具体细节我不便透露过多,因为还有很多不确定性,但可以告诉大家的是高级体积shader在研发之中,但会否在1.6中出现仍是未知... 好了,切入正题LightCache方法一直为许多VR fans们喜爱,但同样也一直被她所困扰,今天我就在此文中给她做个外科手术,让大家知道,VRay的LC过程事实上先做什么后做什么: 我们带着这么几个问题,也可能是现在很多朋友对LightCache感到困扰的问题来开始下文的研究: 1.lightcache灯光缓冲生成的质量是否和渲图尺寸有关,计算灯光缓冲的时间是否和渲图尺寸有关? 2.lightcache如果转变的摄像机视角,是否需要重新计算? 3.lightcache放在主引擎和次级引擎中有什么区别? 4.lightcache和DMC或QMC核心采样管理器之间有关联吗,有什么关联? 5.什么是lightcache的PPT计算模式? 怎么应用它,有什么好处? 为了极大的简化大量灯光情况下光线追踪的计算量,LightCache采用的是逼近式反向光线追踪方法,之所以加个逼近式,是因为,LightCache方法并不对渲染图像的所有像素都进行反向光线追踪,它只对部分像素进行,这部分像素到底有多少,取决于lightCache面板里我们非常熟悉又头痛的Subdivis参数, 这个参数的作用在于,在一开始计算LC时告诉VRay,这幅图像上哪些像素要进行反向光线追踪,被确定为要进行反向光线追踪的像素,我这里称之为图像像素采样点,所以: Subdivis值的具体含义为:Subdivis的平方为实际反向光线追踪的图像采样点个数,假设subdivis值为1,则全幅图像只有一个像素将被确定为图像像素采样点而对其进行反向光线追踪,如果为2,则是4个像素将进行光线追踪 以下是subdivs为100的情况下的某场景的图像像素采样点确定情况 请注意,VRay在确定图像像素采样点时,总是从图幅的左上角顶端第一个像素开始细分分布,这个方式是确定的, 上图大家可以看到,图像中有很多的小白点,这就是确定下来的要进行光线追踪的图像像素采样点,当Vray通过subdivis值确定这个以后,接下来就开始对这些像素进行反向光线追踪了, 并且,很重要的一点是,Vray会一边反向光线追踪一边确定lightcache灯光缓冲数据结构本身,所谓灯光缓冲,其实就是若干个存储了最终计算好了照明结果的采样点,我们称之为LC Samplepoint缓冲采样点,请注意,并不是所有的图像像素采样点都能成为最终存储在lightcache光缓冲里的LC采样点,这也是VRay lightcache 最重要的特性,虽然VRay会将所有的图像像素采样点进行反向光线追踪,但这个像素本身的数据能否成为最终的LC samplepoint取决于下面这个决定性因素: 在以该采样点为圆心的指定半径空间球范围内是否有已经存在的LC采样点,如果没有,则满足条件,如果已经有了,则该像素的计算结果直接取用LC采样点的结果,且不再生成新LC采样点 下图为某场景的LC采样点生成情况: 我们从这张合成的图像中不难得到这样一个事实, 第一, 虽然Vray在一开始通过Subdivis确定了Subdivis的平方个(上例是10000个)图像像素采样点并进行反向光线追踪,但最后确定下来的实际灯光缓冲采样点仅1124个,也就是大家看到的每个色块色斑的中心点. 第二,色斑是如何形成的呢,因为其它的图像像素也进行了光线追踪,但VRay发现它们离这个中心点,也就是已经存在的LC采样点距离过近,所以直接被原LC采样点的计算结果所取代,所以产生很多同颜色的色块 所以我们发现LightCache之所以在大量灯光下仍保持高速计算性能缘于三点: 第一,LightCache使用反向光线追踪,仅追踪可见的图像像素,不可见像素不会追踪计算 第二,一开始就没有对所有像素进行反向光线追踪,而是对部分 第三,大量重复使用已有计算结果,并迭代逼近 那么,一个问题在于,Vray是如何控制每个采样点中心的控制作用范围的呢,也就是说,LC采样点之间的最小距离到底是如何决定的, 这就是SampleSize这个参数的功劳了,但是,SampleSize参数在不同的Scale类型下意义是不一样的,当Sale方式为Screen时,SampleSize的值是一个百分比,具体是实际出图尺寸的百分比,如果出图尺