gamebryo中的管线

Gamebryo中的对象系统之一：智能指针和引用计数

GameBryo提供了一太基本的模板容器类，这些容器在整个库内使用。

Lists

NiTPointerList对象可以包含和管理指针，智能指针，以及其他任何大小小于等于指针的元素，该链表可以有效的插入和删除所有元素，以及正向遍历和反向遍历所有元素，同样可以通过给定值查找元素的实体和所在位置，NiTPointerList的元素的内存是从一个共享内存中分配的，从而提高类的执行速度和内存效率，如果链表元素大于指针，程序可以使用NiTObjectList.

Array

NiTArray对象实现勒几乎可以包含所有对象的动态数组，该数组可以缩放，并且可以压缩(通过转移元素来移除空空间)。内置类型(char*, float, int等)使用NiTPrimitiveArray。NiMemObject派生出的类型使用NiTobjectArray。注意NiTArray的元素上限为65535；如果大于该限制，使用NiTLargeArray派生出的类，比如NiTLargePrimitiveArray或NiTLargeObjectArray。

Map

NiTPointMap对象实现勒哈希表的功能，允许任何类型的键值来影射到指针，智能指针，以及其他任何大小小于等于指针的元素，并能快速的储存和查找键值对，不过不能使用字符串键哈希表，而NiTStringPointerMap对象是专为此设计的，NiTPointMap和NiTStringPointerMap的元素内存也是从一个共享内存中分配的，从而提高执行速度和内存效率，如果map元素大于指针，程序可以使用NiTMap和NiTStringMap

StringMap

NiTStringMap和NiTStringPointerMap对象的函数和NiTMap和NiTPointerMap风格类似，但是允许字符串作为键，并且通过字符串比较来进行键散列

FixedStringMap

NiTFixedStringMap对象函数和NiTMap对象风格相似，但是允许NiFixedString对象作为键

Queue

NiTQueue实现勒基本所有类型对象的先进先出队列，但不提供智能指针，需要注意链表可以当做队列来使用

Set

NiTSet实现了基本所有类型的无序集合，也没提供智能指针，内置类型(char*, float, int等)使用NiTPrimitiveSet。NiMemObject派生出的类型使用NiTobjectSet，智能指针则使用NiTObject或者NiTPrimitivePtrSet，这将正确的处理引用计数。

Pool

NiTPool实现了小型对象的池，使得程序能通过一个池来分配小型对象，并能重复使用，而不是单独的去分配和释放一个小型对象

一个程序会在需要的时候改变一个节点的转换，计算该节点的时间转换，以及该节点子节点的其他转换将被延迟，直到应用程序调用例行的update。

update是高效使用深度优先来遍历子图计算世界转换和世界包围球，从而最大限度的减少节点的访问，当向下递归时，转换被更新，包括所有的自节点，当矩阵更新后，世界包围球通过递归调用返回

总之，转换在递归中被更新，而包围球在递归返回时得到

通常大多数的对象都不会移动的，所有只更新只限于小部分可以移动的对象。在场景图的数据处理初始化中，当应用程序使用到场景图前，至少要对场景图的根节点进行一次例行update，这样保证所有节点的世界信息及本地信息都是最新的。

在应用程序帧到帧的运行中，当符合下面任何一条时，应用程序必须调用对象“O”的update。

·O被绑定到父亲节点或者从父亲节点解除绑定

·O绑定了一个新子节点或者解除了一个子节点的绑定

·O任何一个转换被改变

注意一下，调用当前发父亲节点或者任何祖先节点的update可以代替当前节点update的调用。例如，如果对象A绑定了子节点B和C，只需要调用A的update就够了。没有必要调用三个对象的update，应用程序会以批处理的方式更新。

例如，当应承需要改变了一个活动角色的所有的关节矩阵，他应该推迟update直到所有的改变都完成，并且只需要调用一次角色根节点的update。

但是，注意update尽量在场景图的更下层调用，如果一个场景图每帧只有一个叶子被改变，那么调用根节点的update就太过分了，这将降低性能。

为了世界中对象只需要少量的顶点，一棵树可以用来代表场景图，每个对象被单独表现为树中的节点。但是，在绝大多数场景图中，会多次出现一个需要大量内存来存储的复杂对象，绝大多数的内存是消耗在纹理和顶点数据上，比如纹理坐标和法线。

如果一个应用程序需要多份这样一个对象，是有可能通过共享的NiDataStream来分享模型空间的几何信息，颜色，纹理和其他颜色。换句话说，若干网格对象可能分享NiDataStream对象，在这种情况下，场景图是有向非循环图，而不是一棵树。

在几何数据共享的情况下，叶网格对象共享NiDataStream对象的模型空间网格。但是,两个模型数据的实例是在世界的不同位置,因为他们代表的多个网格对象,并且每个副本自己单独的转换。

这些管理是在应用程序的内部透明处理的——应用程序只需要建立两个网格对象使用同一个NiDataStream对象。网格对象甚至要比一套最小的网格数据小的多，因为网格对象不像数据流，不存在每个顶点的数据

下面的图象是一个典型的情况：

                                            (两个网格对象使用同一个NiDataStream)

两个叶网格对象分享一个轮胎NiDataStream对象的顶点位置和法线。一个网格对象对应到自行车的前轮，另一个对应到自行车的后轮。NiDataStream对象自身存储的网格顶点的位置和法线被共享，两个网格对象都保存表现自己网格的转换。

注意以下，Gamebryo不为任何类型的NiAVObject提供多父亲的功能。绑定一个已经拥有父节点的对象C，会导致C自动脱离原来的父节点

Gamebryo通过一套相互独立的渲染性质为每个能渲染的叶子对象定义了渲染属性，每一个渲染属性都为能渲染的对象定义了某一方面的渲染状态，并且都是NiProperty的子类。对个可渲染的对象可以共享渲染属性。针对一个对象的完整渲染状态是所有属性的完整组合。当属性状态对象存在与NiRenderObject叶子节点时，这个个体渲染属性就被绑定在场景图的任何NiAVObject上。这正式用于每个可渲染叶子对象产生属性状态的每个NiAVObject的属性。一个属性被绑定到一个NiAVObject将影响所有子数上的子对象(包括它自己)，除非在子树中同样的属性类型被其他属性所替代。如果没有任何属性被设置到场景图的对象上，该对象会通过合适的默认属性来绘制。每个属性类型的默认相当于为该类型设置一个默认构造，每个NiAVObject都包含了一个绑定与它的所有属性的链表，一个NiAVObject可能没有任何属性绑定，也有可能绑定一个或多个属性。所有的方式达到一个NiAVObject能绑定的每样属性的最大值。注意确保应用程序任何时候都不能给单一的NiAVObject绑定一个以上已经类型的属性。一个单一的NiAVObject绑定已经类型的一个以上的属性会导致奇怪的视觉效果和未知的问题。

绘制属性类型

NiProperty对象在Gamebryo中的数据层次如下：

NiObject

              NiProperty

                              NiAlphaProperty

                              NiDitherProperty

                              NiFogProperty

                              NiMaterialProperty

                              NiShadeProperty

                              NiSpecularProperty

                              NiStencilProperty

                              NiTexturingProperty

                              NiVertwxColorProperty就如上面讨论的，属性设置从根到叶层次。一个被绑定到NiAVObject对象的属性会影响该对象及它的子对象。除非在更低的子树中绑定该类型的其他属性。因此，一个可渲染叶节点的当前状态是由场景图中它祖先的链所决定的

                              NiWireFramProperty

                              NiZBufferProperty

更新属性到集合物体上

