2007年2月16日

最近同事购入一台wii，体积和一个光驱差不多大，另带传说中的双节棍和一张300多米的wii sports。。

高尔夫，网球，保龄球，棒球，拳击……个个就象个疯子一样在电视机前比划来比划去，绝对哼哼哈兮。提醒各位有意向购入wii的同志一定要在宽敞的场地PLAY，健身游戏两不误哈，怪不得那么受MM的欢迎。

目前来看，wii的走势是最好的，任天堂用了9个月就完成了预计12个月要赚的钱。要说性能，wii绝对不是360和ps3的对手。只能说人家有创意，玩得出新花样，毕竟游戏还是以GamePlay为主的嘛。再看看店里那些被搁置的PS3，不得不PF老任这个老江湖。。

刚好拿到SDK，翻阅了一下才知道为什么叫他GameCube2了，不论是硬件架构还是底层接口设计基本上和GC没太大变化，就连TRC也是在GC基础上直接修改的，orz一个。

  2006年8月11日

在MAYA中要获得通道信息，必须先连接到shader node上，也就是编辑环境中的材质球这个概念。
然后通过findPlug这个接口去访问color这个属性，一般这里放的是diffuse map，具体可以参考SDK里的fileFindTextures例子。
但是很奇怪的是，SDK里的例子没有介绍如何访问其他通道的方法，而且一些开源的插件也仅仅导出一层图。

那么，先看一下diffuse map导出的过程：
在访问到color属性后，SDK的例子是通过调用MItDependencyGraph得到对应的MFnDependencyNode，
然后询问ftn属性取得结点所包含的纹理名称。
我们不妨从现有的基础上出发，做一下尝试。

Test1：
用shaderNode作为根结点构造MItDependencyGraph，遍立整个Graph，输出每个结点包含的纹理信息。
Result：
所有被使用的材质信息都可以导出，但是具体是属于哪个通道是无法确定的。

Test2：
还是使用findPlug这个接口，但是需要填入attribute，其他通道的attribute都是些什么呢？
window->General  Editors->Connection Editor...
load之后会显示任何选种物体的可连接对象，所以，我们需要的attribute就全在这里了。
原来bump channel用的是normalCamera，谁会猜得到呢。。
接下来的步骤就和导diffuse map一样了，而且同时还可以知道对应的通道 :)

Maya的文档中缺少FAQ，而且例子代码也很久没更新。使得开发人员在碰到问题时感到束手无策。
这点Max做的还行，Discreet提供了一个专门的BBS，并且在SDK中还有帮助文档。
实在找不到文档的时候，可以试着学习一下工具的使用流程，或许可以从中得到一点启发。

  2006年2月25日

抱着一颗好奇的心，参加了PCHOME主办的XBOX360见面会
虽然网络上早已流传不少游戏的截图，但游戏的实际运行效果才比较有说服力
这次展出的3个游戏分别是COD2，PGR3和DOA4
说实话我是觉得有些失望的，当然除了没能亲手体验一把，介绍游戏的都是玩家这两个因素
关键是画面的质量上完全显现不出1080P的威力，可以说目前的顶级配置PC是完全达得到相应的效果的

倒是UBI的开发人员介绍的360开发环境来得更精彩一些
对于拥有3颗IBM POWERPC的360，同时处理多个模块游刃有余
随着AI和PHYSICS的模拟日益成熟，在游戏中所占的比重也日渐增加
单芯片显然已经无法继续承受更多压力，3芯片恰好能完美得并行处理这3大模块
也就是说，如果把360利用到极限，其芯片的处理能相当于一块9G的芯片，显然时下不可能有这样的芯片
同一个游戏可以达到以前的3倍性能？难以想象……
GPU方面，除了SM3.0的一些新特性，免费提供4xAA还是很诱人的

另外，编译器也提供了一些有趣的功能
比如说我们知道，内联函数节省了函数调用的开销，从而提高执行效率
但是一些不恰当的内联函数，函数的展开并不比调用及返回来得开销小
在360的开发环境下，可以让程序执行多次后，自动决定哪些函数使用内联

最后是XNA，自己不是很了解，只是在DX的文档里和它见过几面
回来查了一下，发现这家伙的来头还真不小
自从M$在前两年的GDC上提出XNA的口号时，就引起了不少知名开发商的支持
它的主要目的是作为下一代的开发环境，对所有平台，目前已有的开发环境以及一些新的特性的整合
以帮助开发者在创建更加优秀、快速和跨平台的游戏时能够减少费用
（注：这里指的平台是windows, winCE和Xbox）
也就是说，以后再也不需要做XBOX到PC移植这种“愚蠢”的事了
XNA Studio将发布一个由统一的文件格式驱动的改进了的构建架构，并以此来解决工作流问题
该构建框架由一个集成的工具套装构成，能够为所有团队成员优化游戏生产流程
看来，M$又为广大人民搭好了架子，让大家开始新一轮的开发……
XNA工具将包括DirectX和High-Level Shader Language (HLSL)、XACT、PIX和Xaudio API，以及其他开发工具如Visual Studio 

  2006年2月4日

