我是谁？哪些方式可以找到我
作者:volfmath 日期:2010-05-23
关于诡辩生活关于我的博客
作者:volfmath 日期:2009-11-08
Gamebryo系列材质详解：四（一个最简单的VS）
作者:volfmath 日期:2010-06-30
总结上第三课的内容。写一个shader。我用gamebryo生成的写法。对应的hlsl或者cg的大家自己去google
1.首先确定VS中的入参，以及出参，还有寄存器中的东西。
讲下这里的内容：寄存中一般存储了世界矩阵，视矩阵，材质颜色，灯光等相关的环境信息。因为显卡寄存器的数量是有限的，而环境越多能做的变化也越多，所以这里要做一个权衡。到底需要什么样的效果，需要用到哪些寄存器都要事先估算好。
入参的一般是顶点的位置坐标信息。这个显然不能卸载寄存器里，因为顶点数量太多了。有些特殊的做法，比方在做Instancing的时候我们有时候会把顶点的变换信息存储到寄存器里。这以后再讨论。
先写一个简单的：（取自gamebryo自动生成的shader脚本）
程序代码
/*
Shader description:
TRANSFORM = 0
1.首先确定VS中的入参，以及出参，还有寄存器中的东西。
讲下这里的内容：寄存中一般存储了世界矩阵，视矩阵，材质颜色，灯光等相关的环境信息。因为显卡寄存器的数量是有限的，而环境越多能做的变化也越多，所以这里要做一个权衡。到底需要什么样的效果，需要用到哪些寄存器都要事先估算好。
入参的一般是顶点的位置坐标信息。这个显然不能卸载寄存器里，因为顶点数量太多了。有些特殊的做法，比方在做Instancing的时候我们有时候会把顶点的变换信息存储到寄存器里。这以后再讨论。
先写一个简单的：（取自gamebryo自动生成的shader脚本）
程序代码/*
Shader description:
TRANSFORM = 0
番外篇For：Gamebryo材质系统
作者:volfmath 日期:2010-05-30
虽然叫For Gamebryo材质系统，但其实跟他一点关系都没有。番外篇讲点多年来总结的数学知识，很多都是自己的YY。欢迎拍砖。本篇会长期更新。不过为了跟材质系统相关，我会先讲射影几何学，微分几何，线性代数的一点浅见。
1.坐标变换&仿射空间
本人不是科班出身，属于半道出家。计算机图形学小读过几本，幸好有个怪癖喜欢数学。今天才得以让那些深奥难懂的计算机只是重见天日。
其实本质的东西都是很浅显的，但是日子久了形成了一门学问。装逼犯就多了。他们开始喜欢用术语欺骗人。特别是中国大多数教授，本事没学多少，术语倒是一箩筐。所以建议翻译的书少看为好，或者拿来一本一看很多不懂的术语，那通常是烂书。数学上有个operator，翻译到中文叫“算子”。我愣是学了两年才明白这个词的意思。害人不浅啊。计算机也没好哪里去。长度都能说成“欧几里德范数”。我无语。
我大学时候读过2，3本计算机图形学书，一本是本科生教材，一本是3D游戏中的数学，还有本大部头的3D图形学卷1，好象是。每次以讲到变换都要说，我们把变换矩阵加一行，加一列就可以做变换了。
这对刚刚学过线性代数的人很不能理解。我们通常觉得，一个3维矩阵就表示了3维空间。其实这个概念也是稀里糊涂的。好，就这样认为吧。那么为什么在3维空间里坐标换要用到一个4×4的矩阵啊。不奇怪么？
1.坐标变换&仿射空间
本人不是科班出身，属于半道出家。计算机图形学小读过几本，幸好有个怪癖喜欢数学。今天才得以让那些深奥难懂的计算机只是重见天日。
其实本质的东西都是很浅显的，但是日子久了形成了一门学问。装逼犯就多了。他们开始喜欢用术语欺骗人。特别是中国大多数教授，本事没学多少，术语倒是一箩筐。所以建议翻译的书少看为好，或者拿来一本一看很多不懂的术语，那通常是烂书。数学上有个operator，翻译到中文叫“算子”。我愣是学了两年才明白这个词的意思。害人不浅啊。计算机也没好哪里去。长度都能说成“欧几里德范数”。我无语。
我大学时候读过2，3本计算机图形学书，一本是本科生教材，一本是3D游戏中的数学，还有本大部头的3D图形学卷1，好象是。每次以讲到变换都要说，我们把变换矩阵加一行，加一列就可以做变换了。
这对刚刚学过线性代数的人很不能理解。我们通常觉得，一个3维矩阵就表示了3维空间。其实这个概念也是稀里糊涂的。好，就这样认为吧。那么为什么在3维空间里坐标换要用到一个4×4的矩阵啊。不奇怪么？
双面维罗尼卡：深度解析豆瓣成功的秘诀
作者:volfmath 日期:2010-05-27
豆瓣从一上线开始就不走寻常路。慢慢开始构建阿北心中的社区模型，就像乔布斯之于苹果迷一样，我觉得阿北之于豆瓣迷，他就是所有粉丝的教主。
不管你想怎么否认，你的心里总会有一个时刻觉得豆瓣的用户群在中国网民中素质强于其他SNS社区，好过开心网不用多说，秒杀人人网。这个艾瑞的数据也许比我说的更加明白。在一个没有偷菜没有买人抢车位的社区，注册人数和在线人数一次次被刷新不能不说是个奇迹。
人人网抄了facebook的社区模式，开心网抄了插件体系。但都开始陷入瓶颈。人人网的几个动作都2到家了。收购开心域名和改校内为人人。两个目的很明显，用开心的域名来抢流量，用人人域名来做横向扩张。但是我们发现都是失败的。开心网还是那些白领阶层的同事。校内网依然是同学。反观豆瓣，从来都没有高调入市，才豆瓣呢，豆苗都没出来。但是你看看豆瓣用户群恰恰涵盖所有的范围。我的好友里有同事，有同学，有朋友，更多的是不认识的人，他们来自各行各业，有全国各大高校高材生，全球各大公司高级人员，也有厌学的孩子，下岗待业的，自由职业者，摇滚明星甚至钢琴老师。而这些都是因为我们＂臭味相投＂。
我后来发现阿北是工作经历是IBM的科学家，看，阿北是抽象思维，其他两个陈一舟和程炳皓都是具象思维。想想看SNS的精髓是什么啊？什么推动了历史的车轮在前行，互联网为什么这么热闹？交流啊。
什么是交流的出发点啊？兴趣啊。一首歌，一部电影，一本书。这才是社区的抽象接口，用我们程序的思维来说就是找到了合理的隐喻。我为什么不想去人人？因为我根本不关心同学在干吗，开心也是，我也根本不关心我的同事在干吗。换句话说，稀奇古怪的原因使我们在一起学习或者工作了一段时间，或许我们曾经是十年修的同窗度，我们曾经互相帮助，但一旦远了，朋友的友情也就淡了。人人网天天提醒我们，你很久没跟你的同学打招呼了，我也懒的去点，因为什么？我们没什么好交流的，彼此知道曾经是朋友，或许以后哪天能见面，再困难的时候帮助下对方而已。到目前为止我的人人网只有同学，开心网只有同事。
不管你想怎么否认，你的心里总会有一个时刻觉得豆瓣的用户群在中国网民中素质强于其他SNS社区，好过开心网不用多说，秒杀人人网。这个艾瑞的数据也许比我说的更加明白。在一个没有偷菜没有买人抢车位的社区，注册人数和在线人数一次次被刷新不能不说是个奇迹。
人人网抄了facebook的社区模式，开心网抄了插件体系。但都开始陷入瓶颈。人人网的几个动作都2到家了。收购开心域名和改校内为人人。两个目的很明显，用开心的域名来抢流量，用人人域名来做横向扩张。但是我们发现都是失败的。开心网还是那些白领阶层的同事。校内网依然是同学。反观豆瓣，从来都没有高调入市，才豆瓣呢，豆苗都没出来。但是你看看豆瓣用户群恰恰涵盖所有的范围。我的好友里有同事，有同学，有朋友，更多的是不认识的人，他们来自各行各业，有全国各大高校高材生，全球各大公司高级人员，也有厌学的孩子，下岗待业的，自由职业者，摇滚明星甚至钢琴老师。而这些都是因为我们＂臭味相投＂。
我后来发现阿北是工作经历是IBM的科学家，看，阿北是抽象思维，其他两个陈一舟和程炳皓都是具象思维。想想看SNS的精髓是什么啊？什么推动了历史的车轮在前行，互联网为什么这么热闹？交流啊。
什么是交流的出发点啊？兴趣啊。一首歌，一部电影，一本书。这才是社区的抽象接口，用我们程序的思维来说就是找到了合理的隐喻。我为什么不想去人人？因为我根本不关心同学在干吗，开心也是，我也根本不关心我的同事在干吗。换句话说，稀奇古怪的原因使我们在一起学习或者工作了一段时间，或许我们曾经是十年修的同窗度，我们曾经互相帮助，但一旦远了，朋友的友情也就淡了。人人网天天提醒我们，你很久没跟你的同学打招呼了，我也懒的去点，因为什么？我们没什么好交流的，彼此知道曾经是朋友，或许以后哪天能见面，再困难的时候帮助下对方而已。到目前为止我的人人网只有同学，开心网只有同事。
Ogre 1.7版本重大改进
作者:volfmath 日期:2010-05-12
Ogre新的版本在年后首次发布了。1.7较之以往的版本有了长足的进步。
由于跟SOC的互动，Ogre 1.7开始慢慢渗透了更多只有商业引擎才有的功能。这得益于最初优良的框架。
下面一个一个道来。
1.改了个名字，似乎是另外一个怪兽。：） 协议改变，现在是MIT了，总之就是更自由了。
2.Sample Browser的引入，社区里有篇写的很详细的文章。很多商业引擎都有，个人觉得实行用其实一般，属于引擎的噱头。以后只需要进行一次资源重建就可以切换包括渲染系统等等东西，不用重新运行可执行文件。
3.使用CMake来构建，好处就不说了，社区里也有帖子很详细。
重点来了啊~~
一.地形系统重大改进。
由于跟SOC的互动，Ogre 1.7开始慢慢渗透了更多只有商业引擎才有的功能。这得益于最初优良的框架。
下面一个一个道来。
1.改了个名字，似乎是另外一个怪兽。：） 协议改变，现在是MIT了，总之就是更自由了。
2.Sample Browser的引入，社区里有篇写的很详细的文章。很多商业引擎都有，个人觉得实行用其实一般，属于引擎的噱头。以后只需要进行一次资源重建就可以切换包括渲染系统等等东西，不用重新运行可执行文件。
3.使用CMake来构建，好处就不说了，社区里也有帖子很详细。
重点来了啊~~
一.地形系统重大改进。
Gamebryo系列材质详解：三
作者:volfmath 日期:2010-05-12
托了好久的一篇文章，上次写了一半丢了。只好重头写来。
写这篇文章的时候纠结了很久,如果说的太细,就要涉及到很多数学上的东西,比如要解释为什么变换矩阵是4x4的,要解释tangent space的动机.但是我觉得这对毫无基础而言的学习者来说是个灾难.所以我打算用一个特殊的番外篇来试图解释一些问题,但是你完全不用去看他.就像我记得一开始学习一个引擎的使用时,我们都是先掌握好他的用法,刻意回避掉源代码也就是实现过程,这对学习是有帮助的.等到我们自如的使用以后再来研究细节.
和初衷一样，我不觉得写一个shader是多么困难的事情，不过很多地方都把这个说的异常的玄乎。包括图形中用到的大量的数学知识，我也没觉得有多么的数学。当然最近我在看一个模拟流体的文章中，看到了久违的N-S方程，突然觉得有时候数学懂的多点还是很有用的。
但是无论怎样，游戏里用的编程知识，甚至高超的数学技巧，都只是工具而已，如果你沉溺于其中势必会适得其反。真正的成功来自于设计。还是那句胡子白的老话：技术只是工具，不是诉求。
本文的目的是从浅显的角度让你认识到什么的shader，让一个从来都没有写过一句渲染代码的同志们都能通过这几篇短文的学习开始自己东西使用可编程管线。当然，我也力求用最直白的方式让你搞清楚什么是线性变换，什么是仿射变换，Tangent Space啊，甚至刚才那个N-S方程。
首先我假设你稍微懂点高等数学的知识，微积分，线性代数，如果懂点微分几何就更好了。不过就算这些你听都没听过也不要紧。这不会影响阅读。
两个问题：1.先去看下Generated里生成的文件,如果你能看懂一些片段么?
写这篇文章的时候纠结了很久,如果说的太细,就要涉及到很多数学上的东西,比如要解释为什么变换矩阵是4x4的,要解释tangent space的动机.但是我觉得这对毫无基础而言的学习者来说是个灾难.所以我打算用一个特殊的番外篇来试图解释一些问题,但是你完全不用去看他.就像我记得一开始学习一个引擎的使用时,我们都是先掌握好他的用法,刻意回避掉源代码也就是实现过程,这对学习是有帮助的.等到我们自如的使用以后再来研究细节.
和初衷一样，我不觉得写一个shader是多么困难的事情，不过很多地方都把这个说的异常的玄乎。包括图形中用到的大量的数学知识，我也没觉得有多么的数学。当然最近我在看一个模拟流体的文章中，看到了久违的N-S方程，突然觉得有时候数学懂的多点还是很有用的。
但是无论怎样，游戏里用的编程知识，甚至高超的数学技巧，都只是工具而已，如果你沉溺于其中势必会适得其反。真正的成功来自于设计。还是那句胡子白的老话：技术只是工具，不是诉求。
本文的目的是从浅显的角度让你认识到什么的shader，让一个从来都没有写过一句渲染代码的同志们都能通过这几篇短文的学习开始自己东西使用可编程管线。当然，我也力求用最直白的方式让你搞清楚什么是线性变换，什么是仿射变换，Tangent Space啊，甚至刚才那个N-S方程。
首先我假设你稍微懂点高等数学的知识，微积分，线性代数，如果懂点微分几何就更好了。不过就算这些你听都没听过也不要紧。这不会影响阅读。
两个问题：1.先去看下Generated里生成的文件,如果你能看懂一些片段么?
Gamebryo系列材质详解：二
作者:volfmath 日期:2010-04-28
以下内容，在讲解过程中要不时的用到那张表格，希望你可以在合适的地方放置一边对照以便查看。
材质系统并不难理解，大白话就是我们经常说的“导出”。就是说美术人员在利用3D工具制作的那些东西，如果在游戏中使用。（其实这个比方不好.如果你很清楚的话.导出应该是把MAX里记录的数据转换成引擎所需要的数据.不仅仅是材质,还有顶点数据组织方式,包括位置,颜色，法线，多套UV数据，骨骼数据等等.而材质脚本是用来确定这些数据使用的方式.同样的数据可以有不同的表现,这就是Shader的作用.）MAX毕竟是一个通用软件，对于实时性比较高的游戏来说，我们很难百分百利用到所有Max的功能。这就需要数据间的一个对应。有些游戏的做法呢，是自己制作一个与Max差不多的东西，叫做引擎的工具，在他们自己工具里，给你规定好了一些可以使用的功能，而这些都是这款引擎所支持的功能。
另外一些呢，就是做了导出工具，例如gamebryo。也就说美术的面对的原始工具依然是他们熟悉的Max或者Maya，XSI等。然后他们会有一张长长的表，告诉你哪些是支持的哪些是不支持的，其实有不少就算是支持的，也仅仅是模拟跟Max中查看的效果不完全一致。
gamebryo的材质系统，相比那些只给出材质编写规范的引擎有几点好处：
1.完全隔离了美术与技术之间过多的无意义的讨论，比如美术描述我这里想要一种什么样的透明样式，技术人员要把它翻译成alpha_blend的方式等。这样会造成理解的误差，除非一个美术基础好，又懂技术的人员来完成，这样的人才是很少的。
2.规范了材质系统以后，gamebryo会根据不同的情况生成不同的材质脚本文件。（这里我们假设你的机器已经可以使用可编程管线了，事实上gamebryo的材质系统绝大部分是可以用固定管线实现的，而gamebryo也做到了对硬件不依赖。但这不是我们讨论的重点）。比如使用Normal Map的和不使用的，两个材质脚本（这里是Shader实现的）就有些不同。具体的以后在细分析。而这些不同是通过gamebryo内部的所谓Shader tree完成的。
材质系统并不难理解，大白话就是我们经常说的“导出”。就是说美术人员在利用3D工具制作的那些东西，如果在游戏中使用。（其实这个比方不好.如果你很清楚的话.导出应该是把MAX里记录的数据转换成引擎所需要的数据.不仅仅是材质,还有顶点数据组织方式,包括位置,颜色，法线，多套UV数据，骨骼数据等等.而材质脚本是用来确定这些数据使用的方式.同样的数据可以有不同的表现,这就是Shader的作用.）MAX毕竟是一个通用软件，对于实时性比较高的游戏来说，我们很难百分百利用到所有Max的功能。这就需要数据间的一个对应。有些游戏的做法呢，是自己制作一个与Max差不多的东西，叫做引擎的工具，在他们自己工具里，给你规定好了一些可以使用的功能，而这些都是这款引擎所支持的功能。
另外一些呢，就是做了导出工具，例如gamebryo。也就说美术的面对的原始工具依然是他们熟悉的Max或者Maya，XSI等。然后他们会有一张长长的表，告诉你哪些是支持的哪些是不支持的，其实有不少就算是支持的，也仅仅是模拟跟Max中查看的效果不完全一致。
gamebryo的材质系统，相比那些只给出材质编写规范的引擎有几点好处：
1.完全隔离了美术与技术之间过多的无意义的讨论，比如美术描述我这里想要一种什么样的透明样式，技术人员要把它翻译成alpha_blend的方式等。这样会造成理解的误差，除非一个美术基础好，又懂技术的人员来完成，这样的人才是很少的。
2.规范了材质系统以后，gamebryo会根据不同的情况生成不同的材质脚本文件。（这里我们假设你的机器已经可以使用可编程管线了，事实上gamebryo的材质系统绝大部分是可以用固定管线实现的，而gamebryo也做到了对硬件不依赖。但这不是我们讨论的重点）。比如使用Normal Map的和不使用的，两个材质脚本（这里是Shader实现的）就有些不同。具体的以后在细分析。而这些不同是通过gamebryo内部的所谓Shader tree完成的。
Gamebryo系列材质详解：一
作者:volfmath 日期:2010-04-28
前一阵子我贴出了Gamebryo的材质管线的图片，没加解释的贴出的。我想对于明眼人有经验的人一眼就能看出他的思路是什么，高手通常还能分析出他的局限性与弊端。但是还是受到很多很多的回复。最近的很多经历让我觉得有必要详解一下整个这张图片。
我力求做到国内解释的最详细的一篇，或许比官方还详细吧。但是由于我的知识层次结构，或许并不能面面俱到，所以如果你有新的观点也不妨给我指出吧。
首先，我是一个程序，所以里面设计的大部分知识，偏重于图形学基础知识。可编程管线，Shader流水线，坐标变换，甚至微分几何。但是对于美术而言我就欠缺很多，不过好在我得到了很多美术同行的帮助，也会穿插讲一些美术方面的注意事项，以及实际项目过程中使用这套材质系统的经验。而对于后两条实际上，就目前我的菜鸟水平，是很泛泛的也是最需要行家来补充的。当然如果可以，我也将一些在MAX，Maya中如何操作以及一些在项目开发过程中遇到的问题，修改，或者弥补的方式。
几点建议：
1.适合人群：中低层次游戏开发人员，引擎开发人员，有志于从事图形方面研究的起步人员，懂程序的美术，懂美术的程序。高手请绕道吧。
2.也是我最想说的：任何引擎，或者说任何技术都有其所谓的局限性，就是CE3也不是万能的。当然这套材质系统更谈不上十全十美，我经常听到美术抱怨引擎的拙劣，或者程序抱怨美术的滥用。因为在技术日新月异的今天我们时常忘记了游戏画面的本质，我们常常吹嘘自己有了一款怎么怎么样的引擎，我们常常吹嘘自己能实现什么样的技术，但是永远不要忘记，技术只是手段，而不是苛求。一款游戏唯有风格确定了，知道我们要做什么，要实现什么样的画面，才能考虑怎样去做，而这些恰恰与引擎毫无关系。那些长久的，被人们时常拿来称颂的游戏没有一款是仅仅因为引擎而强大的。我想这不仅仅是美术开发的问题，程序又何尝不是，我记得那时候做工具的时候，有一天掌握了Command模式，我高兴的不得了，后来又一天，我发现Boost bind这个东西更是兴奋了半宿没睡。于是开始滥用设计模式，模板，沉迷于语言的技巧中不可自拔，以至于在项目中出现了很多问题，才让我清醒的认识到。简单的才是美的。时间会证明一切，只有那些最简单的最明了的东西才是长远的。扯远了。下面正式开始。
我力求做到国内解释的最详细的一篇，或许比官方还详细吧。但是由于我的知识层次结构，或许并不能面面俱到，所以如果你有新的观点也不妨给我指出吧。
首先，我是一个程序，所以里面设计的大部分知识，偏重于图形学基础知识。可编程管线，Shader流水线，坐标变换，甚至微分几何。但是对于美术而言我就欠缺很多，不过好在我得到了很多美术同行的帮助，也会穿插讲一些美术方面的注意事项，以及实际项目过程中使用这套材质系统的经验。而对于后两条实际上，就目前我的菜鸟水平，是很泛泛的也是最需要行家来补充的。当然如果可以，我也将一些在MAX，Maya中如何操作以及一些在项目开发过程中遇到的问题，修改，或者弥补的方式。
几点建议：
1.适合人群：中低层次游戏开发人员，引擎开发人员，有志于从事图形方面研究的起步人员，懂程序的美术，懂美术的程序。高手请绕道吧。
2.也是我最想说的：任何引擎，或者说任何技术都有其所谓的局限性，就是CE3也不是万能的。当然这套材质系统更谈不上十全十美，我经常听到美术抱怨引擎的拙劣，或者程序抱怨美术的滥用。因为在技术日新月异的今天我们时常忘记了游戏画面的本质，我们常常吹嘘自己有了一款怎么怎么样的引擎，我们常常吹嘘自己能实现什么样的技术，但是永远不要忘记，技术只是手段，而不是苛求。一款游戏唯有风格确定了，知道我们要做什么，要实现什么样的画面，才能考虑怎样去做，而这些恰恰与引擎毫无关系。那些长久的，被人们时常拿来称颂的游戏没有一款是仅仅因为引擎而强大的。我想这不仅仅是美术开发的问题，程序又何尝不是，我记得那时候做工具的时候，有一天掌握了Command模式，我高兴的不得了，后来又一天，我发现Boost bind这个东西更是兴奋了半宿没睡。于是开始滥用设计模式，模板，沉迷于语言的技巧中不可自拔，以至于在项目中出现了很多问题，才让我清醒的认识到。简单的才是美的。时间会证明一切，只有那些最简单的最明了的东西才是长远的。扯远了。下面正式开始。
![[Valid RSS]](valid-rss.png "Validate my RSS feed")
![[Valid Atom 1.0]](valid-atom.png "Validate my Atom 1.0 feed")