Gamebryo会让整个场景图保持绑定属性，绑定在每个可渲染叶对象的属性状态是包含所有提供的类型的属性的数组，这样，每个可渲染的对象包含一个直接指向用来绘制的渲染属性的指针。这很重要，因为渲染只涉及可渲染的叶对象，而不是整个场景图。于是每个可渲染对象的属性状态都是继承其他可渲染对象的所有属性的副本。

Gamebryo使用一个系统类似使用NiAVObject::Update函数来更新这些属性状态对象。这个类似的渲染属性函数是NiAVObject::UpdateProperties。当出现下面的情况UpdateProperties必须在obejct"O"或任何一个他的祖先调用下一次渲染

·一个以O个根节点的树刚被创建

·一个属性被绑定到O或从O移除

·O被绑定到节点P或从P上被移除

注意，当只改变了一个已有属性，应用程序不需要调用UpdateProperties。

要实现最佳性能，这些UpdateProperties的调用可以以相同的方式进行批处理来执行批处理更新,如果应用程序将在子树上绑定或解除绑定许多属性，它必须调用所有的绑定或解除绑定函数，然后在子树的根部调用一次UpdateProperties，通常的，因为属性和子节点的绑定和解绑没有每一帧这样频繁，所以UpdateProperties要比每帧积累属性快的多，但是对于程序员。将多出一个额外的小负担。

软粒子主要是为了解决粒子广告牌和场景几何相交时，产生的生硬边缘，如下图烟雾与地面相交时的边

为了解决上面的情况，我们需要用到场景的深度信息，如下图：

在一般的渲染管线中，点P3就是产生生硬边的点，为了改善这种情况，SoftParticles通过改变粒子的alpha值来处理粒子后面的场景，这里使用了自定义的shader常量来决定距离d以便我们调整alpha值（d为world place中），任何距离原场景深度大于d的粒子相素我们将不处理他的alpha值(对应上图P1的公式)，

上图中点P1正好达到该距离，点P1到P3的alpha混合程度会递增，距离d设置的越小，那效果就越接近于硬粒子的效果，因为P1的条件很容易满足，对alpha值的修改会减少，但是如果距离设置的过大，那P2就很容易满足，这样导致Len/d产生的值很小，让粒子变的很透明，造成的粒子很稀疏，具体的效果要自己手动调节。

这种边缘软化的方式只是近似的，当场景的法线于摄像机方向锤子时会失效，当出现这种情况时，随便粒子与相交面很接近了，但因为摄像机与相交面近乎垂直，而粒子相素的深度检测是沿与摄像机方向的，从而产生一个很大len值，导致了本来应该成为P3效果的点，成为P1。

DEMO5个类，SoftParticles，MRT_ColorDepthMaterial，SoftParticlesMaterial，SoftParticlesManager，MRT_ColorBlackMaterial

SoftParticles::CreateScene()

负责创建场景，从Nif文件中获取场景，摄像机及粒子系统，设置alpha排序，剔除，及默认材质MRT_ColorDepthMaterial, MRT_ColorDepthMaterial继承于NiStandardMaterial，重载了函数bool HandleFinalVertexOutputs()和函数bool HandleFinalPixelOutputs()，这两个函数分别在vertex shader和pixel shader的最后执行，通过HandleFinalVertexOutputs函数，为vertex shader的output结构增加成员NiMaterialResource* pkVertOutViewTexCoord = Context.m_spOutputs->AddInputResource("float4", "TexCoord", "World",
"PosViewPassThrough");作为纹理坐标的格式输出

NiMaterialNode* pkSplitterNode = GetAttachableNodeFromLibrary(
        "PositionToDepthNormal");
    kContext.m_spConfigurator->AddNode(pkSplitterNode);
    kContext.m_spConfigurator->AddBinding(pkViewPos,
        pkSplitterNode->GetInputResourceByVariableName("Input"));
    kContext.m_spConfigurator->AddBinding(
        pkSplitterNode->GetOutputResourceByVariableName("Output"),
        pkVertOutViewTexCoord);

获得自定义函数PositionToDepthNormal，将pkViewPos作为传入参数，把新增的pkVertOutViewTexCoord作为输出参数

而HandleFinalPixelOutputs则在输入结构中增加float4 WorldPosProjected : TEXCOORD6;代码如下

NiMaterialNode * pkInputResource;
    pkInputResource = kContext.m_spConfigurator->GetNodeByName("PixelIn");

    NiMaterialResource* pkDepthFromVP = pkInputResource->AddOutputResource(
        "float4", "TexCoord", "World", "WorldPosProjected");

然后在输出结构中增加深度颜色，通过WorldPosProjected来赋值，CreateScene()还将场景中所有的粒子系统添加进SoftParticlesManager，添加完所有的ParticlesSystem后，SoftParticlesManager通过Initialize()函数，创建默认的粒子材质，以及SoftParticlesManager自己的RnderView及click,然后通过InitializeScene()为每个粒子系统设置材质，并添加进RnderView,这里要注意执行顺序

该函数中，通过获取后备缓冲的属性，来创建相同一张texture，用来渲染深度，不过格式要设置为NiTexture::FormatPrefs::SINGLE_COLOR_32，表示32位的单通道颜色，用R通道表示，然后新建一个RenderGroup，要包含原来的后备缓冲以及先建的位图缓冲，让场景同时渲染到这两个缓冲上，并将纹理缓冲作为SoftParticlesManager中创建的click的一个输入

MSAA(MultiSampling Anti-Aliasing)

GB中MSAA实现的关键代码基本是直接用的D3D，除了自己的渲染批次系统，DX9不能直接对渲染到纹理启用MSAA，但是提供了渲染表面surface,可以对surface启用MSAA。

实现的关键步骤大致如下

1。NiRenderedTexture::Create创建一个和背景缓冲一样大的RenderTexture，NiRenderTargetGroup::Create利用RenderTexture创建RenderTarget，屏幕最终渲染的目标就是该RenderTarget，我们需要的也是将MSAA后的数据给RenderTexture

2。通过D3D的CreateRenderTarget按照自定的MSAA级别来创建surface，利用surface的buffer创建另外一个MSAARenderTarget

3。新建一个RenderView，GB中用的NiScreenFillingRenderView，就是D3D中四个顶点组成的矩形，该RenderView绑定一个baseTexture为步骤1所创建的RenderTexture的NiTexturingProperty，创建RenderClick挂接该RenderView，并设置一个CallBackFunc，然后将该click插到mainClick后面，这样用两pass来完成MSAA

4。主click将画面渲染到开启MSAA的MSAARenderTarget，然后进入新click的CallBackFunc，获取MSAARenderTarget的buffer，用D3D的StretchRect复制数据到RenderTexture，这样新click就会渲染出进行MSAA后的texture

引言：

GameByro作为一款次世代引擎，使用了复杂的材质系统，用来满足各种各样的需求。材质代表了物体受到光照后所呈现出的质感，而这种质感在计算机图形学中需要着色代码来完成，所以当前流行的图形引擎设计是使用被渲染对象的材质与shader相关联，GameByro也不例外。GameByro的材质系统可以通过shade tree生成shader程序，增强了应用程序层对可编程渲染管线的控制能力。

渲染架构概览：

在GameByro中，对象表面的色彩、纹理、光滑度、透明度、反射率、折射率、发光度等可视属性与传统的材质系统分离，独立的成为了对象的渲染属性（NiProperty），而材质（NiMaterial）仅用来对着色程序的封装，这样就实现了渲染数据和渲染方法的分离，降低了耦合性。如上所说的这些可视属性在Gamebyro中会封装成一个属性对象，在应用程序中如果对对象挂载这个属性对象，在GPU程序中就可以访问这个属性对象的值。渲染属性对象可以在创建时指定其类型，如纹理、浮点、矩阵、向量或数组，此外一些全局性的对象也可以通过在Shader中用语意声明为全局object对象，如灯光和摄影机等，这样就可以以同样的方式来访问这些对象上的属性。

