Technique -> Pass式的材质脚本系统被证明是非常有效的。Technique里可以添加一个属性来让程序能够找到需要的Technique。比如延迟渲染的时候，程序会自动找到有GBufferPass属性的Technique。这样便将前向渲染和延迟渲染统一起来。

    延迟渲染不等于全部都用相同的材质，即便是延迟渲染，也有很多不同情况，比如有无边缘光、是否有Detail贴图、是否有Parallax Occlusion Mapping之类的。

    Material中应该有两类参数，Shared的参数和Mutable的参数。对Shared参数进行赋值的时候，会影响到这个Material所有的实例。如果不想产生这种影响，则需要Break Instance，即克隆一个参数相同的材质，这么做会让材质失去与资源的联系。对于Mutable的参数，则是与每个Instance关联的，不会产生全局影响。大部分参数都是Shared的，比如普通的材质参数如高光强度、Diffuse贴图之类的。而通常一些由程序自动赋值的参数则应该是Mutable的，如LightMap相关参数、Shadow Map相关参数等等。

    Shader模板概念挺好。可以通过一组宏参数来裁剪Shader，使Shader尽可能高效。不过Shader模板的宏参数应该和其他Material参数处于并列的地位，而不是更高。一个Shader应该对应一种材质，而不是多种材质。宏参数和值参数的区别应该被埋在底层。

    在使用Shader模板的情况下，宏参数通常很多，要将所有的宏参数对应的Shader预编译出来是不可能的。因此Shader在其被使用到的时候才编译。然而，这样在运行时因为编译Shader而产生剧烈的“卡”的现象。因此引入ShaderCache机制，即将运行时编译的Shader储存下来，再以后启动的时候读入。另外，编译Shader的时候使用外部程序进行编译，然后适当使用代理模式，应该能解决“卡”的问题。

    资源更新机制很重要。应该建立一套统一的资源更新机制，把符合条件的东西都纳入资源的范畴。被当做资源的条件如下：在外存中有其原始形式的数据存在；外存中的数据与某种运行时对象有对应关系；运行时对象的一部分数据可以通过外存中的数据进行更新而不影响其运作。因此资源可以使材质、贴图和模型等等。可以在运行时重载单个资源，而不用重新创建这个资源的运行时对象。

    Shader的值参数应该通过变量名指定，而不是通过寄存器。对于引擎的使用者来说，指定寄存器编号是不友好的方式。

    3D引擎总是需要一套基本的碰撞检测机制，比如射线、几何体、包围和之间的相交检测。

    一个引擎的工具链中可能会有很多编辑器，像什么场景编辑器、角色编辑器、动画编辑器、特效编辑器等等。这些编辑器应该有一套统一的资源管理与更新机制。编辑器之间尽可能采用数据耦合，即通过文件监控与资源更新机制完成编辑器之间的配合。如角色编辑器对角色进行编辑以后保存，文件监控机制发现角色资源被修改，于是启动资源重导入流程，并且发送消息给场景编辑器要求其更新资源，场景编辑器更新资源。不要每个编辑器包含自己的文件更新机制，这样会出现资源导入逻辑不清晰的情况。简单说就是：资源监控系统对Asset进行“拉”(Asset导入)操作，并且把导入生成资源“推”到相应的编辑器中。

sRGB也是一种“加色”色彩空间，并且sRGB用红绿蓝三个分量来表示一个颜色，因此它是RGB色彩空间的一种。但sRGB从物理亮度上来说，不是“线性”的色彩空间。

为什么要制定一个数值与亮度不成线性关系的色彩空间呢？因为在LCD这样的显示设备出来前，计算机的主流输出设备是CRT显示器，当时大多数的相关从业者或者软件，都习惯于将图像不经颜色变换直接显示在屏幕上。而CRT接收到的信号强度与输出的亮度是不成线性关系的。sRGB就是以参照CRT输入信号与输出亮度的关系制定的色彩空间。sRGB标准的运用极广，比如LCD显示器，打印机等，虽然没有CRT那样的数值->亮度对应关系，还是同样使用sRGB作为其色彩表示方法。

