终于有点空搞搞renderer了

keyWord: Rendering,Ray trace,KD-Tree,3DDDA,Photon Mapping 先贴几个效果图吧:

汗，这图渲了我快二十分钟，就象Len3d当时渲染Final Gathering说的那样--“慢的要老命，这么幅破图....”。

先讲讲故事

本来半年前就想搞这个了，后来却一直忙这忙那，最近终于有点空闲搞搞渲染器。

不过由于急着出效果，架构方面没怎么考虑，结果总算在预定
的时间里写了个大概，这东西花了我一个多星期的业余时间了。算法并不难，但实现起来细节太多了。

再看看下面一个效果图，由于没有反射和折射，因此才用了5分钟：

再侃侃开发体会

场景组织方面，我开始的时候是使用3DDDA的，不过当时我写的有BUG,就干
脆不用了，干脆只是简单地使用AABB包围盒来组织好了，现在渲染速度那么慢，其中一个原因就在这了。
但耗费渲染时间的主要部分还是在于Photon的渲染，最后渲染阶段，要处理
的光子太多了，而且，我现在还并没有写Final gather呢，这可是更加慢的方式了。

对于渲染indirect lighting,我现在使用的是基于固定范围的光照密度评
估().为了能用更少的光子产生更柔和的效果，我把这区域设得比较大了。可
以从上图的那个cube的阴影看到，我这做法使光照的精度降低了许多。

自从加了eray渲染器开发群以来就一直很想参与写这东西，但觉得eray那样得
依赖于max才能运行，这对于算法的开发很不利，每次调试还得启动max，调
试出了问题也不好处理。我还是觉得，渲染器在算法开发阶段，做成完全独立
的程序最好。就象小老鼠说的那样，别轻易写max的其他插件（暂时就先写个
max导出插件好了）我这次就是这么搞的，模型的数据就从外面加载（之前写
了个max插件，模型从max导出）既然这是独立的程序，那物体的shade部分
都得自己写了，我这也只是简单地写了几种材质的shade而已。

用废话来总结一下
从测试效果来看，反射的渲染还是有瑕疵，可以明显地从最上面那个图看到。
final gather还是有必要用上。
效率来看，还有赖于以后写KD-Tree来组织场景。同时，对于加速indirect光照
渲染，还得需要写irradiance caching...

 

最新更新：

http://www.cnblogs.com/sixwater/archive/2010/06/15/1758840.html

相关链接：

http://www.cnblogs.com/sixwater/archive/2010/05/29/1747085.html