List? Strip? 想都不用想，肯定是strip更有效率咯
最优的VB和IB，传输速度上是最快的，而且还有相当的cache命中率
但是试验下来却发现两者不分伯仲……算法看了几遍都没发现问题
现在才意识到又是关系到硬件，OMG！
至少在A卡上，优化过的list和strip是执行效率是差不多的
NV则更偏向strip，具体还需要测试一下……

恩，在论坛上找到了许多相关的讨论，而且有趣的是相当一部分人都提到了indexed list要比strip快
ogl的文档里也提到Triangle lists in strip order are recomended by ATI while NV perfers tri-stips
但无论怎么说，其本质就是post-T&L optimization，减少page cross

PS:nv的lib中RemapIndex就是用来优化局部空间的排列，接口是xbox小组提供的
而据说GenerateStrip等主要接口也由Blizzard的程序员重写过了，呵呵

  2005年11月15日

前几天下了极品9的DEMO，这款游戏给我的感觉一直就是两个字：爽快。所以新作上市还是要给EA面子，跑一下看看整体运行的效果。

本人的机子算是够烂的了，差不多是极品9的最低配置了吧...在网上也看到不少用9550跑的火星贴，正好给了我死撑一下的动力，顺便看看人家的优化做得怎么样

最为关心的就是3D选项了。但是很奇怪的是，在shadow这一项竟然是灰的，不让我选...我这128的卡做做shadow map应该还是没问题的吧，不知道EA是怎么想的。world和car LOD用的是低精度的，怕调上去面数太多，影响帧数。cubemap的更新率也没＋到顶...最后把所有的post processing全部打开。进去兜了半圈就郁闷了，帧数只有20多，极大地影响了我的情绪...

以下是我发现的一些问题：第一感觉，地面还是很烂...这基本上要成为极品的招牌了。为什么不给地面加上一层detail纹理呢？还是因为速度上去后这些问题会被忽视？要知道看上去真的很倒胃口。默认的阴影中树影是假的，应该是预先加在赛道纹理中的，并不是实时处理的。可能是对于不支持shadow buffer的显卡，EA都用这招了吧，狠的。。。还有就是cubemap，没有用实时更新看上去是跳帧的感觉，还不如不开。另外，提速到有motion blur后，帧数也会明显下来一点。网上有人抱怨blur后看不清路了，看来不适合打赛车游戏，没有特效速度感怎么能体现出来呢。

还是不死心，出去把分辨率调到了640*480，反正也就这么点能耐了。然后索性把AA和AF全都打开。事实证明为了效果，还是可以牺牲点其他的。而且发现不开AA AF的游戏简直不堪入目。。30帧！也算完完整整得跑了一圈。最令人印象深刻的是bloom效果，特别是天空，而且出隧道一瞬间会眼前一片白茫茫，感觉很不错。跑车的设定也很赞，不论是轰鸣的引擎声或是提速带来的快感，给人狂放不羁的感觉。看来EA在优化上也下了功夫，让我这台“老爷”机也跑到比较流畅，当然还看到了大部分的效果

  2005年10月16日

做shadow map最方便的方法当然是通过硬件的支持，直接获得DST。但很不幸，只有NV的GF3+支持。
这大大提升了渲染的效率，看了网上的一些相应的文章，别人在做3DMARK测试时往往都是把使用DST关闭的。这样测试A卡和N卡才比较公平，不然N卡的“优势”就太明显了。庆幸的是，ATI终于在最近的SDK里放了一个hw shadow map的例子（9700 pro+）^ ^

我这里只有块9600，所以只好用最原始的方法来做shadow map了。。。
用了32bit fp texture作为render target，因为要从场景中取z写到depth map里（也可以用rgba8格式的，但是就要牵涉到depth的encode/decode了）
然后第二步正常渲染时在shader里做z compare（硬件支持的话这步就免了，硬件本身会提供返回值，0 shadow 1 lit）
而且N卡还会额外的替你柔化阴影（PCF，真是考虑周到啊。。。），不过事实上并不是用了真正的PCF，而是以线性过滤来代替（那为什么还号称是PCF）不过4 samples的PCF同样也可以达到该效果，而且不会太影响效率。



左上角是depth map，右上角的是RGBA encoded depth map（light's POV)

  2005年2月24日

好久没有更新了，不过实在是没有新的作品
很少有时间写自己的东西了，最近也就重建了framework，正在加入D3D的部分
skinnedmesh已经写得差不多了，现在在看stencil shadow
 

z-pass:

分别渲染shadow volume的正面和反面，视线经过正面depth test时stensil ＋1，经过反面depth test则－1。
最后得到stensil值不为0，说明该区域在阴影中。
但是，z-pass的致命缺点在于当camera在阴影中时，得到的stensil值会导致错误的结果。

z-fail:
同样根据shadow volume的正面和反面来计算stensil的值，区别就在过正面－1，过反面＋1
这样，即使在阴影中，也能得到正确的stensil值。与前者正好相反。也叫Carmack's Reverse（Carmack给Mark Kilgard的mail中提出的）
此外，该方法还需要一个闭合的volume，并且令前后的两边都为反面。这样也就增加了计算量，渲染速度当然就不如前者了。

两者各有优缺点，因此应该根据实际情况来选择。