可以做这样一个实验：打开mspaint，在左边画出一个RGB都等于127(128也行)的色块，在右边用RGB=0(黑)和RGB=255(白)两种颜色交叉排列画出同样面积的块。然后离开显示器一段距离观察，一般来说你会发现两个块的亮度是不同的。 为什么(0+255)/2的结果和127(128也行)差别这么大呢？

造成这样的现象的原因有2：1、sRGB的数值与物理亮度之间的关系是非线性的；2、物理亮度与人的视觉亮度之间的关系也是非线性的。第二条很复杂，事实上人眼对亮度的感知还与时间有关系…不过我们说的是光照计算，人眼感光是另外一件事情。

上面说到了，sRGB空间中的点的坐标值与物理亮度不线性相关。这意味着在计算光照的时候，简单的将两个sRGB空间中的颜色相加，得到的值并不是物理上亮度相加得到的结果，实际上要比真实情况更亮一点（如下图）。

先将两个颜色变换到线性空间，然后相加，再将结果重新转换回sRGB空间，才能在显示器上得到正确的结果。（如下图）

在渲染物体的时候，我们通常会使用Diffuse（漫反射）贴图。而Diffuse贴图通常是手绘或者通过照片处理得来。对于手绘的情况，由于一般绘图软件都使用sRGB色彩空间（Photoshop里面默认也是sRGB），所以我们得到的Diffuse贴图的颜色一般都是在sRGB空间的。对于照片处理的情况，由于一般的数码相机或者扫描仪同样适用sRGB色彩空间，因此得到的Diffuse贴图也是在sRGB色彩空间的。

因此，在计算光照之前我们理论上应该将它们转换到线性空间。但是由于早期的硬件性能低下，光照计算简单，离“照片级渲染”这样的目标十万八千里远，所以并没有对sRGB色彩进行特别的处理。