GameByro每一帧的渲染（NiRenderFrame）划分为多个步骤（NiRenderStep），每个步骤又包含很多个批（NiRenderClick），NiRenderFrame封装了上层对渲染系统调用的接口，而NiRenderClick则代表了图形硬件的一次绘制操作（对渲染队列中所有的对象的顶点缓存调用DrawPrimitive），当应用程序调用NiRenderFrame的Display接口时, NiRenderFrame会依次调用每一个NiRenderStep的Render()接口，NiRenderStep就会执行所有的NiRenderClick操作。

对于每个NiRenderClick来说，首先要设置视口和渲染目标，也就是渲染数据流的入口和出口。视口建立以后就可以通过关联的摄影机对场景图中的对象进行裁剪（默认的有视口裁剪和遮挡裁剪，此外还可以通过回调函数加入自己的裁剪方式），将未被裁剪的对象放入渲染队列。然后Gambyro会根据材质来对渲染队列中的对象进行排序，让材质相同的对象处于相邻位置，这样可以减少切换shader的开销。

如图所示为帧渲染系统的结构图（简化版）

材质系统：

GameByro中的材质代表渲染对象所采用的方法。前面说过。纹理属性包含了着色所需的原料，那么材质就指定了对这些原料的加工方法。基于当前可编程渲染管线设计，材质就成为连接对象与GPU程序的中间层，应用程序可以通过材质将shader应用于几何体。

NiMaterial类是所有材质的基类，这个类通过一个Map来保存当前应用程序中所有NiMaterial的指针，当然这个Map是静态也就是说相当于全局变量，通过static NiMaterial* NiMaterial:: GetMaterial(const NiFixedString& kName)接口对这个全局的Map进行访问。也就是说，当前环境中所有的NiMaterial对象是通过NiMaterial类来管理的。此外NiMaterial类还通过静态成员变量保存了一个工作路径（即shader文件路径），通过这个路径加载shader文件。NiMaterial就像是一个中介，全权代理对对象的渲染工作。用户可以通过重载NiMaterial来实现自己的渲染机制。每个NiMaterial都是全局性的，可以作用于多个甚至是所有的渲染对象，但一个渲染对象也可以拥有多个NiMaterial，但只能有一个处于激活状态的NiMaterial。

NiMaterial的派生类NiFragmentMaterial提供了对可编程渲染管线完整的控制机制，内部保存了NiShader的哈希表、一个NiGPUProgramCache数组。并且NiFragmentMaterial会生成一个用来编译GPU程序的shade tree（后面会有解释）。这样的话，每个NiFragmentMaterial可以对应多个shader程序，这样就提供了一种机制，在运行时根据不同的运行环境和渲染对象不同的状态，来选择合适的shader程序。在NiRenderClick依次渲染可见集中的每个对象时，首先会判断其是否需要被渲染的标记（flag），如果需要被渲染，则使用NiMaterial::IsShaderCurrent接口判断当前shader（上一次渲染所使用的shader）是否有效，所谓有效就是仍然存在并且可以应用于本次的渲染对象，如果无效，则会调用NiMaterial::GetCurrentShader获得shader，用于本次渲染。NiMaterial::GetCurrentShader会根据渲染对象的属性和当前环境硬件条件来选择合适的shader程序。当然，可以通过重载IsShaderCurrent和GetCurrentShader接口来指定自己的有效性判断规则和如何选择shader程序的方案。 NiFragmentMaterial提供了一套搭建shade tree的框架，用户可以通过重载来搭建自己的shade tree，当然，如果不想通过shade tree的形式生成shader程序也可以，使用NiSingleShaderMaterial可以从文件生成shader程序。

Shade Tree：

什么是shade tree呢？我们通常编写的shader代码是线性执行的，即每个pass流程执行的是文本上定义好的shader流程，每一段shader功能模块是按一定顺序依次执行的。如果需要修改流程中的某一部分就需要更改相关的shader代码并重新编译。而shade tree将shader代码以树形结构组织起来，每一个shader代码块（一般是一个函数）都会被编译成一个节点，通过定义输入变量和输出变量来提供数据流的入口和出口，这些节点的插入和删除可以通过应用程序来控制，从而灵活的控制整个渲染过程。这样shader程序中的一些核心模块可以由美术通过工具生成，然后插入到shade tree中，只要输入和输出的接口不变，就无须修改其他代码，从而降低了美术开发shader的门槛。

GameByro通过以下几个类搭建shade tree:

l NiMaterialConfigurator：shade tree被封装在这个对象中，Uniform constants被封装在NiMaterialResource中，而NiMaterialNode封装了相关的shader代码，所有的资源和节点通过NiMaterialResourceBinding连接起来。当所有的连接都确立以后，NiMaterialConfigurator会调用Evaluate接口生成GPU程序和一个输入Uniform资源的集合。

l NiMaterialFragmentNodes：这个类包含了一个shader代码片段的集合，这些代码片段为不同的平台和编程语言所编写。这就为shader程序员提供了更大的灵活性，用以控制他们的代码在不同平台和图形硬件上的表现。例如：在高端平台可以采用高级的shader model提供更好的效果，而在低端平台上可以关闭一些特效来加快速度。

l NiMaterialNodeLibraries：这个类是一个NiMaterialNode的集合，其实也就是一个shader库。它允许shade tree节点完全基于数据驱动。shader库的生成可以通过两种方式，解析XML文件或用XML文件生成C++代码。GameByro提供了相关的解析器和代码生成器。

l NiMaterialResources：shade tree中的Uniform constants，支持多种数据类型，包括Constant、Predefined、Attribute、Global、Object。

固定管线的渲染：

GameByro支持固定管线的渲染，其纹理混合过程如下。

固定管线的着色处理流程

上图很清楚的显示出了每个stage的操作，平行的表示两张纹理的采样是同时进行的，特定情况下右边的纹理可能被忽略。

大部分情况下，应用程序不会使用上面所有的stage，开启或者关闭那个stage可以由应用程序来指定。

以下为多重采样的原理图:

固定管线的纹理多重采样

缺省的着色处理流程：

GameByro提供了一个默认的着色处理流程，封装在NiMaterial的派生类NiStandardMaterial中，这个类执行类似于固定管线的流程，在不同阶段将纹理采样、并将采样到的数据混合到最终的结果中去。

GameByro默认的材质系统的特性如下：

• Skinned and unskinned transformations. Skinned transformations can support up to 30 bones per draw call.
• Vertex colors
• Base maps
• Normal maps
• Parallax maps
• Dark maps
• Detail maps
• Bump environment maps
• Gloss maps
• Glow maps
• Decal maps (up to 3)
• Cubic and spherical environment maps
• Point/Spot/Directional/Ambient lights contributing to the diffuse, specular, and ambient color. Up to 8 total lights. Per-pixel or per-vertex.
• Projected light maps. Clipped or unclipped. (Up to 3)
• Projected shadow maps. Clipped or unclipped. (Up to 3)
• Texture transforms per map.
• Per-vertex fog

下图显示为不同的纹理、灯光、材质属性的组合过程，不过需要注意的是，视差贴图和凹凸贴图属于特殊的情况，它们仅仅影响到纹理采样的UV坐标，而并非直接对最后的颜色值产生贡献。视差贴图会改变所有贴图采样的UV坐标，而凹凸贴图仅对环境贴图的UV产生影响。

以上流程完全由shade tree构建，NiStandardMaterial提供了大量的函数接口用于对每个流程的控制，用户可以通过重载相关的接口，插入自己的shade tree节点，修改每一步的操作或处理过程。例如：

virtual bool HandleBaseMap(Context& kContext, NiMaterialResource* pkUVSet,

NiMaterialResource*& pkDiffuseColorAccum,

NiMaterialResource*& pkOpacity, bool bOpacityOnly);

