GPU Gems 1 · Chapter 30. The Design of FX Composer

GPU Gems 1 第 30 章讨论的不是某个 shader 技巧，而是“怎样造一个让开发者和技术美术愿意长期使用的 shader 工具”。FX Composer 面向 Direct3D effects：.fx 文件描述效果如何应用到 3D 模型，工具则提供类似 IDE 的编辑、属性调整和实时预览环境。本章聚焦它的设计取舍，不重复下一章的使用教程，也不把历史 API 当作现代引擎的直接依赖。

FX Composer 的设计目标可以压缩成三句话：熟悉的 IDE、可扩展的引擎、稳定的 .fx 创作与可视化环境。这个目标组合决定了后续架构：面板要能停靠和隐藏，插件要能从外部加入，对象要能被统一发现和编辑，预览还要能在不同设备能力下给出明确反馈。

1. 工具开发的优化目标：生产力先于固定帧率

游戏引擎通常有固定的功能集合和严格的运行时预算；工具则需要随着 API、作者需求和调试任务不断增长。FX Composer 的目标用户是有一定编程能力的软件开发者和技术美术，因此编辑器、Materials、Textures、Render 等面板必须共同服务一个闭环：改动效果、调整属性、看到结果、发现错误、继续迭代。

这里的“稳定”不是“永不出错”，而是错误应当可见、边界应当可解释。例如效果编译失败时显示红色 wireframe；当前设备不具备效果所需能力时显示蓝色 wireframe。可见的失败比静默回退更适合工具，因为作者能据此修正输入或选择另一种 technique。

2. 用接口对象和工厂形成插件边界

plugin model 让几乎每个组件都能成为插件：复杂的场景导入器和简单的字符串容器都遵守同一套运行时约定。核心运行时负责对象创建和注册，动态库导出 RegisterNVObjects 与 UnRegisterNVObjects，对象工厂再按类别和 GUID 找到可创建的类型。

interface-based object 的最小基础是 INVObject。它提供 AddRef、Release 和 QueryInterface：前两者控制共享对象的生命周期，后者让调用方在不依赖具体类的情况下询问对象是否支持另一项能力。FX Composer 用智能指针封装引用计数，使接口转换同时承担能力查询和引用管理。

class INVImportScene : public INVObject {
public:
  virtual bool ImportScene(INVScenePtr& scene, const char* fileName) = 0;
  virtual unsigned int GetNumFileExtensions() const = 0;
};
 
INVSceneImporterPtr importer = GetImporter();
INVPropertiesPtr properties = importer; // 隐式 QueryInterface
if (properties) {
  showPropertySheet(properties);
}

这个边界的价值在于“能力按需出现”。对象可以额外实现 Properties、XML streaming 或 Clone 接口；面板只需要查询自己关心的能力，不必知道对象的具体实现。代价也要明确记录：引用计数有固定开销，循环引用需要 weak pointer，接口体系对新贡献者有学习成本。因此，示例插件、宏和文档不是装饰，而是架构可用性的一部分。

3. 连接参数：让属性面板、动画和 shader 共享一份语言

connection parameter 是对象模型与效果创作之间的桥。只要对象实现 INVProperties，Properties 面板就可以枚举参数并用统一的 Property Sheet 编辑；同一种机制既能表达 material 的 bump height，也能表达 shape 的尺寸和 tessellation。

连接参数还支持 time keys 和 interpolator，所以一个 skinned mesh 的角色运动可以和 material 参数动画同时变化。不要把它理解成“UI 变量复制到 shader 变量”：它是跨对象、面板和设备映射的主数据。设备 effect 创建后会有自己的参数集合，运行时需要把共享的 material 参数同步过去。

4. 消息、场景和可恢复的工作区

复杂工具不能让每个对象直接依赖所有其他对象。FX Composer 先使用全局广播消息让多个组件接收类似 NewScene 的事件，后来又增加 sender/receiver 协议，让有明确关系的对象注册自己关心的事件。这两层通信各有边界：广播适合松耦合通知，定向消息适合可追踪的协作，但两端都要管理好对象是否仍然存在。

.fxcomposer workspace 采用混合文件格式而不是纯 XML。容器本质上是一个带 .fxcomposer 扩展名的 ZIP：XML 保存对象关系和二进制块的 offset，binary chunk 保存 mesh 等不适合直接编码进 XML 的数据。保存时遍历对象层次；重载时先通过 ObjectID 检查所需插件是否已经加载，缺少某个 shape 插件时提示用户，并尽量恢复其余场景。