而现在的游戏光照更加复杂。例如进行HDR Tone Mapping的时候，如果不在线性空间计算光照，就可能得到错误的曝光结果。再例如，“次世代”游戏引擎中，Unreal Engine 3的镜面高光的品质为人称道。UE3的高光形状能够很好的随着形体表面（或者法线贴图）产生变化，并且高光贴图对色彩与亮度的控制力很好。高光在物体亮处不会立即爆掉，在暗处也不会显得暗淡无光。其实并没有什么玄妙的东西在里面，产生这样结果的原因有两点：1、UE3可以使用Phong高光，是将光线方向根据法线反射后，跟视线方向求点积得到的；2、UE3中基本上除了法线贴图以外，贴图在导入的时候都会被从sRGB空间转到线性空间，而在光照计算完成，会被转回到sRGB空间以供显示器正确显示。

    (另外，相信我！这绝对不是广告！XSK)

    故事发生在2009年暑假(?)中某一个平凡的下午——

    由于前几天的降雨，今天也不是太热，太阳只在正午露了下脸，就到云层后面呼唤君鹏吃饭了。虽然云层并没有厚到将烈日的光芒完全遮蔽，但还是为我们挡去了一个下午的酷暑。不过即使如此，家里还是开着空调，重庆的温度再怎么也低不到哪去哎。如往常一样，一家人吃过晚饭后，我和父亲便坐在电视旁边聊天，我们谈到如今的经济，我们谈到我将来可能会从事的行业，最后我们谈到了中国的动漫。

    与大部分看动画的人不同，父亲作为一个不看动画的人，对中国的动漫行业的前途是比较看好的。他更倾向于从其他方面来看待中国动漫这个问题。按照我们国家的惯例，一旦国家决定扶持某一个行业，那么这个行业多多少少会得到改善。事实上，近段时间某《喜羊羊与灰太狼》也确实取得一定的成功。老实说，作为一个长年看日漫的人，我完全不觉得国产动画现在与之前更加萧条的时候比起来有多大变化。在我看来，虽然中国动画瞄准的是低龄段，但孩子们也不见得喜欢。“对他人的想法做如此主观的认定，是不是太草率了”，我时常自问。毕竟，对我来说，那些每天六点还没到就守在电视前的时间，已是往日。或许父亲的观点是正确的吧。中国的动画会好起来的，虽然最后的样子可能和我与一些人希望的不同。

    聊罢，父亲睡觉去了，而我则有些无趣地在各个放着动画的频道间切换。一样省工的“中国特色”画风、一样糟糕配音、一样奇怪的分镜、一样无聊的剧情……但是，刚才那是什么。刚才换台太快，一瞬间没看清，只记得有个矮小的橙色背影一闪而过。我赶紧将台切换回来。

    圣洁便便(粗口自重)！这是什么——纯白的发色、大大的双包子头、娇小的体型、上翘的眼角，坐在桌上急性子的发言——这，这不是傲娇萝(*)吗？！是时，百感交集，兴奋、惊讶、高兴、还有些许的茫然。精神被动画牢牢拴住，以至于甚至忘记了用手机把画面拍下来。等我想起用手机拍摄的时候，那萝莉早就从镜头中消失。心中不禁有些遗憾。想了想，中国的动画是天天放，看了看，放的是重庆电视台少儿频道的《缇可春季篇》，来日再战吧。

    于是接下来几天晚饭后我都守在电视前，等着。可惜那天的包子头萝莉再没出现。然而，“上帝关上一扇门的时候，总会为你打开一扇窗”。中国动画这几天给我的惊喜比过去5年加起来还多(因为过去没给过我惊喜)。GGGGOOOD LIKE！那是啥？！紫红色的头发，高树的发束(不好形容，参考《守护甜心》女主)，侧倒在地上，双腿弯曲，左手撑地，右手放在胸口，一副楚楚可怜的表情。但这不是最重要的，最重要的是那双排扣的西式制服，还有日系size的超！短！裙！我用最快的速度拿起手机赶在镜头结束前按下拍照键，但是该死的山寨手机按键和实际拍摄间有将近一秒的延迟，就这样再次错过了机会。

    就这样又过了几天，这季动画竟这样就完了。也没拍到几张有价值的图片。虽然这部视美出品的动画的质量并不是非常的高，配音依旧垃圾，动作连贯性也不咋样，但总觉得很遗憾。

    于是，我想，我能做点什么吗？我想到了同人。可是，对于这么一部面向年龄层为9~14岁的动画，我一个21岁的怪叔(?)来画这个同人，不觉得奇怪吗？但是，心中有个声音越发高昂：“傲娇萝！超短裙！傲娇萝！超短裙！傲娇萝！超短裙！……”

    不管了！男人忠实与自己内心的欲望有什么不对？！(米：喂喂，别给我在这种地方用变态宣言啊) 爸爸，妈妈，儿子不孝，终于要跨入那个奇妙世界了。(米：BL宣言也给我自重！)

    总之，还是动笔了。因为某包子头萝莉只看到几个镜头，外形穿着都记得不是很清楚了所以就只好画了这只。嘛，虽然成品和原版看起来不怎么像就是了。(变御了)

——————- 我是内纽曼面的分割线 ———————

以上是口胡文，比较夸张。不过后面那个确实被那超短裙震了下，不过基本上还是“中国特色”的风格。

真相如下——

而前面的傲娇萝，我现在还在遗憾没能拍到。可恶啊…..

于是，决定以后看到“有希望”的国产动画，也顺便围观一下….

另外，虽然我看到的不是什么大不了的东西，但是….

视美，好样的！

总之，事情是这样的。VOCALOID2出现后一段时间，日本那边出现了一个叫做VocalListener的技术研究项目。这个项目的目标是让用户上传一首自己歌曲，然后变成VOCALOID的文件返回给用户，而这个VOCALOID的文件的输出效果尽可能趋近于用户上传的歌曲的效果。其原理就是将VOCALOID合成输出的歌声与用户提供的人声进行主要是音量和音高上的对比，找出差值，并利用这些差值来生成VOCALOID中的控制参数(比如DYN与PIT)。在VocalListener出现后不久，日本那边便产生了一股VOCALOID技术研究热，也出现了各种各样的模仿VocalListener的技术/软件。

以上那些，差不多已经说明了本文的性质。简单的说，被我称作VocalTune这东西就是一VocalListener的山寨。下面有个演示视频

http://www.acfun.com/html/music/20090722/38890.html

或者

http://you.video.sina.com.cn/b/22894978-1630562311.html

