博客园_String Of Brilliant Blue

Photoshop DDS转化插件的一些问题

2012-03-28T09:38:00Z

最近被老外提NORMAL效果不够好，建议我们使用DXT5来压缩NORMAL，而不是DXT1，我很纳闷，如果不是用DXT5NM，DXT1和DXT5效果应该是一样的才对，难道他指BC5，但BC5支持也还不广泛。后来还特地将原始TGA NORMAL分别压成DXT1和DXT5对比了下，确实DXT5比DXT1好很多，真奇怪，都用的RGB来存储XYZ，怎么会有差别了，当时也没多想，后来有空我测试了下，发现PS插件原来是这样压缩DXT1和DXT5的，如果原始图含RGBA 4个通道，你选择DXT1 WITH 1BIT ALPHA将它当作带ALPHA压缩，这样4色中有1色会被设置成完全无用的黑色，所以如果使用PS DXT PLUGIN存储DXT1时，如果没有ALPHA需求，一定将ALPHA通道给删了。后来只存储RGB 3通道的原图，则DXT1和DXT5效果完全一样。如果追求比较好的效果只能使用DXT5NM，就是将X分量存于DXT5独立压缩的A通道上，而将Y分量存储在有6bit精度的G通道上，同时将RB设置为相同值避免co-compression artifacts，如果是DX10可以考虑使用高精度，且体积小的BC5压缩方式，就是ATI的3Dc，另外还有个trick，我们即可用DXT1存也可以用DXT5存，可以保证shader代码不用变。如果存DXT1可以将X存入R通道，而Y存入G通道，不要ALPHA；如果存成DXT5格式，则将X存入ALPHA，Y存进G通道，且将R通道设置为1，这样shader中的解压代码都是：

normal.x = R * Alpha;

normal.y = G;

normal.z = sqrt(1 - x^2 - y ^2);

本文链接

对scheme的一些理解（3）

2012-02-17T08:19:00Z

断断续续读到SICP第三章，觉得scheme有点入门了，不过长久不练习，脑子又不能适应函数式编程模式了，觉得3.17、3.18、3.19还比较有意思，贴个自己的解题思路吧。

3.17

(define (count-unique-pair x)
(let ((db (cons 0 0)))
    (define (count-pair x)
      (define (add-unique-pair x db1)
(define (add-record db0 x)
   (set-car! db0 x)
   (set-cdr! db0 (cons 0 0))
   x)
(define (find-record x db0)
   (if (not (pair? (car db0)))
       (add-record db0 x)
       (if (eq? x (car db0))
    '()
    (find-record x (cdr db0)))))
(find-record x db1))
      (if (not (pair? x))
   0
   (if (null? (add-unique-pair x db))
       0
       (+ (count-pair (car x))
   (count-pair (cdr x))
   1))))
    (count-pair x)))

