深入浅出LightCache
作者：凡子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的情况下的某场景的图像像素采样点确定情况:
http://img1.snren.com/UploadFile/2008-8/200882310403695073.jpg
请注意,VRay在确定图像像素采样点时,总是从图幅的左上角顶端第一个像素开始细分分布,这个方式是确定的,
上图大家可以看到,图像中有很多的小白点,这就是确定下来的要进行光线追踪的图像像素采样点,当Vray通过subdivis值确定这个以后,接下来就开始对这些像素进行反向光线追踪了,并且,很重要的一点是,Vray会一边反向光线追踪一边确定lightcache灯光缓冲数据结构本身,所谓灯光缓冲,其实就是若干个存储了最终计算好了照明结果的采样点,我们称之为LC Samplepoint缓冲采样点,请注意,并不是所有的图像像素采样点都能成为最终存储在lightcache光缓冲里的LC采样点,这也是VRay lightcache 最重要的特性,虽然VRay会将所有的图像像素采样点进行反向光线追踪,但这个像素本身的数据能否成为最终的LC samplepoint取决于下面这个决定性因素:
在以该采样点为圆心的指定半径空间球范围内是否有已经存在的LC采样点,如果没有,则满足条件,如果已经有了,则该像素的计算结果直接取用LC采样点的结果,且不再生成新LC采样点
下图为某场景的LC采样点生成情况:
http://img1.snren.com/UploadFile/2008-8/200882310415329573.jpg
以及采样点实际控制范围的情况:
http://img1.snren.com/UploadFile/2008-8/200882310424315367.jpg
如果我们把以上两张图合成,会得到这么一张有意思的图像:
http://img1.snren.com/UploadFile/2008-8/200882310432991761.jpg
我们从这张合成的图像中不难得到这样一个事实,
第一, 虽然Vray在一开始通过Subdivis确定了Subdivis的平方个(上例是10000个)图像像素采样点并进行反向光线追踪,但最后确定下来的实际灯光缓冲采样点仅1124个,也就是大家看到的每个色块色斑的中心点.
第二,色斑是如何形成的呢,因为其它的图像像素也进行了光线追踪,但VRay发现它们离这个中心点,也就是已经存在的LC采样点距离过近,所以直接被原LC采样点的计算结果所取代,所以产生很多同颜色的色块
所以我们发现LightCache之所以在大量灯光下仍保持高速计算性能缘于三点:
第一,LightCache使用反向光线追踪,仅追踪可见的图像像素,不可见像素不会追踪计算
第二,一开始就没有对所有像素进行反向光线追踪,而是对部分
第三,大量重复使用已有计算结果,并迭代逼近
那么,一个问题在于,Vray是如何控制每个采样点中心的控制作用范围的呢,也就是说,LC采样点之间的最小距离到底是如何决定的, 这就是SampleSize这个参数的功劳了,但是,SampleSize参数在不同的Scale类型下意义是不一样的,当Sale方式为Screen时,SampleSize的值是一个百分比,具体是实际出图尺寸的百分比,如果出图尺寸为640*480,并且Scale为screen方式,那么当Samplesize为1时,每个采样点的作用范围为百分之百的出图范围,即640*480精度,相当于在这个LC采样点为中心,物体表面上贴一张640*480精度的贴图的范围,如果为0.02,那就是出图尺寸的百分之二大小的精度范围
如果Scale方式为World类型,那么,SampleSize的单位将与MAX系统单位统一,这时你可以在场景中拉出一个小球来大概知道将来每个SampleSize的大小,并且这种方式下,所有的采样点作用范围都是恒定的,不会因为视图发生变化,它只依赖于场景本身,更适合于摄像机动画.
可以说SampleSize的作用范围机制使得每个最终灯光缓冲采样点之间保持一定的距离,但这并不意味着当SampleSize参数确定后,整个灯光缓冲的大小就实际确定下来了,只能说,所有采样点的分布结构确定下来了,LC采样点就是这样放置了,LC采样点数量仍然会跟随Subdivis的增加而少量增加,因为VRay允许采样点同一位置堆积,这个特性可能在后续版本中会有所改进.
下面是一张具体的光路示意图:
http://img1.snren.com/UploadFile/2008-8/20088231045396876.jpg
上图很好的说明了从Subdivis确定下图像像素采样点后,反向光线追踪其光路,并存入LightCache中的过程,其中B点就是一个存下的LC采样点,图中色斑中心都是LC采样点
接下来我们看一张图,看看哪种情况光线追踪计算后却不被存储:
http://img1.snren.com/UploadFile/2008-8/200882310454230805.jpg
上图我们可以看到,虽然A1图像采样点也进行了光线追踪,但它与表面接触的C点刚好离已存在的B点,一个先前计算并存诸过了的LC采样点太近,或者说处于它的SampleSize作用范围内,所以这时它不会被存储,并且直接用B点的计算结果取代给它
而从A2图像素样点反向追踪的光路与墙面的接触D点,离B点很远,不在其SampleSize范围内,所以它将成为一个新的LC采样点并存入灯光缓冲
好了,讲到这里,我们大概可以这样理解LC的过程,Vray首先确定图像中哪些像素要被进行反向光线追踪,这相当于告诉一群小蜜蜂去对哪些花采蜜,而一旦这些花被确定,那么成千上万的小蜜蜂就飞出去采集花蜜,但很可惜,这些花蜜并不都被保存下来,LightCache通过SampleSize告诉这个蜂巢有多大有多少个晶格以及这些晶格怎么样分布摆放着,这决定了有多少采来的蜜能被保存下来.
我想这个比喻应该是非常形象的说明了LC的计算和存储过程,可见,SampleSize相当于对已计算的密集数据再作一次采样,所以说LC算法是极大简化了运算的减益算法,质量损失是比较大的,和QMC对每像素的暴力分布式光线追踪相距很远,但事实上从效果上来讲这种精度却又可以靠用户把握,过高的Subdivis值和过高的SampleSize值搭配,将会使得你采集的大量有用数据没有足够的缓存采样点来存放,而太少的Subdivis和过小的SampleSize搭配会导致有很多缓存采样点得不到采集的数据而被强制性插值.
所以Subdivis和SampleSize之间的关系其实就是供求关系
当然,到此为止LC的过程还远没完全结束,
当LightCache形成以后,相当于Vray存下了一个空间LC采样点结构,这个结构和IRmap的结构是一样的,所以LC灯光缓冲同样可以用IRmapViewer查看
但光靠这几个采样点的计算结果无法渲染最后成图,于是还是老办法,插值
在LC灯光缓冲确定并生成后,接下来VRay即将进入渲染Rendering阶段,但在即将进入这一阶段之前,
它会用做一件事,那就是PreFilter 预过滤
Vray会使用PreFilter的过滤器对所有采样点形的的色斑值做一次类似photoshop滤镜的操作,越大的filterSize将会使得色斑边缘更模糊
完后就会提交给Rendering阶段了,在这一阶段,VRay根据lightCache面板中Filter所选类型来进行插值,如果选none,就是不插值处理,如果选取nearest,就会将最靠近的LC采样点进行互相插值融合,使得渲染结果尽可能平滑连续,
如果选fix方式,则也不插值,不过可以重定义每个LC采样点的固定着色大小,这个功能在观察LC采样点分布时很有用
那么讲到这里,我开始回答本文一开始提出的问题:
1.lightcache灯光缓冲生成的质量是否和渲图尺寸有关,计算灯光缓冲的时间是否和渲图尺寸有关?
如果在Subdivis值确定的情况下,图像从640*480增加到1024*768,那么相当于实际有更多像素需要被光线追踪来进行采样,而Subdivis的固定,所以实际上被反向光线追踪的像素数量就一定了,导致这种情况下质量将下降
当Subdivis和SampleSize值确定的情况下,增加和减少出图尺寸都不会改变lightcache本身的计算时间,但渲染大图花费的图像反走样时间肯定是比小图要多的
2.lightcache如果转变的摄像机视角,是否需要重新计算?
很明显,LightCache只计算可见像素,所以有以前不可见的像素变得可见时,重新计算是必要的
3.lightcache放在主引擎和次级引擎中有什么区别? 答案是没有区别
4.lightcache与DMC或QMC核心采样管理器之间有无联系 LightCache的PPT模式
PPT的全称也就是Progressive Path Tracing(过程化路径追踪)
在这种情况下,允许你用LightCache反向光线追踪特性计算场景中所有的效果,并且这个效果,你可以随时中断并使用其结果,
你觉得可以了随时可以停止计算,并使用当前的结果,或把它用于其它引擎的计算,
但有几点在PPT方式下需要注意:
1.PPT方式下不支持任何反走样,它只会使用自己内部特殊的反走样算法,也不支持任何反走样过滤器,所以当使用LC的PPT模式时,图像反走样可以关闭
2.避免使用任何接近255色值的颜色.
OK,讲到这里,有什么问题的欢迎提出 这个该好好学学啊
页:
[1]