(注：视频前部分大部分时间在进行原唱的消伴唱处理。2:02左右出现的那个命令行窗口才是VocalTune的正体)

VocalTune的原理与VocalListener差不多，都是通过对比人声与VOCALOID输出歌声来获得参数。使用snack库来分析歌声的频率。因为人的听觉中，频率高一倍的话，音高就刚好高一个八度，所以将人声与VOCALOID歌声的频率值求2的对数后并想减。然后，现在音乐理论中，一个八度被分为12个半音，几乎是按照对数平分的。也就是说，增加一个半音高，频率的对数就几乎刚好增加1/12。结合VOCALOID中PIT与PBS两个参数的含义(PBS表示PIT影响的半音数)，我们便可以用分析出的频率对VOCALOID的参数进行调整。

现在VocalTune的很不完善，界面也很不人性化。不过够用了。写这个东西的动机主要是觉得好玩，其次是自己这边有潜在的需求。

本体暂时不放了，修修再放出…

最后放MP3：http://www.yyfc.com/play.aspx?reg_id=2173027&song_id=3142370

还有应景的两张赶图…

HL2在Lost Coast中加入了HDR支持，不过因为当时MSAA和fp16冲突，Value并没有使用很直观的fp16方法来实现HDR，而是用了普通的int8来实现，其做法就是将光照信息编码压缩到RGBA的总共32bit里面。不过这有个问题，在Alpha混合的情况下处理起来会很麻烦，因为编码也会用到alpha通道。

然后，GeForce7600(或者说DX9c?)的显卡支持int16也就是每通道16位整数的渲染目标，但是在dx9c中int16并不支持alpha blending，于是pass。再考虑A2R10G10B10的渲染目标，此格式是支持alpha blending的，而一般的alpha blending只用到dest alpha(也就是贴图中的alpha通道)并没有用到framebuffer中的alpha通道，所以那个A2并不会影响到alpha混合的精度。据df叔所说，A2R10G10B10在XB360上会出现alpha混合的问题，而在他的PC(NV卡)上似乎没问题。于是我们也无从知道是不是PC上的NV卡就没问题，更不知道A卡如何了。

接下来还可以考虑MRT。GF7600是DX9c显卡，支持Shader Model3，也就是说可以一次性渲染到4个渲染目标。我们不做Deferred Shading，所以4个RT绰绰有余了。渲染到2个int8的RT，其中一个RT用RGB三个通道存储色相(剩下的一个留作alpha)，第二个RT使用一个通道来存储一个倍数。在进行HDR相关的计算的时候，将第一个RT中的RGB值乘以第二个RT中的倍数的到完整范围的色彩。至于剩下的通道嘛…存点其他的东西啦，自发光度什么的…

最后，我觉得用什么技术实现并不是最大的问题，最大的问题是60FPS的怨念啊….

以上！

以下的东西进过少量验证，还是不怎么可靠。

之前想到的方法仅仅是直接上法线贴图，结果是，之前“打肿脸”的的光照角度OK了，但是其他光照角度又“打肿脸”了。不过现在用法线贴图，是为了一定程度的模拟SSS的一些特征。在材质空间扩散这种模拟SSS的做法中，使用模糊来模拟光线在材质中的散射，而模糊这种做法，实质上降低了光照变化的频率。因此猜想，如果有其他方法可以降低这个频率的话，是否也可以一定程度上达到SSS的效果呢？

法线贴图一般用来添加表面细节，但是用作其他的目的也不错来着。比如用来扰动法线是表面看起来更加平滑(即是说，降低光照变化频率)。不过这个贴图该怎么做呢…烘焙就可以了。

提出以下两个方法制作这样的贴图：

1、高模(如果有)向低模烘焙法线，不过不是烘焙到常见的Tangent空间，而是烘焙到Local空间。接着在PS或者其他软件里面模糊处理这张法线贴图。最后用软件(比如万能的xNormal)把贴图从local空间转换到Tangent空间。

=>

2、另外建立一个高模，修改这个高模降低其表面变化频率。比如，一张人脸，可以把鼻子、嘴巴都弄平把颧骨附近relax一下。然后用这个高模向低模烘焙法线贴图。