(define xx '(a b))
(define z1 (cons xx xx))
(define z2 (cons '(a b) '(a b)))
(count-unique-pair z1)

实现比较丑陋，基本还是过程式编程，使用了一个db存储已经遍历过的pair，可以对付带环的表，而且只要此pair已经遍历过，则其子pair也不在遍历了。相比一下纯函数式写法，这种方式还是比较清晰且容易理解的，不过存在内存竞争问题，不能并行运行。

3.18

此题简化了一些，不用考虑car的环，使用3.17的存储做法就OK了。

3.19

这个需要个小trick，要空间常量，意味着不能存储已遍历的pair指针，那我就用时间换空间吧，使用两个指针，A指针一次步进1个pair，B指针一次步进2个pair，如果存在环，B指针会再次追上A指针，每次步进判断指针是否相等就可以知道是否带环了：）

本文链接

对SCHEME的一些理解（2）

2011-12-04T10:18:00Z

平时抽空看看SICP，主要是为了理解一些UNIX设计问题，另外也能揣摩最早一批计算机黑客的技术发展历程，UNIX将一切都是文件，一切最好都用文本的思想全面贯彻到系统设计中，想要领悟其哲学，必定得掌握最接近机器模型的C语言和最强文本处理能力的LISP，再说，一代UNIX黑客几乎都是LISP黑客（主要是MIT人工智能实验室中的那群人），UNIX也是其最主要的两位作者将经验主义和理论主义完美结合的典范，个人觉得Ken Thompson设计的UTF-8编码就有浓重的经验主义意味，也透露出一些无厘头的搞怪气氛，可能是又一次对KISS原则的贯彻吧。《UNIX编程艺术》和《黑客和画家》这两本具有浓厚技术黑客文化意味的书籍都有指出，程序员不是科学家，更像创作者，用现有的技术发明的新的创意，所以很有可能对于程序员来说，经验甚至比科学理论基础更重要。
言归正传，我在做SICP习题时，会拿一些我觉得比较有启发意义的题目做深入点的分析，给自己留个笔记（如上篇对习题2.6的分析）。现在来看习题2.18（我看书比较慢），这道题不算很难，但我觉得它着重点出了前递归和后递归的差别（没专门学过算法，不知道怎么描述），要打印题目要求的样式，list必须是前数据后pair模式，就是(car list)返回数据，(cdr list）返回还是个list，我看了下SICP之前都是用的前递归模式，所以我第一次写了这样一个习惯性的答案：
(define clist
(cons 21
(cons 22
       (cons 23
      (cons 24
     (cons 25 ()
    ))))))
(define (reverse x)
(if (null? (cdr x))
      (car x)
      (cons (reverse (cdr x))
         (car x))))
打印结果为：
((((25 . 24) . 23) . 22) . 21)

数字是倒过来了，可惜用的数据结构不对，这个打印结果表示成scheme语法如下：
(cons (cons (cons (cons 25 24) 23) 22) 21)
和想要的模式正好相反，(car list)返回的是list，而(cdr list)返回的是数字。造成这个结果的主要原因是reverse是前递归式的，也就是说递归展开后cons的操作是从前向后顺序计算的，我们需要将list的所有数据car出来，然后从后向前进行cons操作，也就是说cons操作要先于递归展开，有一种方法可以做到这点，就是将cons包含reverse的模式，改为reverse包含cons，将cons结果作为参数传递给reverse，这样就能在递归展开前进行cons操作了，修改后的reverse如下：
(define (reverse-1 x part)
    (if (null? (cdr x))
part
(reverse-1 (cdr x)
   (cons (car x) part)
   )))
写的好看点：
(define (reverse k)
(define null ())
(define (reverse-1 x part)
    (if (null? (cdr x))
part
(reverse-1 (cdr x)
   (cons (car x) part)
   )))
(reverse-1 k null))
总结一下，如果要在递归完成的同时就完全所有操作，就将要的进行的操作和判断条件通过参数传入函数，如果要在递归收敛时进行相关操作，就将递归函数作为参数传递给操作。

本文链接

对SCHEME的一些理解（1）

2011-11-28T08:37:00Z

最近抽空阅读SICP，并重温《黑客帝国》这个电影给了我在计算机程序设计上有了一些灵感的启发，在正式谈论SICP之前我想先对scheme及其在程序设计语言中的地位作个简单解释，LISP是一门非常古老的语言，据说仅FORTRAN比其老迈，在经历多年落寞之后LISP突然焕发光彩，新近的流行语言不断从中吸取养分，茁壮成长，比如C#加入LAMBDA表达式，JS的闭包，垃圾回收等，为什么LISP在分支方言众多，而且没有组织统一维护的不利状况下能如此潇洒得意。现在将自己的一些理解写下笔记，方便后面温习查询。

我喜欢scheme，因为他小且纯粹，我不指望能直接用LISP做一些现实开发，只希望靠它开启我的思维，很多人之所以觉得LISP入门极难，或者SICP这本书起点太高，只是因为我们基础太差，相信如果我们之前有离散数学、数理逻辑的基础，看起来必定轻车熟路，因为相比计算机编程语言，LISP更像数学，它比C/C++更为基础和原始，就如donald e.knuth所言，计算机科学只不过是数学的一层漂亮外衣，没有离散数学、组合数学、概率论、抽象代数、基础微积分等基础数学知识，而直接阅读《计算机程序设计艺术》，不但异常艰难，而且收效甚微，所以在看这套计算机科学经典之前，最好先看看作者的另一本书《具体数学》，这是题外话，现在我证明给你看为什么lisp比C更为原始，夸张一点说：更接近真理本质。

打个不太恰当的比喻吧，你觉得1米/秒和1千克哪个大？你觉得数字1和+运算符有什么关系？你可能会说，你不是白痴吧，两个完全不同的东西，你怎能拿来类比，我想说的是，不要和"matrix"的奴隶一样，要学"neo"尽可能看透这个世界，很多人都相信真理是简单的，我也相信。几百年前没有人会觉得我们和植物有什么相同，而现在我们知道了，其实我们很像，都是由DNA/RNA传递遗传信息，都由细胞构成；几十年前没有人觉得我们和水有什么相同，现在我们知道了，其实我们都是由有限的几种元素组成。爱因斯坦发明了质能方程统一能量和质量，质量和能量其实可能只是一种事物的不同表现，不要被一切美丽的外表所迷惑，借用《黑客帝国》中的台词，何为真实？你所看到的？你所嗅到的？这些只不过是你大脑的反应。而现在的一切知识模型很可能在未来都会慢慢推翻，直到找到真理。

这里有一个可观察和可测量的概念，就如牛顿的万有引力，牛顿不知道万有引力到底是什么，他只是找到了它的作用规律，在没有找到真理之前，所有知识都只是事物的近似抽象模型，很多我们习以为常的概念却不是那么显而易见，比如：数字‘0’到底是什么，如何严格定义？你别告诉我一个圈就是个零，我也不清楚，但我知道这个问题不是那么显而易见，比如如果一个“东西”它和任何其他东西的积是它本身，它就是零，那么只要一个东西满足这个约束条件那他就是“0”，正好说明SICP第二章关于序对的阐释，不管底下如何组织序对，我只需要一个可以生成序对、两个取出前后元素的方法就行，SICP展示为了完全用过程表示数据的方式，让人大吃一惊，我们关心的是可以真正触摸产生效果的接口，一切无法观察的东西对我们来说都是没有意义的（见“看不见的龙”小故事），这个世界充满着一个规律，世界上所有物体都是透过其可以对外界产生作用的接口让外在得以察觉认识，我们知道的只是这些接口，而内部的真理却无法窥见。

可以言归正传了，看看SICP习题2.6，整个SCHEME建立在唯一一条规则上：lambda演算。发明者是著名数理逻辑学家alonzo church，已经证明了lambda演算是图灵完全的，所以一定程度上讲基于lambda演算的scheme和基于机器模型的C语言计算能力是完全等同的。C语言中数据和操作是严格区分的，静态的数据和动态的操作在我们脑海中已经根根深蒂固，但根据以上的论述，我可以想到，只要能发明一个东西，能完全满足数字的定义，那这个东西就可以完全代替数字了（本质上就是），lambda演算还真有这个能力，用操作实现数据。以下一些概念可能牵涉到数学中的实分析（推荐一本书《陶哲轩实分析》，大家可以看看如何用基本规则构成复杂的数学大厦），如果没有实分析理论基础，看数据抽象这块会有一些障碍。SICP中的例子非常简单，要大家用lambda演算建立（整数）自然数体系及自然数加法规则。
它先定义了数字0：
(define zero (lambda (f) (lambda (x) x)))

然后定义了自增1操作：
(define (add-1 n)
(lambda (f) (lambda (x) (f ((n f) x)))))

很显然有了这两个规则，其他自然数都可以定义出来了：
1 = (add-1 zero)
2 = (add-1 (add-1 zero))
3 = (add-1 (add-1 (add-1 zero)))
...

这样表示不够直接，换成如下：
(define one (lambda (f) (lambda (x) (f x))))
(define two (lambda (f) (lambda (x) (f (f x)))))
(define three (lambda (f) (lambda (x) (f (f (f x))))))

大家看见了吧，任何自然数被都定义成过程，我们再在这些过程上定义等同的四则运算，然后提供转换到阿拉伯自然数空间的方法，就建立了属于自己的自然数体系了。这里SICP让我们定义一个基于lambda自然数定义的原生加法，很简单，a + b的加法效果只需要等同于0自增a加b次就算成功了，为了更简单的检查结果到底准确与否，先实现一个lambda自然数体系到阿拉伯自然数体系的简单方法：
(define (print-x n)
(define (mark x)
(display "0"))
((n mark) 0))

使用方法如下：
(print-x three) => 000
会打印3个'0'字符，这样我们就知道这个lambda数到底对应于自然数3了，这和原始人在还没有数字概念的情况打绳结计数是一个道理：）

加法定义如下：
(define (lmd-add a b)
(lambda (f) (lambda (x)
((a f) ((b f) x)))))

测试下对不对：
(print-x (lmd-add two three)) => 00000
(print-x (add-1 (add-1 (add-1 (add-1 (add-1 zero)))))) => 00000

有兴趣的朋友还可以在这个基础上添加负数定义和加法运算。

scheme能用一条规则，推导出数字、四则运算符，甚至条件语句、循环语句等等，够原始吧，原来在C语言中被我们看来是原子的数字、运算符、流程控制关键字都可以继续分解为更细的粒度，例子中数字、加法，都只不过是lambda演算漂亮的语法糖衣（正如matrix 1中，最后neo看透了世界的外表，发现世界其实都是code）。

lisp不会衰落，只能会进化，因为他是数学家弄的一套数理逻辑，一个图灵等价的lambda演算，更直白一点讲就是用一种更简洁的方式定义了图灵机。更深层次上lisp代表了一种分析问题解决问题的思想，它和C语言所基于的数学原理从最本质上来讲是完全一样的，只是形式不同，scheme要强力依赖递归形式，其核心思想就是用简单的规则递归组合出复杂规则，将复杂现象分析抽象成简单规则的递归，这非常类似于人类大脑分析现实问题的模式（如果大家非常感兴趣可以参看一本获普利策大奖的科普书《GEB一条永恒金带》），这与类C的命令式语言强调模块治理的理念还是有很大差别的。我觉得lisp思想和分形很像，其大量用于复杂问题求解上，比如编译、定理证明等，当然问题的层次化和模块化与事物简洁规则抽象上并不冲突，相反这两种思想要在紧密配合才能将处理信息最小化，解决问题方式最优化。另外lisp给我一个明显的提醒，没有良好数学基础的程序员走不了多远（大家可以看看《编程本质》这本书，相信大家会理解这个观点）。

《量子物理史话》小故事：
“我的车库里有一条喷火的龙！”卡尔．萨根这样声称。“太稀罕了！”他的朋友连忙跑到车库中，但没有看见龙。“龙在哪里？”“哦，”萨根说，“我忘了说明，这是一条隐身的龙。”朋友有些狐疑，不过他建议，可以撒一些粉末在地上，看看龙的爪印是不是会出现。但是萨根又声称，这龙是飘在空中的。 “那既然这条龙在喷火，我们用红外线检测仪做一个热扫描？”“也不行。”萨根说，“隐形的火也没有温度。”“要么对这条龙喷漆让它现形？”--“这条龙是非物质的，滑不溜手，油漆无处可粘。”反正没有一种物理方法可以检测到这条龙的存在。萨根最后问：“这样一条看不见摸不着，没有实体的，飘在空中喷着没有热度的火的龙，一条任何仪器都无法探测的龙，和‘根本没有龙’之间又有什么差别呢？”。

本文链接

整数二进制补码的数学原理(two's complement)

2011-10-30T05:36:00Z

最近重新学习CPU体系结构，对使用二进制补码原理来消除带符号数和无符号数计算差异，以及整合减法运算器到加法运算器，从而简化CPU硬件设计的原理很感兴趣，所以特地思考了下，查看了一些网上关于two's complement的文章，但大部分还是太过学术，经过整理，我想以一种比较简洁的方式表达出来。为了简单起见，我使用了4位字长的寄存器作为例子，32位和64位道理一样。想了解补码更为科学的数学原理可以参考wikipedia关于one's complement、two's complement的相关文章。

硬件设计以简洁为目标，所以整数的运算最好只有加法，而且不用对符号位进行特殊处理，能达到这个目标吗？当然可以，那就是使用补码（two's complement），所谓补码其实是针对带符号数来说的，其意思就是正数使用原码，而负数使用2的字长的指数减负数的绝对值表示，即x = pow(2, word_length) - abs(x)，这个补码的简单计算方法就是我们计算机书中常说的，将x绝对值取反加1。现在你知道补码的真正计算方法了吧。为什么要将负数表示成这样呢？这是有数学原理的，这正是本文需要阐释的内容，充分了解后对CPU常用指令编程就打下了坚实的基础（general purpose instructions都是针对整数的），以后可能还会增加关于浮点数计算规范的文章。

现在我们来看一个减法：
7 - 6     （式1）
能把它变成一个加法吗？我来试试：
7 + （16 - 6）- 16    （式2）
16是4位寄存器最小的溢出数（2**4 **表示pow运算）,以上两个式子是完全等价的，在我们看来比较繁琐的第二个式子却正是CPU内部整数计算单元所采用的方法，由于一些特殊原因，CPU只需要计算第一个加法，其余两个减法分别由编译器、人或寄存器自动截断完成了。
经过前面的叙述，我们知道了16 - 6就是-6在4位字长机器上的补码，这步计算一般是编译器完成的，将负数直接存储为补码形式，这里是1010。我们来看看CPU如何计算：
0 1 1 1        （7）
+ 1 0 1 0     （10）
-----------   ----------
1 0 0 0 1     （17）

以上式子完成了式（2）中前两步计算，还需要减16才能得到正确结果，神奇的地方到了，因为机器是4位字长，所以第五位1直接丢弃掉了，就是溢出，这相当于自动减了16，所以最后结果就是0001，等于1，完成了式2个所有计算，得到了正确结果，现在你应该明白了为什么会选择最小溢出数所为补码转换中的被减数了吧，就是为了完成自动溢出，从而实现最后的减法。

再来看看2个负数相加，看看CPU是如何把它们当纯粹二进制运算而结果却丝毫不差的：
（-6） + （-7） (式3)
依据上面的规律换成如下式子
[(16 - 6) - 16] + [(16 - 7) - 16]    (式4)
其中(16 - 6)和(16 - 7)部分已经由编译器完成，就是对应负数的补码，让我们来看看CPU的计算内容：
1 0 1 0     （10）
+ 1 0 0 1     （9）
-----------   ------
1 0 0 1 1      (19)

式4中还需要减2个16，这里第5位已经自动溢出减了一个16，我们还要减一个16才能得到正确结果，可是寄存器中结果0011，光凭这个结果，我不知道这到底是最终值还是还需要减16，这可太糟糕了，产生这个问题的原因是如果使用全部4位寄存器存储值时，会产生带符号数二进制歧义问题，打个比方，-9用二进制补码表示是（16 - 9），二进制为0111，居然和整数的7是一样的，光凭这串二进制我无法知道它是-9还是7，好吧，我确实聪明，想到了一个办法，嘿嘿，让我们来看看4位寄存器能存储的二进制有哪些：
0 0 0 0
0 0 0 1
0 0 1 0
0 0 1 1
0 1 0 0
0 1 0 1
0 1 1 0
0 1 1 1
1 0 0 0
1 0 0 1
1 0 1 0
1 0 1 1
1 1 0 0
1 1 0 1
1 1 1 0
1 1 1 1
我可以将最高位数字当作解释数字符号的标志，如果是0我就当正数解释，如果是1我就当负数解释，当正数解释后不用再减16，直接就是最终结果，而如果是负数则还需要减个16才是最终结果，因为我们是用16-x来表示-x的，正好正数负数对半（假设0是正数），再回到上面那个问题，（-6） + （-7）CPU寄存器中最终为0011，我当应该当正数解释，正数不用减16，所以最后等于3，不对！应该是-13，还需要减个16才对，可我们刚说了正数不用减。到底哪里出问题了？大家思考下。
原来如果我们将二进制用以上阐述的方式解释，决定了4位二进制表示的数的范围只能是[-8～7]，实际上寄存器如果从左端溢出的话，其值是在[...0\1\2\3\4\5\6\7\-8\-7\-6\-5\-4\-3\-2\-1\0...]不断循环的，也就是说刚才的-13从-8向左数5位，又循环回到了3，我们必须有办法判断溢出情况，如果我们把寄存器中的二进制当无符号数解释，那很简单，只要最高为产生进位那就溢出了，可如果当带符号数解释，如何看最后的值是否溢出呢？
这是个补码数学原理的精髓所在，有了这个推理，CPU才能做到同等处理带符号数和无符号数，我们来仔细分析下数学上的原理，在CPU看来寄存器中的就是纯粹的二进制，相当于无符号数，如果两个数相加时，最高位产生了进位，则表示结果肯定位于[16～30]，如果次高位向最高位产生了进位则表示结果低3位相加结果范围位于[8～14]，由于最高位溢出被丢弃，表示对最终结果减了16，而次高位向最高位产生进位，表示最终结果最小为8，现在就有如下几种结论：
（1）最高位有进位，次高位有进位，则最终结果位于[-8～6]
（2）最高位有进位，次高位无进位，则最终结果位于[-16～-9]
（3）最高位无进位，次高位有进位，则最终结果位于[8～14]
（4）最高位无进位，次高位无进位，则最终结果位于[0～7]
而我们带符号的解释方法，决定了数的范围为[-8～7]，怎么样一眼就看出该如何判断带符号数计算是否溢出了吧！

然我们来看看CPU EFLAGS寄存器中最常用的6个标志位CF,PF,AF,ZF,SF,OF，我只解释CF和OF，其余的4个都很好理解，CF表示两个操作数进行二进制整数计算时最高位发生了进位，很显然可以用来判断无符号数是否溢出，而OF是寄存器次高位是否向最高位发生进位的标志（进位1，否则为0）与CF位的XOR值，是不是很神奇，就是我们最后阐述的四项规则，正好用来判断带符号整数是否溢出。

是不是无法想象在一般书上一笔带过的整数计算用的补码规范后面却隐藏了这么多原理，正是这些特性，决定了处理器设计时采用二进制补码进行整数计算，他使带符号数和无符号数的加减运算全部用无符号数加法运算实现，使电路实现大为简化，增加了处理器效率，减少了设计制造成本。但整数的乘法/除法运算却无法这样处理，这就是为什么有带符号的乘除指令而加法和减法却没有，从一定意义上讲，其实减法指令只是加法指令的一个包装，因为CPU内部没有减法逻辑，只有加法。

本文链接

Vray的全局照明(Global Illumination)算法原理与比较(图文)

2010-08-27T03:47:00Z

Vray的全局照明(Global Illumination)算法原理与比较(图文)

引言

即使沒有經過實際統計但毫無疑問地Vray是國內最多人使用的渲染器。有些人會說那是因為Vray是最容易學、最簡單的渲染。其實根本不是，Vray是在MentalRay、FinalRender、Brazil、Maxwell…等眾多渲染器中最複雜的渲染器，原因很簡單，因為它除了一般常見的渲染引擎Qusi Monte-Carlo、Photon Mapping、Irrandiance cache (或稱Final gathering)外，Vray又多了Choas Group專利的Light Cache演算法。Vray渲染器明確地把光線反彈分為第一次反彈（Bounce）與第二次反彈，第一次反彈有4種渲染引擎可供選擇，第二次反彈有3中渲染引擎可供選擇，在不考慮原理之下，就有4x3=12中排列組合可供選擇。雖然Vray預設有第一次渲染是用輻照映射（Irrandiance cache），第二次反彈是用準蒙特卡羅演算法（Qusi Monte-Carlo），但當要調整渲染引擎時，若不是實際了解這些演算法背後的原理，真的要調整使還是會使人一頭霧水。怎樣針對你的場景特性去調配第一次反彈的引擎與第二次反彈的引擎種類? 這還真是不容易回答的問題。

這篇文章一開始的時候只是翻譯Vray的相關文件，但後來添加如Wikipedia的解釋名詞以及個人的理解，並順便將相關知識補齊，所以最後是翻譯的內容與原創文章混雜在一起。參考文獻放在文章最後。其實Vray用first bounce， second bounce這個用字是很容易誤導，不準確的用字。因為Bounce本身就暗示了演算法是基於光子映射（Photon Mapping）的光子在場景中反彈。一開始總會納悶為何Vray要把渲染搞的這麼麻煩，要提供這麼多選項?其實Vray只是把混合計算法這樣的概念明確寫出來罷了! 就好像是MentalRay可以把Photon mapping與Final Gathering這兩種計算法混合一起使用，Vray也可以在第一次反彈使用Photon mapping 第二次反彈使用irrandiance cache，就本質是上是與MentalRay完全相同。Finalrender則是比較賊的不明確告訴你它是由哪兩種計算法混合的其實這三個渲染器都是採用混合演算法。為什麼要用混合演算法呢?因為各種算法有其缺點也有其優點。簡單的說，把算法混在一起使用可以截長補短。在後面的翻譯文章會詳細介紹。

一、渲染器的歷史：

幾乎所有現代全局照明渲染器都是基於Jim T. Kajiya 在1986年所發表的那篇---渲染方程式(The Rendering Equation)論文之上。這個方程告訴您光是如何在場景中傳播。在那篇論文當中，kajiya還提出了以圖像為基礎，利用蒙特卡羅方法的渲染方程式稱為路徑追蹤(path tracing)。其實，這個方程式已經廣為人知，並使用在計算輻射在環境中的傳播有一段時間了。然而，Kajiya是第一個將這套方程式應用到計算機圖形學當中的人。

這個渲染方程式只是一個“計算電磁學的麥斯威爾(James Clerk Maxwell )方程式的逼近版本"。它並不能模擬所有的光學現象。它只是基於幾何光學，因此無法模擬折射，干涉或兩極分化。不過，這個方程式很容易修改，使其能夠計算與波長有關的效應---例如散射。(譯者注: 這就是為什麼著名的渲染器要命名為Maxwell?)

更哲學一點來說，這個渲染方程式是是一個數學模型用來描述光的行為。雖然對計算機圖形學來說這是一個很好的模型，它並未說明究竟光如何在現實世界中當中運動。例如，渲染方程式假定光線是無窮的薄且認為光的速度是無限的---這兩個假設都不符合真實世界的光線。

因為渲染方程是基於幾何光學的，光跡追蹤(raytracing)是一個用來求解渲染方程非常方便的方法。事實上，大部分渲染器在計算渲染方程式的時候都是用光跡追蹤這個方法。

雖然渲染方程式可能會有不同寫法，但Kajiya提出的方程式看起來像這樣：

這個方程式的意思是：場景中，光線由x點移動到另外一個點x1等於光線自x2移動到x1並且反射到x點的所有光線總合

除了一些簡單的狀況之下，要無限長的計算時間電腦才有可能把這個方程式解出來。不過，我們可以盡量得到接近的結果---在可接受的計算時間裡面。科學家找尋能在合理的時間內完成計算的全局光照演算法。

渲染方程式只有一個。不同的渲染器只是用不同的解法去計算結果而已。如果任何兩個渲染器的計算結果精確度夠的話，那麼就應該渲染出完全一樣的結果才對。理論上是這樣啦，但實際上渲染器往往會截斷或是修改原始渲染方程式，因此可能計算出不同的結果。

二、渲染引擎特性分類：

A. 完全計算法（Exact）與估計值計算法（approximate）

如上所述，我們計算不完每條算式---始終會存在著一些計算誤差，雖然這些物非常小。某些渲染法，可以由使用者自行決定計算的精度（例如 GI的密度，或GI的射線數目，或是光子的數目等。然而這種做法有一個缺點，那就是使用者必須等待整個計算過程完成後才能知道最終的渲染品質是如何。另一個缺點是，使用者必須要經過很多嘗試才能知道如何在最少的時間內達到要求的品質。不過，這種方法有個大優勢，就是可以有效率地控制精度範圍，因為這種演算法能夠專注於困難的計算區塊（將渲染範圍分割成區塊，成為獨立區域，最後在將結果組合起來。

其他方法，是用漸進式(progressively)的方式進行渲染，這種方法在剛開始計算時誤差很大，但在每次新的演算後會把誤差縮小。在任何時間點，我們能獲得完整的渲染結果。因此，我們可以在計算途中終止渲染器的計算。

表一、完全計算法與估計值計算法比較表

B. 收集法（Gathering）與發射法（shooting）

發射法：

自燈光開始發射光子到場景中。請注意，這種方法繼可以是完全計算法也可以是近似值計算法。

收集法：

由攝影機方向或是場景中的幾何體開始。請注意，收集法，既可以是完全計算法或是近似值計算法。

混合計算法：

將發射光子法與收集法兩個方法結合在一起使用;混合計算法可以是完全計算或是近似值計算。

表二、收集法與發射法比較表

C. 收集法：

收集方法和某些混合法可以是與視角有關（view-dependent）或是與視角無關（view-independent）的計算法。

表三、視角有關或是與視角無關的計算法比較表

三、Vray當中所支援的GI法

Vray提供您不同的GI計算方法---完全計算法，近似值計算法，光子發射法及收集法。不同場景適合不同方法。

完全(exact)計算法

Vray支持兩種完全計算法：蠻力GI及漸進路徑追蹤法。兩者之間的差異，就是蠻力GI法能與傳統的影像組合演算法（區塊渲染）相互使用，而且是自適應的，而漸進路徑追蹤法，必須一次就把整個影像計算完畢並沒有任何自適應的功能。

近似值(Approximate)計算方法

Vray所有其他的方法（輻照映射，光快取，光子映射）都是近似值方法。

發射(shooting)光子法

光子映射法是Vray當中唯一的發射光子法。焦散效果也可以由光子映射法被計算出來，且能夠與收集計算法搭配使用。

收集(gathering)計算法

Vray所有其他的方法（蠻力GI，輻照映射，光快取法）都屬於收集計算法。

混合法

你可以在V-Ray當中的第一次反彈與第二次反彈中使用不同的計算法，你可以使用完全計算法或近似值計算法，光子發射法及收集計算法，完全依據您的需求。可能的組合列在GI範例中。

V-Ray提供您不同的計算法計算間接照明。讓你在品質和速度之間做取捨：

A. 蠻力法(Brute force)

蠻力法---或是翻譯成暴力法，這是最簡單的解算法；這個方法是經由獨立計算物體表面每一個陰影點(shaded surface point)追蹤每個點上的半球面不同方向的射線所計算出來的間接照明。

蠻力法是一種程式設計的撰寫風格，這種程式並不帶有任何投機取巧的方法來改善計算效能，純粹只是依賴的電腦努力的運算，嘗試所有的可能性，直至最終答案被計算出來。典型的例子是旅行的推銷員難題（the traveling salesman problem）。假設推銷員需要到十個城市訪問。請問推銷員要怎樣的走法才能用最短的距離訪問所有的城市呢?蠻力法用的是最簡單的做法來求解---就是實際計算每一條可能的路徑，然後選擇其中最短的一個。這種方法不是很有效率，因為它並不是用有智慧的方法先過濾掉一些不可能的路徑。

雖然蠻力法用起來很愚笨，但它在軟體開發卻有它有用的地方。由於蠻力法最後可以保證得到正確的計算結果---儘管計算速度緩慢---但蠻力法可以用來測試其他快速演算法的精確度。

例如，在考慮八后(eight queens problem)問題時，要求把八個皇后放在一個標準西洋棋棋盤上，而且沒有皇后能夠攻擊其他皇后。蠻力法會研究所有的可能性---64! /56! = 178，462，987，637，760---也就是在64平方的位置上擺8個棋子，在每一個排列組合中，檢查是否沒有皇后能夠攻擊其他皇后。

蠻力法很容易設定，並會一定會找到解答，只要是這個問題是有解的。不過，問題越複雜往往會計算越久，在許多實際問題中，這種狀況往往隨著問題的複雜程度呈現倍數成長。因此，蠻力法通常應用於候選解答較少時，或是問題能有某些提示，可以用來減少候選的答案的數目。這種方法也可以用於速度比答案更重要的問題上。例如當問題的答案錯誤會導致產生非常嚴重的後果的時候。

蠻力法(Brute Forc)在大部分的情況就等於準蒙特卡羅演算法(Quasi Monte-Carlo)也等於直接計算(Direct Computing)，雖然它們的本質還是有點不同。準蒙特卡羅演算法指的是一種取巧的隨機採樣的方式，主要是為了不計算所有算式(母群體)，而只考慮較少的採樣本。蠻力法要跟像是Photon Mapping、 irrandiance cache這種算法相比較，後者多少有點取巧不計算所有的採樣點，後者是指計算部分採樣點其餘採插值計算。蠻力法則是乖乖地計算所有準蒙特卡羅產生的採樣點。換句話說是直接計算---Direct Computing。

準蒙特卡羅演算法(Quasi-Monte Carlo simulation)跟傳統蒙特卡羅演算法(Monte Carlo)類似，只是與傳統蒙特卡羅演算法不同的是，準蒙特卡羅演算法使用準隨機序列(quasi-random sequences)，而不是用隨機序列(random numbers)。這些序列是用來產生與我們要解決的問題有關的機率分布的代表性的採樣。準隨機序列，也被稱為低差異序列(low-discrepancy sequences)，在某些情況下可以改善傳統蒙特卡羅演算法計算時間過長的問題，準蒙特卡羅演算法能提供較短的計算時間/或更高的精度。

其實，低差異序列是完全確定性的，因此，準隨機會誤導人以為它是隨機的，其實並不是。低差異序列被用來取代均勻分佈的隨機序列。用“準”這個形容詞，其實是要強調這樣的序列既不是隨機也不是假隨機，但準隨機序列與隨機序列有某些共通性質，這種特性被應用在如準蒙特卡羅方法裡面，這樣的特性是準蒙特卡羅方法一個重要的優勢。

蒙特卡羅法，其實是一種通稱。蒙特卡羅法是一種隨機的技術---這種方法利用隨機率列和機率統計來解決複雜問題。蒙特卡羅法被應用到各行各業中，從經濟學到核子物理，到交通車流調節。當然，不同研究領域的應用方法會不一樣，單就化學研究來說就有數十種不同的蒙特卡羅演算法。

蒙特卡羅法源於美國在第一次世界大戰時研發原子彈的---曼哈頓計畫(Manhattan Project)。該計畫的主持人之一馮·諾伊曼(John von Neumann)用世界馳名的賭城---摩洛哥的蒙地卡羅(Monte Carlo)來替這種方法命名為它蒙上了一層神秘色彩

使用蒙特卡羅法能讓我們研究相當複雜的物理模型難題，不用這種演算法我們幾呼無法解決的。要求解兩個原子之間的交互作用是相當簡單的;一樣的方程式要解決數百或數千個原子交互作用是不可能算的出來的。使用蒙特卡羅法，我們可以對大系統做隨機採樣，而這些採樣足以描述整個複雜系統的行為。

計算全局光照的蠻力法，由於這種方法會計算每以個採樣點的GI數值，每一個點的計算是獨立的。雖然非常耗時，但這種方法非常準確，特別場景中的小細節都能表現出來。為了加快蠻力法的計算，您可以與其他方法混合使用（光子映射或光快取）作為第二次GI反彈的計算法，而使用蠻力法作為第一次反彈的計算法。

B. 輻照映射（Irradiance map）

輻照映射---或翻譯成發光貼圖，相當於MentalRay的Final Gathering最終收集。這個方法是基於輻照快取（irradiance caching）;基本上就是指計算場景中特定的採樣點，而場景中其餘的點做插值計算。

輻照指的是在3D空間某一點的光線，這個光線是自這個點四面八方反彈過來的。一般來說，場景中不同的點都有不同的輻照。不過，有兩個有用的限制條件，。第一種是表面輻照-這指的是位於物體表面的輻照。這是一個很自然的限制條件，因為我們通常對物體表面的照明有興趣。第二個限制是漫射表面的輻照值---等於光線到達這個點的光總量，不論這些光線是從哪裡來的。簡單來說，其實物體表面的顏色其實就是他的表面輻照數值，如果這個材質是純白且完全的漫射

V-Ray的輻照映射能夠有效地計算場景物體的表面輻照。因為場景中不是所有物體都有相同的間接照明細節，理所當然在有許多細節地方應該要有更精確的計算（例如兩個靠近的物體，或是有銳利陰影的地方，而在沒有細節的地方減低精確度（例如大型均勻的光照區域。因此輻照映射法是自適應的。這是經由多次pass才能實現的，每一次pass（每渲染所謂的及格率）解析度就增加一倍。這種做法就是一開始使用低解析度（例如1/4的最終影像解析度）然後慢慢增加到使用最高解析度。

其實輻照映射就是在3D空間（點雲）中點的集合，這些點包含了間接照明的資訊。在GI那個pass裡面，當一個物體光線擊中，V-Ray會判斷輻照映射裡面是否有其他類似的點具有類似的方向與位置。從那些已經計算點，V-Ray可以提取點裡面的各種資訊（例如: 是否有物體靠近這裡，或是間接照明改變的有很明顯嗎…等）。根據這些訊息，V-Ray可以決定，這個點的間接照明究竟是要其他已經建立好的輻照映射來做內插計算就好呢?還是不要做內插計算。如果不要，那就必須真的去計算這個點的間接照明並將資訊儲存在輻照映射當中。當進行實際渲染時，V-Ray採用非常複雜先進的插值方法得出場景中輻照映射的逼近值。

C. 光子映射(Photon map)

光子映射---或翻譯成光子貼圖(Photon Mapping)，這種做法讓光子自光源開始發射出去，在場景中彈跳。這對計算是內或半開放的是內場景很有用。單獨使用光子映射計算法通常不會產生好的結果;但如果與蠻力法或輻照映射其中一方法搭配使用，光子映射可以粗略估計光線在場景中的位置。

光子映射有點類輻照映射。它也是用來成現場景照明的一種方式，它也是3D空間中點的集合（點雲）。但是，光子映射是以不同的方式建立的。它是藉由追蹤場景光源發散出的粒子（光子）。這些光子在場景中反彈，並撞向各種表面。光子擊中點會儲存在光子映射當中。

由光子映射重建出場景的照明是與輻照映射的重建方式有所不同。輻照地圖只需要把每個樣本點之間作簡單的混合與內插計算就可以。使用光子映射則必須要估計任一點的光子密度。光子密度估計是光子映射這項技術的重點。V-Ray可用使用多種方法進行光子密度估計，每個方法都有它優缺點。這些方法基本上就市找尋最接近採樣點的光子。

請注意，一般來說，光子映射算出來的光照效果比輻照映射算出來的較不精確，特別是在細節較多的場景時。輻照映射是自適應的，而光子映射不是。還有另一個重大的缺點就是光子映射對於場景的邊界常常出現計算錯誤。通常會出現在邊緣或角落，而算出來的會比它們原本應該的亮度來的深。輻照映射也有邊界計算錯誤的問題，只是因為其有自適應計算的性質，使得這個錯誤被大大地減低了大。光子映射的另一個缺點是它不能模擬天光照明。這是因為光子需要一個實際發射光子的表面。至少在V-Ray裡面，實際上天光並不只是場景中的一個表面物體而已。

然而，光子映射是不受視角所影響的且可以計算較快。因此把它作為場景照明的估計，然後與其他更精確的方法例如直接計算或是輻照映射搭配使用會更好。

D. 光快取（Light cache）

光快取---或被翻譯成燈光緩存，是計算場景中全局照明的逼近計算法。這種方法非常類似的光子映射，但它沒有光子映射的許多限制。這種方法是發由Chaos Group所研發，專門設計給V-Ray渲染器的。光快取的建立是經由自視角產生許多追蹤線。每個路徑的反彈儲存照明訊息在幾何體之上，這種方法非常類似的光子映射。光快取能夠被應用於是內場景或是室外場景，不論是單獨使用或是與蠻力法或輻照映射其中一種方法搭配使用，都能計算的不錯。

光快取方法主要是自視角追蹤光線。每個路徑會儲存由其他點過來的光照資料，非常類似的光子映射。在某種意義上，它與完光子映射完全相反，因為光子映射是追蹤光線的路徑，並將能量儲存在光子映射當中。

表四、Vray的四種渲染引擎優缺點比較表

表五、各種全局照明演算法特性簡表

表六、推薦的GI配對方法

總結
Vray的irrandiance cache其實就等於MentalRay的Final Gathering。這兩個名詞不同但是本質相同即使它們內插方式稍有不同。就全局照明的計算方式而言，Photon Mapping其實是最容易理解的；想像在一個純白的房間內，有一台自動網球發球機，每個網球上塗上了紅色的油漆。發球機發射網球在房間內反彈把房間染的紅紅一點一點。用這樣比喻，越多的網球發射，房間的紅色球斑就越不明顯，越少就會有明顯的球斑。Photon Mapping的原理就是燈源發射光子到場景中彈跳，根據設定條件光子會停止彈跳停留光照資訊在場景表面。irrandiance cache (或Final Gathering)的概念就完全不同，自攝影機中決定場景細節多的地方放置收集點(Gathering Point)這些點自其半球方向收集四面八方的間接照明資訊這種演算法的重點就是收集資訊 Final Gathering應該翻譯成最終收集，而不是最終聚集。Light Cache則是和Photon Mapping很像，只是Light Cache追蹤光線的方向不是自光源開始，而是源自攝影機視角。

本文链接

关于D3D9显示格式的解释

2010-04-15T09:06:00Z

程序员被D3D的一堆格式搅的心神不宁、如坠云雾，这是可以理解的，因为MS对底层封装一般，而且不对情形做任何解释，我只能在主观猜测的基础上对显示系统做个最粗浅的说明，权当参考，希望对初学者有帮组。D3D将顶点绘制到最终的显示器上经历了太多了磨难，但我不在此不说明顶点变换和光栅化部分，因为这属于3D图形范畴，这里要阐明的是D3D没有开放给程序员的部分，viewport以及从PS里出来到显示器上对应像素的流程。

关于光栅化和MSAA的一些讨论

2009-12-17T08:00:00Z

关于MSAA和光栅化的一些讨论，出自http://www.opengpu.org/bbs/

程序员面对分歧和难题应当具备的态度

2009-12-08T06:48:00Z

能力不是最重要的，态度才是决定因素。程序员由于幼年受虐，缺乏异性关爱，以及鲜与人类交流等特殊原因，滋生了很多心理疾病，点一盏明灯，照亮这些阴暗角落，愿大家健康茁壮成长。

坐标变换

2009-08-07T04:35:00Z

图形学数学基础中，总能看见把（x,y,z,1）称为齐次坐标，而把(x,y,z)称为普通坐标，我觉得可能理解有问题，当然我对数学也知之甚少，希望一起讨论。