在本书的所有示例程序中都是在代码中指定assets-models，textures和materials（模型，纹理，材质）。这种方法可以简化示例程序，但是在实际的现代渲染引擎中并不常用。相反，这些引擎都是data driven（数据驱动结构），由配置文件构成场景中的各种objects。一个data-driven引擎意味着在场景中没有任何数据（或有大量数据）的情况下，游戏都能正常执行。此外，在现在引擎中不仅可以从配置文件获取objects的assets还可以获取objects的行为活动。在引擎中一般使用脚本语言实现objects的行为。比如，在Unreal Development Kit（UDK，UE引擎）中，使用UnrealScript脚本编写所有的游戏逻辑代码。在Unity（另一个流行的游戏引擎）中则提供了用于编写游戏脚本的多种语言，包括C#，JaveScript以及Boo。
设计一个data-driven架构的游戏引擎，需要定义一个配置文件格式，以及用于加载assets的入口点。XML是一种常用的配置文件格式，因为这种格式的文件（至少部分）是直接可读的，并且可以使用任何文件编辑器手动修改。配置文件的详细定义与运行时类型对应的属性相匹配。此外，配置文件通常是按层次划分的，把一个“总的”配置文件分成无数个子文件，每一个子文件定义具体的关卡或者asset类型。多个开发人员可以分别开发游戏的不同部分，而不用担心在文件发生改变时会导致冲突。下面列出了一个分层的XML格式的配置文件：
<!-- Game.xml, the root asset store of the configuration hierarchy --> <AssetStore> <Items> <Item Class="AssetStore" File="Content\Levels\Level1.xml" /> <Item Class="AssetStore" File="Content\Levels\Level2.xml" /> <Item Class="AssetStore" File="Content\Levels\Level3.xml" /> </Items> </AssetStore> <!-- Level1.xml --> <AssetStore> <Items> <Item Class="Camera" FOV="0.785398" AspectRatio="1.33333" NearPlaneDistance="1.0" FarPlaneDistance="1000.0"> <Position X="0" Y="0" Z="0" /> <Direction X="0" Y="0" Z="-1" /> <Up X="0" Y="1" Z="0" /> </Item> <Item Class="Skybox" CubemapFile="Content\Textures\Maskonaive2_1024. dds" Scale="500" /> </Items> </AssetStore>在这种引擎系统中最核心的问题是，把运行时类型与配置文件中的属性元素进行匹配。这个过程一般使用factory pattern（工厂模式）实现，工厂模式是软件设计模式的其中之一，支持通过一个接口实例化对象。更具体地说，在配置文件中存储了类的名称用于从工厂集合中找到对应的初始化接口。每一个factory类知道如何实例化单个对象，在factory manager类使用一个变量把类名与对应的工厂类关联。
在上面的例子中，一个C++类AssetStore包含一组Item实例。AssetStore类表示该配置文件数据结构层次的根结点。Item类表示store中的单个asset，其中Class属性值指明了要实例化的C++对象类型。如果item含有File属性值，运行时加载系统就会从另一个配置文件中获取该aaset的配置；否则，该类所需的配置数据作为属性值包含在Item的XML格式属性中。在该示例中，使用Item关联的数据实例化Camera和Skybox类。
AssetStore类与一个使用模板的Factory类进行交互，Factory类的声明代码如列表22.7所示。 列表22.7 The Factory Class Declaration
template <class T> class Factory { public: virtual ~Factory(); virtual const std::string ClassName() const = 0; virtual T* Create() const = 0; static Factory<T>* Find(const std::string& className); static T* Create(const std::string& className); static typename std::map<std::string, Factory<T>*>::iterator Begin(); static typename std::map<std::string, Factory<T>*>::iterator End(); protected: static void Add(Factory<T>* const factory); static void Remove(Factory<T>* const factory); private: static std::map<std::string, Factory<T>*> sFactories; };该类同时用于表示factory和factory manager。在每一个派生类中实现纯虚函数ClassName()和Create()，并通过静态成员函数Add()和Remove()把该派生类添加到静态factories列表成员中，或从列表中删除。其中，静态成员函数Create()根据给定的名称找到对应的factory类，并在查找成功的情况下执行非静态成员函数Create()。创建factory的子类是一种常用的操作要求（对任何想要对data-driven配置系统提供公有访问接口的子类都是必须的），因此为了更简单的定义factory类，可以使用列表22.8所示的宏实现代码。 列表22.8 ConcreteFactory Class Macro
#define ConcreteFactory(ConcreteProductT, AbstractProductT) \ class ConcreteProductT ## Factory : public Factory<AbstractProductT> \ { \ \ public: \ ConcreteProductT ## Factory() \ { \ Add(this); \ } \ \ ~ConcreteProductT ## Factory() \ { \ Remove(this); \ } \ \ virtual const std::string ClassName() const \ { \ return std::string( #ConcreteProductT ); \ } \ \ virtual AbstractProductT* Create() const \ { \ AbstractProductT* product = new ConcreteProductT(); \ return product; \ } \ };有了以上创建factory的代码，就可以使用如下方法创建一个Skybox类：
ConcreteFactory(Skybox, RTTI)然后就可以使用如下的调用方法实例化一个Skybox对象：
RTTI* skybox = Factory<RTTI>::Create("Skybox");生成游戏世界中所有objects的过程主要包括：反系列化配置文件，通过factory系统实现化游戏objects，并把这些objects添加到用于表示场景的任意数据结构中。
本章主要讲解了一些现代图形渲染的技术主题。首先讨论了一些优化应用程序渲染速度的方法，包括view frustum culling，occlusion culling，object sorting，shader optimization以及hardware instancing。然后探讨了deferred shading，global illumination，compute shaders以及data-driven的引擎架构。
这是本书的最后一章。恭喜你完成了本书的学习。但是，我希望你把此作为一个新的开始，而不是结束。你现在正处于研究更多渲染主题的开始阶段，我衷心希望你能喜欢这本书。