to

ok，贴图做好了，但是该怎么用呢。一开始，我直接将烘焙出的法线贴图(用第一种方法得到的贴图)用在模型上，结果是

…虽然看起来平滑了，但是有些想要平滑的地方没有平滑(比如嘴唇下边的较暗部分)，某些不想平滑的地方被平滑掉了。而且，鼻子和嘴巴处出现黑块儿。黑块儿出现的原因是，从几何结构上来说那块地方应该是处于shadow之中。效果不理想。于是一次性放弃第一种烘焙材质的方法(可控性低)和上面的法线贴图运用方式(和shadow map不怎么友好)。

先设想法线贴图的用法。

如果我们的模型是一个球体，那么根据光线角度与表面法线的夹角我们倒是可以很方便的伪造出次表面反射的效果，像这样。

然而，这样的方法和shadow map不怎么友好。转变思路，次表面散射效果主要是由与光线进入表面以后在其内部散射，最后又离开表面进入摄像机。离开表面的光与在表面就被反射掉得光是叠加的。于是想，减弱普通光照模型的下的光照(光进入了表面)，然后后在适当的地方加上一些光(光离开了表面)。对于球体，可以直接用dot(normal,lightDir)的方法找到适当的位置，而在更复杂的表面上，这个方法就不怎么好用了。like this…

(鼻子下部分应该有光透过，不过却没有)

于是，结合法线贴图降低表面变化频率的想法，用第二种方法烘焙贴图，这次建立的烘焙用高模把鼻子弄平了，嘴唇也平掉了，好吧其实是偷懒，实际上应该更仔细的对待这些部分。效果如下：

鼻子透过光了！虽然没有真正的SSS(或者比较接近真实的伪SSS)那么好，但是效果也不赖。

最后再加上glow。

好吧，glow是作弊，不过看起来还不错。

对比用的未扭曲法线版本(当然，也有glow)….感觉还是前者比较有通透感。