当然，整个流程的顺序和结构修改起来比较困难，如果有需要可以定制自己的材质系统，搭建自己的shade tree。

NiStandardMaterial提供了若干回调函数，这些函数可以动态的修改流程，分割PASS，对shader运行失败进行容错。

l SplitPerPixelLights/SplitPerVertexLights:这两个函数分别作用于逐顶点光照和逐像素光 照，当物体所受的光源数量太多，超过了顶点或像素着色器的能力时，通过这些函数可以将失败的pass分割成两个，如果分割出的pass仍然不能执行，那么函数会被递归调用，直到每个pass只有一个光源为止。

l SplitTextureMaps：这个函数会把对纹理采样的pass进行分割，当纹理查询过多时，顶点或像素着色器就会过于复杂，这时就可能导致shader运行失败。此函数只能迭代一次，生成一个额外的pass。

l DropParallaxMap：这个函数用来从几何体上移除视差贴图，且不产生额外的pass。

l DropParallaxMapThenSplitLights：这个函数首先调用DropParallaxMap移除视差贴图，然后一直调用SplitPerPixelLights直到失败为止。

NiMaterialInstance：

NiMaterial并不是直接与NiRenderObject相关联，而是经过了NiMaterialIstance这个中间层，由它来代理将NiMaterial关联到几何体，它负责调用NiMaterial为NiRenderObject生成NiShader，通过改变NiMaterialIstance上的接口SetMaterialNeedsUpdate，可以决定每一帧NiRenderObject所使用的材质是否需要被更换，通过接口SetDefaultMaterialNeedsUpdateFlag，可以决定当前材质所需的数据（即当前渲染流程所需的数据）是否要被更新。这样每个NiMaterialIstance只能被一个NiRenderObject所拥有，而多个NiMaterialIstance可以共享一个NiMaterial，这样就减少了重复创建NiMaterial的时间和空间上的开销，同时降低了渲染对象个材质之间的耦合度。

如下为材质系统的类结构简化图：

渲染属性：

前面提到过，GameByro将渲染所需要加工的数据全部封装在了NiProperty中，只要在shader中用指定的语法进行声明，就可以访问这些属性的值。

目前引擎中已经定义了12种属性，均派生自NiProperty，分别代表渲染数据的12种不同类型：

l NiAlphaProperty

l NiDitherProperty

l NiFogProperty

l NiMaterialProperty

l NiRendererSpecificProperty

l NiShadeProperty

l NiSpecularProperty

l NiStencilProperty

l NiTexturingProperty

l NiVertexColorProperty

l NiWireframeProperty

l NiZBufferProperty

用户也可以自定义属性类型，但所对应的数据类型要被shader语言所支持。

光照与阴影：

光照与阴影密不可分，因为阴影就是由光照产生的，前面在材质系统中已经提到过光照对着色的影响，这里重点阐述，GameByro是怎样根据光源产生阴影的。由GameByro提供的阴影均基于ShadowMap技术，

但也提供了ShaowVolume的示例代码。

Shadowing System是完全建立在帧渲染系统上的， 通过一个RenderClick生成ShadowMap，然后在正常渲染流程开始之前将ShadowMap更新到可见集内每一个渲染对象上。这样当渲染对象使用NiStandardMaterial时就会根据光源的阴影技术来对ShadowMap进行采样，并将结果与最终的输出颜色按一定比例混合。

阴影系统由以下几个类构成：

• Shadow Write Materials:从NiFragmentMaterial派生，封装了生成 ShadowMap的算法和着色程序。

GameByro提供了三种类型的Shadow Write Materials，分别为NiPointShadowWriteMaterial、

NiDirectionalShadowWriteMaterial、NiSpotShadowWriteMaterial，适用于三种不同的光源类型。

• Shadow Technique:这个类封装了阴影算法的细节，包括生成ShadowMap和使用ShadowMap投射阴影。
• Shadow Render Click: 这个类是一个生成ShadowMap的批，这个类的对象是由shadow click generator负责生成。
• Shadow Click Validator: Shadow Render Click:通过此类对象判断接受阴影的几何体对于shadow generator来说是否可见。
• Shadow Map: 每个ShadowMap对象包含一个作为阴影图的纹理，shadowmap对象由shadowManager直接管理，每个shadowmap对象都被一个shadow generator引用。
• Shadow Cube Map: 同shadowmap作用相同，只是阴影图的纹理类型为CubeMap。主要用于点光源生成的全方向阴影。
• Shadow Generator: 阴影生成器，每个ShadowGenerator都对应一个NiDyamicEffect（NiLight的基类），也就是为这个NiDyamicEffect代表的光源生成阴影， 生成阴影所采用的技术由对象引用的ShadowTechnique来决定。
• Shadow Click Generator: 生成ShadowMap的Shadow Render Click都由此类负责创建。这个类为每个ShadowGenerator指定ShadowMap，并负责每帧更新ShadowMap和ShadowMap所对应的变换矩阵。
• Shadow Manager:所有的ShadowMap、ShadowTechnique、ShadowGenerator、shadow render click对象都由ShadowManager统一管理，并负责使用一个shadow click generator 在每一帧生成一个shadow render click的列表。

阴影系统静态结构如下：

整个阴影渲染的流程大致如下：

1. 在应用程序初始化阶段，通过调用NiShadowManager的Initialize()接口实现对整个阴影系统的初始化，此时应用程序会注册所有的ShadowTechnique，并初始化NiShadowClickGenerator。

2. 当我们创建一个NiLight以后，我们可以通过NiShadowManager为这个NiLight新建一个NiShadowGenerator，NiShadowGenerator会通过NiLight的类型来选择合适的NiShadowTechnique，此时NiShadowManager会为新的NiShadowGenerator创建一个NiShadowRenderClick。

3. 当帧渲染系统启动后，NiShadowRenderClick的PerformRendering()接口会被调用，此时NiShadowRenderClick会通过引用的NiGenerator获得阴影生成的着色程序和所需的数据（例如深度偏移），同时通过NiGenerator引用的Camera获得场景图中的可见集。下一步就是对可见集中的渲染对象添加ShadowWriteMaterial并设为激活状态，而ShadowWriteMaterial的类型是根据NiDyamicEffect的类型指定的。最后NiRenderClick就会启动渲染流水线，将可见集中的对象的深度全部渲染到ShadowMap中。

4. 在第一个RenderClick中生成了ShadowMap，下面就要使用这些ShadowMap投射阴影。在每一帧开始之前，用户还可以自己指定不接受阴影的节点，手动将其插入NiShadowGenerator：：m_kUnaffectedReceiverList中。在渲染BackBuffer的RenderClick中，首先会对场景图中的节点进行一次遍历，将不受阴影的节点放入NiShadowGenerator：： m_kUnaffectedCasterList的列表。在对每个节点进行渲染时，会遍历NiShadowManager中所有的NiShadowGenerator，判断这些NiShadowGenerator是否对这个节点有影响，判断的规则是此节点是否存在于UnaffectedReceiverList和UnaffectedCasterList这两个链表中，如果存在于任何一个链表，则节点不受此NiShadowGenerator影响，如果受此NiShadowGenerator影响，那么就将该NiShadowGenerator上的ShadowMap和数据更新到节点上的渲染属性中，NiStandardMaterial会根据这些数据选择对ShadowMap采样的方式，并将结果混合到最终的输出颜色中。

值得注意的是，点光源的shadowMap默认的是采用CubeMap实现，用户可以通过接口选择不使用CubeMap实现，当采用CubeMap实现时，光源无法产生软阴影。

渲染系统的扩展：