这种格式把“可读的结构”和“紧凑的媒体”放在同一份交付物里。它也暴露了真实的恢复边界：文件能定位一个对象，不等于当前运行时拥有创建这个对象的插件；因此插件版本、类别和 GUID 应当成为项目诊断信息，而不是隐藏在加载失败之后。

5. 多设备预览与效果编译的两阶段路径

FX Composer 可能同时管理 Materials、Textures、Render 和 Shader Perf 等窗口。原书选择为不同面板使用独立 Direct3D device，使窗口可以撕出到第二块显示器，也能把 reference rasterizer 和硬件设备并列用于验证。这个选择可能造成 texture 资源在窗口间重复实例化，但对开发机而言，灵活性和实现清晰度是可接受的交换。

ID3DXEffectCompiler 把共享层和设备层分开：先创建 material，它代表 .fx 文件与该 material 独有的 connection parameters；再编译 .fx 并检查错误，保存紧凑表示；最后，material 第一次用于某个窗口时，ApplyToDevice 才把表示转换为该 device 的 ID3DXEffect。

Material material = loadMaterial("cartoon.fx");
CompiledEffect compiled = compiler.compile(material.source);
 
for (DeviceWindow& window : windows) {
  if (!material.hasEffect(window.device)) {
    material.applyToDevice(window.device, compiled);
  }
  material.syncParameters(window.effect);
  render(window, material);
}

这条路径有三个可验证的结果：一份 .fx 可以生成多个参数不同的 material；多个窗口可以共享一次编译；每个设备仍然可以检查自己的能力和 technique。效果被拆成 techniques 正是因为不同 technique 可能需要不同资源，工具可以把当前设备可用的 technique 呈现给用户并在必要时切换。

6. geometry pipe：让几何输入匹配 effect 的语义

Direct3D effect 通过 semantics 描述 vertex shader 需要的输入。FX Composer 因此没有把“模型必须预先符合某个固定顶点布局”写死，而是引入 geometry pipe node：底部由 shape 或 mesh 提供初始 bundle，上层插件可以添加、修改或移除 position、normal、texture coordinate 等 stream，最后再按照 effect 需要的 semantic 和 usage index 生成 vertex buffer。

这个管线让插件可以适配新的使用场景，例如为 fur shader 增加 fins 数据。skinning 也沿用同一原则：如果 geometry 有 bones/weights 而 effect 不需要，就先在 host 侧处理；如果 effect 需要而 geometry 没有，就提供默认权重和当前变换；两边都匹配并且硬件支持时，才把数据直接交给 effect。选择不是“永远在 GPU 做”或“永远在 CPU 做”，而是先对齐输入契约，再根据现有数据和硬件能力决定路径。

7. 从原书设计抽出可迁移的工程规则

FX Composer 的历史实现依赖 Direct3D 9 和 COM 风格接口，但设计经验可以迁移到今天的 shader 工具或编辑器：

• 把作者可见的错误、可恢复的工作区和可扩展的 public interface 作为工具质量指标
• 把共享描述、作者参数和设备资源拆成不同生命周期，避免窗口数量直接放大编译工作
• 让对象通过能力查询接入通用面板，避免为每种插件复制一份 UI 和序列化逻辑
• 让 geometry、material 和 effect 通过 semantics 或明确的 schema 对接，先验证契约再选择 CPU/GPU 路径

下一章会讲如何使用 FX Composer 创建项目和效果；本章的练习只要求你能从系统边界、数据生命周期和失败反馈解释这些设计，而不是把历史 SDK 当作现代项目的即插即用依赖。

小结

• FX Composer 的首要目标是生产力、稳定性和可扩展性，而不是把工具当成固定功能的游戏引擎。
• 接口对象、对象工厂、类别注册和引用计数形成插件模型；QueryInterface 让 Properties 等附加能力按需出现。
• connection parameter 把属性编辑、动画、语义和 material 数据连接起来，成为跨对象和设备的共享主数据。
• .fxcomposer 用 ZIP 容器组合 XML 场景描述与 binary chunk，并在重载前检查插件是否可用。
• .fx 先由 ID3DXEffectCompiler 编译一次，再由 ApplyToDevice 按窗口创建设备专属 effect；geometry pipe 则让输入 stream 与 effect semantics 对齐。