最后，其实嘛…我作弊了(拖

正面光时候的效果并不太好，是否能够通过一些调节来解决，就不清楚了╮(╯▽╰)╭。

不能继续偷懒了orz….

OK，可以吐槽了orz…

(It works)

    然后我把光源移高一点，往旁边偏一点。

(）

    我对无故打肿主角的脸这种事情没有兴趣。不过传统的TV动画的光照模型是高度扭曲过的，要想做得像动画一样不容易啊。很重要的，另外一个原因让我对传统的Cel Shading失去兴趣，那就是Cel Shading会干掉很多的细节。于是把视线转向真实渲染(PR)和非真实渲染(NPR)之间的中间地带。从思路上讲，就是把PR中的技法用到NPR中去。反映到具体画面上就是一些看起来很“湿润”(别想歪)的ACG系CG的效果。

比如这张的效果(脸)：

http://www.pixiv.net/member_illust.php?mode=medium&illust_id=3129353

(由于版权原因，只能放出URL。而且很可恶的是没有账号不能看…

等下有空自己来仿一个)

    稍微分析一下这样的效果的组成。答案是，非常重的“次表面散射(Sub-Surface Scattering即SSS)”效果！对，就是那个传说中的SSS(啥？）。不过这里的散射度放倒PR的情况中去的话，就是严重的过度SSS了。如果用看PR的眼光来看这个皮肤，就像是个蜡块。

    于是引出了正题——SSS效果(死)。不过以下都是妄想，没有经过论证，也暂时没办法论证。主要目的是记下思路等以后有时间的时候实现，比如在游戏正体开始填充阶段的时候。

    关于SSS，在很早之前(还没有开始这个项目之前)就了解过，不过关于实时SSS方面的信息和知识，则是在这个项目开始后才开始关注的。专家们已经提出了很多实时SSS的方法，比如Spherical Harmonics(球谐函数、PRT)、Texture Space Diffusion、Translucent Shadow Maps等等。但是，TSM要求特殊的Shadow Map，而且还可能对Shadow Map做down sample；Texture Space Diffusion需要将光照先渲染进贴图，还要加工这个贴图；而PRT则是计算了整个光照对应情况，而且需要大量预计算时间。这些要么和OGRE的渲染流程相处不怎么河蟹，要么不够灵活(或者说是太麻烦？)。于是一直苦闷，想要找到一种效果不必那么好，只需要刚好能在人物的脸上使用就够的SSS或者伪SSS算法。

    上课无聊，只好各种YY，忽然阀门一转，回想起之前在查找shader新技术的时候找到的运用在HL2中的Radiosity Normal Map——辐射法线贴图RNM。RNM的思路是用贴图记录下某个点对各个方向的不同属性，虽然HL2中的RNM是用来记录辐射度以实现GI的，但是这并不表示RNM只能用来做这样的事情。如果我们吧RNM的那些基向量关于切平面对称一下呢？贴图中的每个分量都是向着物体内部的，每个分量的大小表示的是这个方向附近一块区域的衰减程度。

    具体是这样的

    考虑上图的情况。光照从上向下。下面的是当前渲染的像素。像素上的三个向量是RNM中的基，是处于切线空间的三个固定向量，虽然图上画的是3个向量，但是实际上我准备使用4个向量，基本上就是HL2的RNM的三个再加上一个和法向量相反的向量。总之，在这三个向量指向的物体的另一面的一块区域内设置采样点，计算每个采样点到渲染像素的距离(或者衰减系数toka)的平均值。将这个平均值记录下来(相当于基中向量的长度)，四个值刚好对应四个通道，可以用RGBA的贴图来存储。

    渲染的时候，将基中的每个向量乘上上一步中预制的长度值。再将光照方向变换到切线空间，并与基中的每个向量依次saturate(dot)，然后将这些结果值加起来。如此就得到了某个像素在某个光线角度时从内部反射出来的光强度，在这里我将其称为补光。接下来我们可以计算一般的带shadow的光照，最后把这个补光加到基础光照上面去。

考虑三种情况

1、点发线方向和光照方向很接近。

l为光照方向的向量取反，a1 a2 a3分贝为三个基向量

则saturate(dot(a1,l))=0

saturate(dot(a2,l))=0

saturate(dot(a2,l))=0

最后得到的补光为0

2、点向量方向与光照方向几乎垂直

这时候

saturate(dot(a1,l))>0

saturate(dot(a2,l))约等于0

saturate(dot(a3,l))=0

得到的补光>0

这里会出现这样的情况

    此时点发线、基向量和光照方向都相同。但是明显右边的情况下，入射光衰减的更重，因此， 点P处的补光应该是左>右。造成这样的区别的原因是，物体的几何结构的区别。而实际上，我们在计算基向量长度的时候就已经将物体的集合结构计算进去。因此，此处a1本就应该反映出其附近的衰减程度，也就是说这里的a1向量，左边的应该比右边的长。(好吧，我的表述能力很差，我的意思是。我们之前预计算的贴图会让我们得到近似正确的结果)。

然后是

3、点法线与光照方向几乎相反

这时候三个基向量与l的点积都>0。一般这样的情况是怎么出现的呢…

我想，大概是这样

也就是渲染的像素处于背光面。这时候的a2值不会太长。为什么？

因为计算a1a2a3长度的时候我们可以调整衰减的情况…

比如这样…这个要根据实际的光照模型来弄。

总之，就是利用RNM的原理，来做3S的方法。最后，这个方法其实只对没有变形的物体有效，但是对于脸这样形变并不是很严重的表面大概也适用吧。

上课orz /~

    话说前几天看了某视频教程(?)《动画师生存手册(The Animator’s Survival Kit)》(好吧，其实是某书的配套物的样子)于是蛋痛开始做小动画orz…发现没有想象中的困难，不过很费时是没错。那教程挺有意思的，至少补习了一些基本的知识。虽然教程教的是2D动画，不过发现对3D动画也挺有意义的。以后设计人物动作的时候说不定会用到…啊不，应该会用到。

接下来是场景和其他的一些奇怪(?)设定图了呢orz…什么时候才能开始建模啊。(众：拖进度的不是你么。) 最新版的人物设定图被船长形容为“有如FF7到FF8的变化”….各种意义上的泪目(囧。想画HCG啊(自重！

orz…另外，实验课开始了，每周的行动点数又下降了。