为了验证GameByro渲染系统的扩展性，笔者尝试着加入了一个后期处理特效Screen Space Ambient Occlusion（SSAO）,即屏幕空间的遮蔽，由于仅仅为了熟悉GameByro的渲染流程，所以笔者并未对SSAO算法做深究，仅仅用了自己简化的算法。

在渲染过程中先单独使用一个RanderClick将场景中的深度渲染到一张纹理上，然后在渲染到后台缓冲区的RenderClick中对深度纹理进行采样，执行SSAO算法，将结果混合到最终的结果中。采样点的偏移坐标是通过对一组随机向量进行归一化再乘以0~1之间的随机数而生成的，即长度为0~1之间的随机向量。

PS代码如下：

float VerticalRange:GLOBAL; //控制XY方向采样范围变量，可以在应用程序层对其进行调整

float HorizontalRange:GLOBAL; //控制在Z方向采样范围的变量

float calAO(float2 texCoord,float dw, float dh ) //通过当前像素所标和偏移量计算AO

{

float2 coord = float2(texCoord.x + dw, texCoord.y + dh);

float4 CenterPos = tex2D(DepthSampler,texCoord);

float4 CurPos = tex2D(DepthSampler,coord);

float depthDiff = clamp(CenterPos.z - CurPos.z,0,VerticalRange);

float ao = depthDiff/length(CurPos.xyz - CenterPos.xyz);

return ao;

}

// Pixel shader

float4 PS_SSAO(VS_OUTPUT In) : COLOR

{

float2 texCoord = In.BaseTex;

float depth = tex2D(DepthSampler,texCoord).z;

float ao = 0.0;

float scale = HorizontalRange/depth; //因为采样范围会受深度影响，故除以此系数。

for(int i=0; i<32; ++i)

{

float2 offset = arrRandomPt[i].xy* scale;

ao += calAO(texCoord, offset.x, offset.y);

}

ao/=32;

float4 color = tex2D(BaseSampler,texCoord);

color.xyz *= (1.0 - ao);

return color;

}

最终实现效果如下：

SSAO生成的明暗图 无SSAO材质

以下两图上图为无SSAO效果，下图为开启SSAO后的效果。

总结：

GameByro的帧渲染系统是比较灵活，想加入自己的渲染流程是比较容易的，此外由于RenderTarget和RenderView都可以由用户指定，所以想实现自己的shader效果不是很难。然而，NiStanderMaterial的shade tree比较复杂，总共高达6000行代码以上，过程非常复杂，这就是说，如果想实现自己的材质处理流程也要付出相当大的工作量，阴影系统虽然实现了较低的耦合度，但是实现过于复杂，不够简洁高效。

作者：叶起涟漪

GameByro是一款成熟的商业引擎，已经被许多成功的商业项目所使用，不仅包括文明4、上古卷轴4，辐射3等跨平台知名单机游戏，还有EA的大型3DMMORPG战锤online。GameByro完全基于面对对象设计，结构清晰，便于使用和扩展。灵活的可编程渲染架构使它比较容易支持最新的图形技术。另一方面，由于强调通用性，GameByro并没有对上层应用做太多的支持，其工具和插件大多仅具有一些通用功能，所以它更像是一个游戏开发套件而不是一个完整的FrameWork。

引擎特性概览：

· 跨平台（PC,XBOX360,PS3）

· 场景图表现为层次化的结构

· 同目前主要的建模工具集成（插件支持）

· 高效的可视性裁剪

· 在所有的平台上支持高级3D硬件加速

· 高级纹理和着色效果

· 动态碰撞检测

· 细节分级表现（LOD）

· 灵活的渲染，排序和裁剪算法

对象系统：

GameByro的对象系统的使用遍及整个引擎，其主要实现如对象管理，引用计数，对象生存期等功能。可以通过对几个基类的继承来使用对象系。

其主要特性主要有：

1. 智能指针（引用计数）

2. 运行时类识别（RTTI）

3. 场景对象复制

4. 序列化（对象文档化）

5. 对象命名

6. 对象扩展数据的管理

7. 定时器（主要用于动画）

8. 多线程操作

驱动层：

GameByro对图形接口进行了封装，将图形API从引擎的渲染系统中剥离出来，在PC系统上，GameByro同时支持DX9和DX10两种接口。

DX9渲染器特性：

l GameByro不允许多个DX9Renderer对象同时存在，且不能与DX10Renderer共存。但在同一帧内，GameByro的DX9Renderer可以同时渲染多个窗口。

l GameByro的DX9渲染器支持对资源的多线程访问，同时也支持对资源的预载，但是多线程的操作仍然受到严格的限制。

l DX9Renderer 的固定管线蒙皮操作最少支持4块骨骼（矩阵），同时基于shader的蒙皮操作支持30块骨骼。

l DX9Renderer通过对后台缓冲的多重采样支持全屏抗锯齿，范围在2倍到4倍之间。

l 大多数硬件在DX9下对几何体的一个单一的piece所能接受的光照数量都有一定的限制（指渲染的一个批），如果超过这个限制，GameByro会根据距离或者是影响因子放弃一些光照。正因如此，在应用程序中，当8个以上的逐顶点光照作用于同一对象时，就会有一些被抛弃。

l DX9Renderer提供了视口的左右反向功能，用于实现后视镜、立方体贴图表面绘制等功能。

l DX9Renderer支持顶点雾，可以通过相关接口设置雾的最大值。

l DX9Renderer完全支持DX的纹理格式。应用程序可以将自己的Direct3D textures提供给GameByro，引擎会自动将其封装到自己的材质对象中并允许添加属性和特效。通过提供自己的DX的纹理格式，GameByro能够正确的使用自并非天然支持的纹理格式。

l 纹理相关特性和限制：DX9Renderer需要显卡支持在同一pass中至少使用两个纹理，否则渲染器则不会创建成功。此外受限于硬件的功能还有：

1. Cube Mapping（立方体纹理）

2. Specular Bump Mapping（凹凸镜面贴图）

3. Diffuse Bump Mapping（凹凸反射贴图）

4. Non-Power-of-Two Texture Size（编长非二整数幂的纹理）：使用这种纹理有如下限制：纹理寻址模式必须设置为clamp，Mipmapping不能使用。

5. Texture Downsizing（纹理精度缩减）

6. Texture Compression（压缩纹理），DX9Renderer支持载入经过压缩的纹理格式，并提供了纹理即时压缩的功能。如果硬件支持压缩纹理，DX9Renderer可以将经过压缩的纹理数据直接交给硬件处理，否则DX9Renderer会自动将数据解压后再交给硬件。

7. Texture Apply Modes Supported：DX9Renderer不支持APPLY_DECAL纹理应用模式。

8. Texture Format Requests（纹理格式要求）：精确的纹理像素映射依赖于目标硬件和显示器像素位宽。

9. Palettized Texture Formats（调色板纹理格式的支持）。

10. Sphere Mapping（球面映射）：GameByro中所有的渲染器都支持世界空间中的球面映射。

11. DX9Renderer支持加载包括DDS、TGA、BMP格式的文件。Cube textures和volume textures都能被正确的加载，但是只能通过三维坐标寻址。

12. GameByro的编辑器支持导出DX原格式的纹理，并在加载的时候不进行格式转换。将DX格式的纹理直接交给DX处理。

引擎渲染系统分析

GameByro的渲染是由帧渲染系统(Frame Rendering System) 控制的，帧渲染系统封装了每一个批次的绘制过程，这样可以方便的控制整个渲染流程。

阴影系统：

GameByro的阴影系统是使用帧渲染系统的典范，通过对已有的类以继承的方式进行功能扩展，实现了灵活的阴影渲染功能。GameByro自身支持三种光源的阴影图生成，分别为点光源（全方向光）、平行光、聚光灯。

阴影系统统一由一个管理器负责控制。阴影的算法被封装成了一个个类对象中。系统中同时存在着几种阴影技术，即可以选择使用，也可以同时使用几种阴影技术作用于同一几何体。阴影系统会自动裁剪掉那些没有阴影接受体的光源，同时在计算每个光源所产生的阴影时，会裁剪掉那些不受此光源影响的几何体，达到性能优化的目的。用户很容易对阴影系统进行扩展，实现自己的阴影算法。

GameByro的阴影主要是基于shadowMap技术，点光源使用了立方体阴影图，软阴影则使用了方差阴影图技术（VSM）。

GameByro的阴影系统集成到了场景编辑器中，可以在编辑器中直接为光源指定阴影效果，所见即所得，提高了开发效率。

（如图所示，在编辑器中同时使用点光源阴影和方向光产生的软阴影）

地形系统：

GameByro的terrain是简单易用的，并且方便为其扩展，用以满足项目的其他功能需求。

地形系统由以下几部分组成：

1. NiTerrainComponent：是整个地形系统的入口，通过Terrain Interactor可以像访问容器一样访问NiTerrainComponent所有的sub-component。

2. Terrain Interactor 地形迭代器，通过Terrain Interactor可以启动所有的数据查询，比如简单的碰撞检测，meta-data查询，高度图导入和文件加载。几乎所有基于terrain系统的操作都是通过Terrain Interactor完成的。

3. NiTerrainSectorComponent 的内部主要包含一个负责组织地形数据块的四叉树。此对象负责从磁盘加载执行物体与地形的射线相交查询，转换地形几何体，管理内部资源（包括共享的顶点流和shader）。同时NiTerrainSectorComponent还负责进行四叉树的遮挡查询和生成可见集。

4. Data Leaves and Blocks 四叉树的切分等级是通过NiTerrainComponent设置的，四叉树的每个节点都包含一个地形块，块的边长必须是2的整数幂。四叉树的根节点等级为N，叶节点为0，由高到底细节依次增加，等级为0的叶节点所包含的地形块拥有最高的细节。

5. Material Layers：地形系统通过掩码图来为地形指定材质。掩码的数据指定了地表的每个部分所对应的材质。同一地表最多支持四种材质，根据各自的权重进行混合，权重数据也是通过掩码来获得。

材质在地形的渲染系统中扮演着很特殊的角色，可以通过对材质指定meta-data来附载其他的信息（比如在雪地行走的声音），同时也可以通过对材质的纹理贴图为地表增加顶点或像素着色程序。此外每种材质可以包含如下指定类型的纹理贴图：

l Diffuse/Base Map 反射贴图，通过3或4个通道决定反射光的颜色。

l Detail Map 细节贴图，为反射贴图提供Alpha值。

l Normal Map 法线贴图。

l Parallax Map 视差贴图，用来保存表面像素的高度偏移信息。

此外GameByro还提供了简单的地形射线追踪和水面渲染。地形射线追踪目前的实现很简单，就是用一个射线查询地表的三角形，以后会与Physics进行集成，支持通过物理引擎l实现物体与地表的碰撞检测。水面渲染主要是用两张纹理动画混合而成，通过凹凸贴图来表现水波。引擎为水面所在的地表生成一个灰度图，保存地表距离水面的高度。这里预先定义了两种颜色，深水颜色和浅水颜色，如果水面以下没有地表就直接使用深水颜色。再像素着色器中可以对高度图进行采样，从而得出当前像素的水深，然后根据这个深度在深色和浅色之间进行差值，得到最终水的颜色。不过这个效果并不是很理想，如需更好的效果，还需要对其进行扩展，比如说，增加反射和折射等。

材质：

GameByro的材质主要是通过3DMAX的插件进行编辑的，并提供了标准的材质节点。

（在GameByro中，材质节点的主要作用是负责根据着色过程生成相应的shader代码）这个节点一共有9个通道，并提供了大量可供调整的参数，这样就可以让美术方便的使用逐像素光照、视差贴图、环境体贴图这些效果，在游戏中，GameByro通过不同的材质属性和不同的光照环境编译出不同的shader代码，以二进制的形式保存在磁盘上，下次启动时载入内存，这样就不用重复编译，但在第一次进入游戏中时会有些延迟。灵活强大的材质是次世代引擎的重要特征，GameByro在这方面做到了灵活，但是美术仍然不能通过可视化工具控制材质的处理过程，只能编辑资源和修改参数，编辑性还不够强大。

Shader：

GameByro提供了一个极具扩展性的shader系统，并将它与艺术创作工具紧密结合。GameByro定义了自己的shader格式，基于文本的.NSF文件和基于二进制的.NSB文件，.NSF文件编译后生成.NSB文件，这个过程即可以在开发时完成，也可以在运行时进行。 .NSF文件使用的是GameByro自定义的语法，并使用自己的语法分析器将其编译成相关平台的代码。实际上，GameByro的shader系统在应用程序和GPU程序之间做了一层封装，屏蔽了不同平台之间的差异，使得应用程序可以用相同的接口来与GPU之间进行交互，而GPU程序最终还是通过cg或hlsl来实现的，这样做的好处是，当平台发生改变时，只需要根据具体的平台来编写相应的shader程序，而不需要去修改应用程序。当然，shader系统也直接支持cg和hlsl格式的文件，使用方法同NSF、NSB文件相似。GameByro的Shader系统提供了一套完整的查错机制，方便使用者对程序进行debug。

GameByro的shader系统集成到了所有的配套开发工具中，这样就实现了所见即所得，美术在工具中就可以直接看到资源在游戏中的效果，从而提高了开发效率。

GameByro通过引入自己的shader文件格式为跨平台提供了方便，同时也增加了系统的复杂性，使用起来稍微有点繁琐，开发人员又不得不去熟悉它的语法，如果开发中不考虑跨平台的话，想要自己开发特效，也可以不使用NSF文件，直接使用fx格式的文件。

引擎自带的特殊材质：

AdditiveLightMapsMaterial（附加光照图材质,使用额外的光照图纹理来混合当前场景光照计算的结果。下面的插图是使用投射光照图纹理的渲染效果。）

AlphaTextureBlender（纹理Alpha混合）

Aniso（各向异性光照，左下的飞机）、Halo（光晕效果。上面的飞机）

ASMSkinningLighting（参与光照计算的骨骼动画蒙皮）

ASMSkinningNoLighting（不参与光照计算的骨骼动画蒙皮，效率经过了优化）

BaseBumpWithSpatialGlow（带有辉光效果的凹凸贴图）

Chrome（金属外表，使用基本纹理、漫反射cube map、镜面反射cube map、法线贴图等效果实现类似于金属表面的光泽和质感，并支持基于此效果的蒙皮操作）

Colorize（使用一个自定义的属性来动态的设置或者修改颜色）

FXSkinning and HLSLSkinning（使用可编程渲染管线进行骨骼动画的蒙皮）

GeneralGlow（普通辉光效果）

GeneralDiffuseSpecularGlow(普通镜面反射高光辉光)

GeneralDiffuseSpecular（普通镜面反射高光，支持蒙皮操作）

Dot3BumpMap（凹凸贴图，右图为蒙皮效果）

Glass (玻璃效果)

OilyFilm（油状薄膜）

LuminanceTransfer（类似于热源侦测仪的效果）

Outlining（蓝图或草图）

ParallaxMapping（视差贴图，下面右图是使用了ParallaxMapping的效果）

PerPixelLighting（逐像素光照，同时支持固定管线和可编程渲染管线）

SkinnedToonShadingWithOutline（卡通渲染，支持骨骼蒙皮、描边）

纹理：

GameByro的纹理系统支持多重纹理、投射纹理、动态纹理、特效纹理，并且使用纹理的一些高级特性是平台无关的。当然GameByro中纹理的功能仍然受限于硬件特征。主要特性和限制见渲染器。

工具及插件：

GameByro提供了场景编辑器，资源浏览器，资源的物理模型浏览器、动画编辑工具，字体创建工具，以及3DMAX、MAYA插件，材质编辑是在插件中进行的，这套工具包含了完整的3D资源开发流程。

物理系统

GameByro通过PhysX提供物理仿真模拟，只需几行简单的代码就可以将GameByro的场景和PhysX建立起联系，不过需要在显式的调用相关接口来进行物理仿真对象和场景对象间的同步，即将物理仿真的结果作用于场景中的对象。同时，还可以通过参数来决定是否需要等待物理仿真运算的结果。这就保证了一定的灵活性，例如，用户可以不对静态物体进行同步，达到优化的目的。还可以通过把更新的接口放在下一次循环开始的时候调用，这样可以减少由于等待物体仿真模拟造成线程的阻塞，充分的利用了CPU资源。

粒子系统：

GameByro的粒子系统为3ds max 和 Maya等粒子生成工具提供了完整的插件系统，并完全支持软粒子，即粒子会受到力的影响。

流处理引擎：

GameByro实现了一个完全跨平台的流处理引擎。使用者可以方便的利用它完成多线程任务，如资源的加载等，完全发挥多处理器平台的威力，而不用关注底层细节。

效率分析：

为了对GameByro进行全面的评估，笔者试着对GameByro的渲染效率进行了简单的测试，本人的机器配置如下：

l CPU：E2180

l GPU：2400PRO

l 内存：2GB

基本可以代表当前中低端玩家的配置。

场景一：

下图为一个大的室外地形场景，包括建筑物、水面，地表使用了法线贴图，除了植被以外，基本包含MMORPG的大部分室外场景要素。最后测试的结果平均帧数为21帧。帧数偏低的原因是整个场景使用了逐像素光照，同时没有采用LOD进行优化。

场景二：

如图所示场景中有100个角色在做不同的动画，每个角色有51个骨骼，整个场景共有287900个多边形和556600个顶点，并且场景中有一个点光源和平行光源，在没有阴影的情况下帧数大约在27~28帧左右。这些骨骼动画使用了GameByro提供的骨骼动画优化方法，性能有一定提升。

由以上结果可以看出，GameByro的骨骼动画渲染效率尚可，而室外地形渲染系统的性能稍显不足，再没有角色和植被的情况下，仅能达到22帧左右，如果在实际的游戏环境还要算上其他游戏系统（网络、逻辑、UI等）的性能消耗，这是不足以让玩家流畅进行游戏的，还需进一步手动的优化。

总结：

GameByro拥有一套灵活的架构，便于使用和扩展，易于上手；配套的开发工具比较齐全，拥有完整的美术开发流程；完全支持跨平台，便于游戏的移植；同时由于为了保证灵活性，在设计上面比较偏重于功能和扩展，而不是性能。

高度的可定制性带来的是较低的整合，GameByro没有提供游戏框架，地图编辑器也仅仅实现了最通用的功能，即地表和物件的摆放。这就说明，如果要使用GameByro开发产品，就需要自己整合GameByro，并对其进行一定的修改和扩展。这也是它与UnrealEngine3区别最大的地方。

作者：叶起涟漪

引言：

GameBryo拥有一套复杂的材质系统，这套材质系统可以根据渲染对象的状态和属性生成不同的shader代码，提高了渲染流程的适应性，可以使你定义一套材质能适应多种渲染对象。同时，GameByro将shader的初始化和使用插件化，方便与美术工具集成，并且实现了平台无关性。为了实现这些目的，GameByro使用了一套复杂的机制，本文主要解析GameByro如何生成、编译并使用shader代码。

Shader

GameBryo的shader的接口封装在NiShader中，顶点数据流声明，常量表的访问，渲染状态的设置都是通过这个类（有点类似于D3Deffect）。在程序运行NiShader是由NiShaderFactory负责管理的，NiShaderFactory通过NiShaderLibrary从文件中创建shader，用全局性的map管理起来。NiShaderLibrary通过解析shader文本创建NiShader对象，并调用3D图形接口编译shader代码，将这个类以dll的形式封装，就可以作为插件来使用。NiShader类的创建可以通过解析文件来进行，也可以通过C++的类来定制，只需从NiShader上继承即可。GameByro为PC平台提供了一个NiD3DXEffectShaderLib库，这个库提供了解析shader文件和初始化shader对象的功能。用户只需按GameByro定义的格式编写shader代码的语意和注释，NiD3DXEffectShaderLibrary就会根据文本来创建NiD3Dshader对象，在应用程序中就可以通过Techinqe的名称来访问这个对象。通过这种机制，我们将shader文本文件放在相关美术工具指定的目录下，在工具中就可以使用这些shader，并且能够通过shader的语意和注释为相关参数和变量生成UI，方便美术调试。

WIN平台上的整个流程如下：

1. 应用程序在启动时会先初始化整个shader系统，接下来导入Shader解析库和加载库（dll的形式）。

2. 接下来应用程序将NiD3DShader的初始化工作委托给NiShaderLibrary来处理，NiShaderLibrary首先通过NiD3DXEffectLoader载入所有的shader文本文件，并通过NiD3DXEffectParser解析文本生成NiD3DXEffectFile对象，同时NiD3DXEffectLoader还负责将shader代码编译成二进制形式的GPU程序。

3. 最后由NiD3DXEffectTechnique负责通过NiD3DXEffectFile上的信息生成NiD3Dshader对象。

4. 所有的shader对象创建后，NiShaderLibrary的初始化就结束了，最后由NiShaderFactory负责统一管理。

材质：

NiMaterial为渲染对象生成和定义Shader,NiMaterialInstance为渲染对象分配 和Cach Shader。NiFragmentMaterial提供了一个Shader Tree框架，在它的继承类中可以使用这个框架搭建shader tree。这个机制允许NiFragmentMaterial根据对象不同的渲染状态生成不同的shader代码，Cach在内存中，并保存到磁盘文件。GameByro描述符的概念大量使用，包括前面提到的Shader解析过程也是通过描述符来传递信息。在材质系统中主要使用了NiMaterialDescriptor和NiGPUProgramDescriptor这个两个类做描述符，这两个类中保存的信息是兼容的，都是为了描述某种材质在渲染对象的某一特定渲染状态下所对应的GPU程序的特征。NiFragmentMaterial通过渲染目标的状态和属性生成NiMaterialDescriptor，并通过NiMaterialDescriptor查找匹配的shader，如果找不到，则通过shader tree生成相应的shader程序，并保存到磁盘文件中。当下一次应用程序启动时就可以通过这个文件直接创建NiShader对象。可以说通过NiFragmentMaterial生成的shader代码是为特定的渲染对象在特定的情况下量身打造的。

整个过程的详细流程如下：

1. 在每次渲染一个物体之前，NiMaterialInstance会先判断这个物体的shader程序是否需要更新，如果不需要更新，就直接返回当前Cach的NiShader；如果需要更新， NiMaterialInstance首先会根据物体的渲染状态为其生成一个NiMaterialDescriptor，然后将这个NiMaterialDescriptor和当前Cach住的NiShader进行比较，如果匹配仍然返回当前Cach的NiShader，如果不匹配，将获得shader的工作转交给NiMaterial进行。

2. NiMaterial首先通过这个NiShaderFactory 查询匹配这个NiMaterialDescriptor的NiShader，如果找不到，就通过NiMaterialDescriptor生成NiShader，同时生成一段Shader代码，并保存到以shader描述符中的特征码来命名对应的shader文件。

3. 当获得相应的NiShader对象后，NiMaterialInstance会调用NiShader的SetupGeometry接口，在这个接口中会进行顶点声明。

以下是NiMaterialInstance为Geometry选择shader的代码：

NiShader* NiMaterialInstance::GetCurrentShader(NiRenderObject* pkGeometry,

const NiPropertyState* pkState,

const NiDynamicEffectState* pkEffects)

{

if (m_spMaterial)

{

bool bGetNewShader = m_eNeedsUpdate == DIRTY;

if (m_eNeedsUpdate == UNKNOWN)

bGetNewShader = pkGeometry->GetMaterialNeedsUpdateDefault();

// Check if shader is still current

if (bGetNewShader && m_spCachedShader)

{

bGetNewShader = !m_spMaterial->IsShaderCurrent(m_spCachedShader,

pkGeometry, pkState, pkEffects, m_uiMaterialExtraData);

}

// Get a new shader

if (bGetNewShader)

{

NiShader* pkNewShader = m_spMaterial->GetCurrentShader(

pkGeometry, pkState, pkEffects, m_uiMaterialExtraData);

if (pkNewShader)

{

NIASSERT(m_spCachedShader != pkNewShader);

ClearCachedShader();

m_spCachedShader = pkNewShader;

if (!pkNewShader->SetupGeometry(pkGeometry, this))

ClearCachedShader();

}

else

{

ClearCachedShader();

}

}

m_eNeedsUpdate = UNKNOWN;

}

return m_spCachedShader;

}

如果想通过NiFragmentMaterial实现自己的shader tree就需要在NiFragmentMaterial提供的接口中实现自己拼装代码的逻辑，代码块由NiMaterialLibraryNode封装，NiMaterialLibraryNode既可以直接写C++代码来定义，也可以先写成XML脚本，再由专门的解析工具转换成C++代码。

由NiStandardMaterial生成的shader代码文件如下图所示：

文件名就是NiMaterialDescriptor的掩码，用来标识的shader代码的行为。

Shader代码的行为描述如下：

Shader description:

APPLYMODE = 1

WORLDPOSITION = 0

WORLDNORMAL = 0

WORLDNBT = 0

WORLDVIEW = 0

NORMALMAPTYPE = 0

PARALLAXMAPCOUNT = 0

BASEMAPCOUNT = 1

NORMALMAPCOUNT = 0

DARKMAPCOUNT = 0

DETAILMAPCOUNT = 0

BUMPMAPCOUNT = 0

GLOSSMAPCOUNT = 0

GLOWMAPCOUNT = 0

CUSTOMMAP00COUNT = 0

CUSTOMMAP01COUNT = 0

CUSTOMMAP02COUNT = 0

CUSTOMMAP03COUNT = 0

CUSTOMMAP04COUNT = 0

DECALMAPCOUNT = 0

FOGENABLED = 0

ENVMAPTYPE = 0

PROJLIGHTMAPCOUNT = 0

PROJLIGHTMAPTYPES = 0

PROJLIGHTMAPCLIPPED = 0

PROJSHADOWMAPCOUNT = 0

PROJSHADOWMAPTYPES = 0

PROJSHADOWMAPCLIPPED = 0

PERVERTEXLIGHTING = 1

UVSETFORMAP00 = 0

UVSETFORMAP01 = 0

UVSETFORMAP02 = 0

UVSETFORMAP03 = 0

UVSETFORMAP04 = 0

UVSETFORMAP05 = 0

UVSETFORMAP06 = 0

UVSETFORMAP07 = 0

UVSETFORMAP08 = 0

UVSETFORMAP09 = 0

UVSETFORMAP10 = 0

UVSETFORMAP11 = 0

POINTLIGHTCOUNT = 0

SPOTLIGHTCOUNT = 0

DIRLIGHTCOUNT = 0

SHADOWMAPFORLIGHT = 0

SPECULAR = 1

AMBDIFFEMISSIVE = 0

LIGHTINGMODE = 1

APPLYAMBIENT = 0

BASEMAPALPHAONLY = 0

APPLYEMISSIVE = 0

SHADOWTECHNIQUE = 0

ALPHATEST = 0

NiStanderMaterial就是根据这些掩码的数据来生成shader代码，用户可以通过重载GenerateVertexShadeTree、GeneratePixelShadeTree、CreateShader这些接口来定义自己的shader生成规则。

增加自己的渲染效果：

通过前几节我们可以了解到，想定义自己的材质，一是通过编写shader代码完成。在应用程序初始化的时候，这些shader代码会被初始化成NiShader对象，进一步的通过NiShader对象来初始化NiSingleShaderMaterial对象，并分配给渲染对象。在GameByro默认的渲染流程中，这些步骤都是自动进行的，美术只需在3DMAX插件中为几何体的材质指定Shader程序，导出到nif文件，应用程序就能正确加载并渲染；二是定义自己的NiMaterialFragment类，在类中定义如何生成shader，在应用程序运行时只要将这个类的实例指派给几何体，这个类就会自动为几何体生成shader。这两种方式对于美术人员来说，主要区别在于，采用第一种方法定义的材质，其渲染数据的设置必须严格符合shader代码中所需的数据，否则就会报错。（比如说，顶点数据流必须严格符合shader程序的定义，必须为shader中每个采样器提供格式正确的纹理）；而采用第二种方法定义的材质，就有很高的容错和适应性，但是这种容错性和适应性需要自己写代码来完成，GameByro提供的NiStanderMaterial就提供了这套完整的机制。每个贴图槽内的贴图如果你设置就会生成相应的贴图处理流程，如果不设置，就没有这张贴图的处理流程。

为了验证这个过程，笔者尝试增加了一个自己的shader特效——SubSurfaceScattering，简称3s，其原理是模拟光在半透明物体中散射的效果。由于该效果无须预处理过程，所有的贴图均来自磁盘文件，所以比较容易融合到GameByro工作流中。

笔者将在FX COMPOSER中调试通过的fx文件放入SDK中的SDK\Win32\Shaders\Data目录下，在3DMAX的材质面板选择GameByroShader，然后就可在显示shader的组合框中看到文件中定义的Techinqe，选择点击apply按钮，就会出现自定义的参数调整界面。

通过调整参数，最终得到皮肤和玉器的渲染效果如下：

皮肤

玉器

总结

GameByro的这套开发流程非常方便直观，但是美术仅能为shader程序分配静态的数据源，比如说光照图等，CubeMap等；而一些在程序中实时生成的纹理数据则无法整合到美术工具中，比如说阴影图、折射图、反射图等，这些都需要程序写代码来实现。调试起来就不大方便了。大部分情况下，我们只需要使用GameByro提供的NiStanderMaterial就可以完成大部分材质的需求，特殊的效果可以自己写shader或者通过引擎提供的shader库来完成，只有当我们需要即根据复杂的情况做很多不同的处理时，我们才需要重载NiFragmentMaterial搭建自己的shader tree。不过搭建shader tree的程序一般比较复杂，编写难度大，虽然引擎允许通过XML文件来编写材质节点，但是使用起来仍然不方便。GameByro并没有提供相关的后期处理的开发工具，后期处理的特效并不能所见即所得，这方面还需完善。

GameByro为几何体在特定的环境下生成专用的shader代码，具有一定的灵活性，但是也付出了以下代价：

l 分析几何体的属性和当前状态，为其生成shader代码的过程有性能损耗。

l Shader代码生成后会保存到磁盘文件中，这个过程如果不使用异步，可能会引起阻塞。

l 生成的NiShader对象会有内存消耗。由于GameByro默认的实现是将所有的shader文件初始化成NiShader对象，所以当游戏运行的时间久了以后会生成大量的shader文件，这时候内存的消耗可能会很可观，同时加载的时间也会增加。不过可以自己控制加载的流程，在这里进行性能优化。

作者：叶起涟漪