Gamebryo系列材质详解：二

以下内容，在讲解过程中要不时的用到那张表格，希望你可以在合适的地方放置一边对照以便查看。

材质系统并不难理解，大白话就是我们经常说的“导出”。就是说美术人员在利用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完成的。

3.所谓Shader Tree。对程序来说其实不难理解，就是一大堆function，或者说函数，或者说过程的片段。比如：世界坐标转换视坐标，光照的计算，Normal的计算，等等等等。当你在Max中用到这些选项后，他就会把所有用到的过程组织起来形成一个巨大的树状结构。所以叫ShaderTree。而这个树状结构就是一步步的流水线处理。好处不言而喻，坏处如果仔细想也能猜到。函数方法都被固定了，如果用光照，那么对于任何物体计算光照就一个方式，Normal也一样，如果你想做点个性的东西，对不起要么你自己组织ShaderTree(非常繁琐)，要么写自己的Shader。

gamebryo用哈希表来表示所用到的不同特性.比如是否有normal map啊,是否有darkmap啊.哈希表最终作为生成的材质脚本文件名.你可以看到有个generated文件夹下有些稀奇古怪的文件名就是那些了.注意他们是自动生成的.你不能做修改,或者说改了也没用.第二点,他保证了相异的功能不同名,哪怕只是很微小的差异.第三哈希表加快了文件名字符串匹配速度,能很快知道一个新模型用到的功能是否已经存在.另外在第一次进入游戏的时候会生成并且缓存下来,所以当游戏资源固定的时候是不会每次做这个工作的.所有的材质脚本的个数就是gamebryo所谓的自己的渲染管线的排列组合。如果你很熟悉可以推算出固定管线一共支持的描画方式的个数.更加详细的内容请查阅内核代码.
建议:
1.固定管线基本能覆盖绝大多数游戏中大部分物体的描画方式.毕竟这是总结了很多游戏以后的一个浓缩.不是随便想出来的.所以尽量使用他.
2.例外怎么办?首先肯定有例外.不可能有一个覆盖所有渲染方式的游戏材质系统,否则就自由成DX了,失去了设计的意义.
3.我们项目中也遇到过例外.解决方式第一如果是一个比较通用的例外,并且完全舍弃掉原来某些功能的使用方式，建议直接修改核心的shader tree.有点抽象哈,后面具体例子里我会讲.第二,如果是仅仅扩展某一项或者某几项功能,并保留固定管线功能,建议扩展自己的shader tree.其实1也可以按照2的方式来做,但是自定义shader tree是件非常麻烦的工作,代码量也很大.最后一种,自己写shader,如果仅仅为了某几个特殊物体的处理.或者与固定管线差距太大.

收藏到网摘:

[本日志由 volfmath 于 2010-04-29 10:10 AM 编辑]
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags:
相关日志: