Chapter 107: Engine Integration

一条独立渲染管线可以只讨论 pass、shader、buffer、texture 和 GPU 提交；进入完整引擎后，渲染模块面对的是一个持续变化的世界。脚本修改对象，动画更新骨骼，物理产生碰撞结果，资源系统完成贴图流式加载，场景系统给出可见对象，渲染线程再把这些变化整理成一帧 GPU 能执行的命令。读完本章后，读者应能定位这些变化进入渲染帧的边界，判断资源生命周期是否安全，追踪 scene graph 到 render queue 再到 frame graph 的数据路径，并复盘一帧表现下降时该检查哪类证据。

本章使用一帧“城市街角角色镜头”作为贯穿材料：主角从阴影区走到霓虹灯下，脚本在角色身上打开交互描边，动画系统更新骨骼矩阵，物理系统推动一扇玻璃门，资源流式系统在这一帧完成建筑外墙的高分辨率 albedo 和 normal 贴图上传，音频系统更新空间声源位置，渲染模块需要提交主相机、阴影、透明玻璃、后处理和 UI pass。这一帧的视觉目标很普通，但它把引擎集成中的核心矛盾集中到一起：渲染需要稳定快照，其他系统持续写入状态，GPU 资源又有跨帧释放和同步约束。

引擎集成的主问题可以压缩成一句话：渲染模块如何把场景、动画、物理、脚本、资源系统和平台后端的变化收束到一个可提交、可调试、可评估的 frame。Unity 6.4 Manual 对 render pipeline 的工作定义是把 scene 内容经过一系列操作显示到屏幕；SRP 文档进一步说明脚本层通过上下文调度渲染命令，再交给低层图形架构和图形 API。这个描述适合放在本章的边界上理解：渲染管线负责 frame 内部的图像生成，引擎集成负责把 frame 外部的系统状态可靠地送到管线入口。Unity Render pipelines 与 Unity Scriptable Render Pipeline fundamentals 可以作为这一边界的官方表述。

完整引擎里的渲染质量由两层结果共同决定。第一层是图像结果，角色是否被正确描边，玻璃是否按透明顺序绘制，流式贴图是否替换到正确材质槽位。第二层是工程结果，帧时间是否稳定，资源释放是否等待 GPU 完成引用，多线程任务是否存在无意义等待，调试工具能否把问题定位到对象、pass、资源或命令。只看图像会漏掉跨帧隐患，只看 profiler 会漏掉错误的视觉契约；集成评估必须同时覆盖两层。

107.1 渲染模块与引擎核心其他模块协调

渲染模块和其他引擎模块协调的第一条规则是确定 frame boundary。Frame boundary 指一帧中可被渲染读取的世界状态边界：哪些脚本结果、动画结果、物理结果、资源状态和相机参数会进入本帧，哪些变化进入下一帧。没有这个边界，render queue 构建时会读到半更新对象，GPU 命令和调试记录也无法还原当时的世界状态。

在城市街角这一帧中，脚本系统在角色靠近门把手时打开交互描边，动画系统把角色骨骼推进到当前姿态，物理系统把玻璃门旋转到新的碰撞后角度，音频系统使用同一份角色和相机位置更新空间声源，资源系统报告外墙贴图的高分辨率 mip 已经可用。渲染模块读取这些状态时，需要得到一个 render snapshot。Render snapshot 是面向渲染的只读快照，通常包含 transform、bounds、mesh handle、material handle、light data、camera data、visibility flags 和 debug tags。它的作用是把游戏逻辑对象转换成渲染可消费的数据，而非让渲染线程直接追逐游戏对象的可变字段。

这一关系可以用一条 frame 数据路径表示。图中的关键点是渲染模块接收的是各系统提交后的帧快照，并在该快照上构建可见性、队列和 pass。

这条路径把模块责任分开。脚本系统负责产生交互意图，例如“角色进入描边范围”；动画系统负责输出骨骼矩阵或变形参数；物理系统负责输出稳定的刚体 transform 和碰撞事件；音频系统通常不直接生成 draw call，但它和渲染共享相机、角色、遮挡和事件边界；资源系统负责报告资源 handle、resident mip 和 upload 状态；渲染模块负责把这些输入整理成可见对象、材质参数和 pass 资源。边界清楚后，画面错误才能定位到具体模块：描边没有出现，先查脚本事件是否写入 render snapshot，再查材质 variant 和 pass toggle；玻璃门位置错，先查物理 transform 是否完成提交，再查渲染对象是否读取了旧 transform。

Frame boundary 还决定延迟容忍度。动画姿态通常需要进入当前主相机帧，否则角色会有可见抖动；音频对一帧图像的依赖较弱，但镜头 cut、爆炸和大型交互事件需要使用同一帧事件边界，方便回放和调试；高分辨率贴图可以晚一帧切换，只要低分辨率 mip 和材质占位符保持稳定。引擎集成的目标是给不同输入定义不同的提交契约，而非把所有系统强行塞到同一个同步点。

一个可维护的集成接口应记录三类时间信息。第一类是 simulation frame，说明脚本、动画、物理在哪个逻辑帧产生结果；第二类是 render frame，说明渲染线程在哪个图形帧使用结果；第三类是 GPU frame，说明命令何时提交、何时完成。只要这三类编号可追踪，工具中看到的错误就能回到源头。例如角色描边晚一帧出现，日志中显示脚本事件属于 simulation frame 120，render snapshot 在 render frame 121 才包含 outline flag，问题就落在跨线程提交延迟，而非 shader 输出错误。

引擎模块之间的协调还需要共享对象身份。Render object ID 应该和 scene entity、asset GUID、material variant、debug name 形成可追踪关系。这样在 frame capture 中选中一条 draw call 时，开发者能回到“城市街角外墙材质实例”“主角 skinned mesh 第 2 个 submesh”“玻璃门透明 pass”这类引擎对象。缺少对象身份时，渲染系统仍能提交 GPU 命令，但问题排查会被迫停留在 buffer 地址、descriptor slot 或匿名 draw call 上。

107.2 Asset Import Resource Lifetime and Render Queue Integration

Asset import 进入渲染系统时，要经历离线数据、运行时资源和 GPU resident resource 三个阶段。离线数据是美术工具导出的 mesh、texture、material、animation clip 和 metadata；运行时资源是引擎内可引用的 asset handle、material instance、streaming state 和 dependency record；GPU resident resource 是已经完成上传并能被 shader 读取的 buffer、image、sampler 和 acceleration data。三个阶段的生命周期不同，集成接口需要明确每个阶段谁拥有引用、谁可以触发上传、谁负责释放。

城市街角这一帧中的外墙贴图提供了最小例子。Asset import 阶段已经把原始图像转换成平台格式，生成 base mip、normal map、compression format 和 streaming metadata。运行时资源系统根据相机距离决定需要高分辨率 mip，把上传请求放入 upload queue。GPU 后端在 copy queue 或 graphics queue 中写入 texture memory，并通过 resource state transition 或 barrier 让后续 fragment shader 读取。Render queue 构建时看到材质 handle，必须根据资源状态选择当前可用 mip：高分辨率 mip ready 就绑定新视图，尚未 ready 就继续绑定低分辨率占位资源。

资源生命周期的核心是引用关系和完成信号。CPU 侧引用只能说明引擎对象还活着，GPU 侧引用还要看命令是否已经执行完成。Vulkan Guide 在同步章节中强调应用开发者负责管理同步，错误同步会带来难查 bug 和 GPU 空闲；这一点可以迁移到引擎抽象层：释放 texture、buffer 或 descriptor 前，要确认所有引用它的 GPU frame 已经完成。Vulkan Guide: Synchronization 支撑的是这个判断边界；各引擎可以用自己的后端抽象表达同一类完成信号。

一个实用的资源生命周期可以按以下状态推进。

这个状态图说明，release 请求和真正释放之间存在 RetirePending 阶段。RetirePending 是跨帧渲染最常见的安全缓冲区：CPU 已经移除对象引用，但 GPU 仍可能执行上一帧或上几帧的 draw call。对贴图、vertex buffer、index buffer、uniform buffer、descriptor set、bind group 和 transient attachment 都应有类似概念，只是实现名称不同。图形 API 后端可以用 fence、timeline semaphore、frame index、resource version 或 deferred deletion queue 实现这个阶段。

Asset import 还要把资源契约写入 render queue。Render queue 应记录比“绘制一个 mesh”更完整的信息，保证 command building 阶段无需回到可变 asset 系统重新查找。典型字段包括 mesh GPU handle、submesh range、material pipeline key、texture residency state、constant buffer layout、sort key、pass mask、debug name 和 resource version。这样 upload 线程完成贴图切换时，render queue 可以通过 resource version 判断当前绑定是否匹配，命令构建阶段始终读取已经完成提交的材质对象。

Streaming 对 render queue 的影响主要体现在降级策略。外墙高分辨率贴图迟到时，画面可以使用低 mip；mesh LOD 数据迟到时，可以继续使用上一档 LOD；材质 shader variant 迟到时，通常需要使用 fallback material 或跳过某个 feature pass。降级策略需要在 asset metadata 中声明，因为 render queue 构建阶段只适合做选择，通常不适合临时发起复杂 import 或 shader compilation。大型引擎会把“可用资源集”和“目标资源集”分开：可用资源集负责本帧稳定绘制，目标资源集负责后台追赶质量。

资源系统和 render queue 的集成检查可以按四步执行。先查资源身份：frame capture 中的 texture 或 buffer 能否回到 asset GUID 和 material slot。再查 residency：当前绑定的是目标 mip、fallback mip，还是默认占位资源。接着查同步：upload 完成信号是否早于 draw 读取，release 是否晚于 GPU 完成。最后查降级契约：资源迟到时画面是否有稳定占位，debug view 是否能显示 streaming 状态。这四步能把“贴图偶尔闪黑”“材质一帧变粉”“切场景崩溃”这类问题放回同一组生命周期证据中。

107.3 渲染与场景系统整合

场景系统和渲染系统整合的核心路径是 scene graph → visibility → LOD → material system → render queue → frame graph。Scene graph 负责表达对象层级、transform、空间分区和组件关系；visibility 负责从相机和遮挡条件中筛出候选对象；LOD 负责根据距离、屏幕占比和平台质量选择几何或材质级别；material system 负责把材质参数和 shader variant 映射为 pipeline key；render queue 负责按 pass、排序和状态切换组织 draw item；frame graph 负责声明 pass 依赖、attachment 生命周期和资源读写关系。

城市街角这一帧中，主角、玻璃门、霓虹灯牌、建筑外墙和 UI 分属不同场景对象。主角来自 skinned mesh 组件，需要动画姿态和骨骼 buffer；玻璃门来自刚体对象，需要物理 transform 和透明排序；霓虹灯牌既是 emissive material，又可能影响 bloom；建筑外墙触发贴图 streaming；UI 通常走独立 overlay pass。渲染集成的价值在于把这些对象拆成不同 draw item，并让每个 draw item 携带足够的 pass 和资源信息。

Scene graph 不应直接决定最终绘制顺序。场景层级表达逻辑关系，例如“玻璃门挂在建筑节点下”；绘制顺序需要根据 pass 类型、material state、深度、透明距离、GPU pipeline 和 frame graph 依赖计算。把逻辑层级直接当成绘制顺序，会让透明、阴影、depth prepass、decal、post-process 和 UI 的关系难以维护。稳定的做法是 scene graph 只输出渲染候选，render queue 再按渲染规则重新排序。

Visibility 阶段解决“这一帧哪些对象进入渲染候选集”。最小输入包括相机 frustum、对象 bounds、layer mask、visibility flag、occlusion data 和 shadow caster flag。对城市街角镜头，玻璃门在主相机可见并参与透明 pass，主角参与主相机和阴影 pass，屏幕外背街建筑可能只参与 shadow 或完全剔除。可见性结果需要记录原因，例如 frustum visible、shadow visible、occlusion culled、layer filtered。记录原因看似增加数据量，但它直接支持 debug view：对象消失时，开发者能看到它是被 frustum、layer、occlusion 还是 LOD 策略过滤。

LOD 阶段解决“用哪个版本画”。几何 LOD 改变 mesh，材质 LOD 改变 shader feature 和 texture set，动画 LOD 改变骨骼更新频率或 skinning 精度，阴影 LOD 改变 shadow caster 参与策略。LOD 决策应使用同一组可记录输入：距离、屏幕覆盖率、质量等级、平台预算、对象重要性和 streaming readiness。主角在近景中使用高骨骼精度和完整材质；远处外墙可以使用较低 mip；玻璃门由于透明排序和反射效果可能保持较高材质级别。这些决策进入 render queue 后，后端才能把它们转成 pipeline key 和 resource binding。

Material system 是 scene 和 GPU pipeline 之间的翻译层。材质作者关心 albedo、normal、roughness、emissive、alpha mode 和 feature toggle；GPU 后端关心 shader variant、descriptor layout、blend state、depth state、raster state 和 specialization constant。集成接口需要从材质实例生成稳定的 material pipeline key。这个 key 应该覆盖影响 pipeline state 的字段，也要把只影响 uniform 数据的字段分出去。霓虹灯 emissive 强度变化通常只更新常量或纹理；alpha mode 从 opaque 切到 transparent 会改变 pass、排序和 blending，属于 render queue 结构变化。

Render queue 的 draw item 可以简化成一组字段来理解：object ID、pass mask、mesh range、material key、resource bindings、transform data、bounds、sort key、debug labels。Frame graph 再根据 draw item 需求创建或引用 depth、color、shadow map、G-buffer、lighting target、bloom target 和 UI target。这样 scene graph 的对象变更不会直接污染 pass 设计，pass 设计也不会反向依赖具体场景层级。

一个典型场景整合错误是对象在主相机可见，却没有进入阴影 pass。排查顺序应从 scene object 的 shadow caster flag 开始，接着看 visibility 阶段是否为 shadow camera 生成候选，再看 LOD 是否在当前质量等级关闭 shadow mesh，最后看 render queue 是否给 draw item 写入 shadow pass mask。这个顺序体现了本节主线：场景、可见性、LOD、材质、队列、frame graph 是递进关系，任意一步都应留下可观察证据。

107.4 多线程资源调度与并行执行模式

多线程渲染集成的目标是把一帧中的 CPU 工作拆成可并行任务，同时保持数据依赖清楚。常见任务包括脚本更新、动画采样、物理同步、可见性剔除、LOD 选择、资源 streaming、GPU upload、render queue 构建、command building、async compute 调度和提交。任务能并行的前提是输入已固定、输出写入独立缓冲、依赖关系可表达。只把工作丢进线程池不会自动改善帧时间；依赖设计错误会把并行变成等待链。

城市街角这一帧可以拆成几个并行区间。脚本和物理完成后，角色描边 flag、玻璃门 transform、相机参数进入 render snapshot。动画采样可以和资源 streaming 请求并行，前者输出骨骼 buffer 数据，后者输出贴图上传任务。可见性剔除依赖相机和对象 bounds，LOD 依赖可见结果、质量等级和 streaming readiness。Command building 依赖 render queue 和资源绑定结果。Async compute 的 SSAO、light culling 或后处理准备任务需要读取 depth 或其他输入，因此它们的 GPU 依赖要写入 frame graph。

下面的任务图展示了 CPU job 和 GPU queue 之间的边界。它不绑定某个特定 API，重点是每条边都代表实际数据依赖。

Culling 适合并行，因为不同空间分区、不同相机或不同对象批次可以写入独立候选列表，再在末端合并。Animation 也适合并行，因为每个角色或动画实例可以输出自己的骨骼矩阵。Command building 的并行空间来自 pass、material bucket 或 draw item range，但它受到 API 后端约束：某些 API 支持多线程录制 command buffer，某些后端需要通过引擎内部命令列表合并。抽象层需要暴露“可并行构建”和“必须串行提交”的差异，不能把一个后端的录制模式写成全平台事实。

资源 upload 的并行边界更细。CPU 可以并行解压、转码、创建 staging buffer 和填充 upload command；GPU copy 与 graphics draw 之间需要同步。贴图 upload 完成后，本帧是否使用新资源取决于 frame graph 中的可见依赖。如果上传完成信号到达得太晚，render queue 应继续使用旧 resource version。这个选择让帧稳定性优先于单帧画质跳变，也让工具能解释“为什么这帧仍然使用低 mip”。

Async compute 需要谨慎集成。它适合 light list、SSAO、particle update、skin cache、GPU culling 等与 graphics queue 可重叠的工作，但收益取决于硬件 queue、资源读写、barrier 和 shader cost。若 async pass 读取 depth，depth pass 完成前它只能等待；若 async pass 输出 texture 给后处理，composite pass 读取前需要等待。一个看似并行的 compute pass，只要依赖链放在主路径上，就可能增加帧时间。评估时要看 GPU timeline，而非只看任务被放到了 async queue。

多线程调度还要处理帧间缓冲。Render snapshot、per-frame constant buffer、upload ring buffer、transient descriptor、command allocator 和 frame graph resource 都常用多帧轮转。轮转数量取决于 CPU-GPU 延迟和平台后端。若 CPU 第 N+2 帧覆盖了 GPU 第 N 帧仍在读取的 constant buffer，画面会出现随机闪烁；若轮转过多，内存占用和延迟会上升。稳定集成需要把 frame index、resource version 和 GPU completion fence 统一纳入资源分配器。

排查多线程渲染问题时，应先看依赖图，再看时间线。依赖图回答“谁等待谁”；CPU timeline 回答 job 是否并行；GPU timeline 回答 graphics、copy、compute queue 是否真正重叠；frame capture 回答资源状态和 pass 读写是否匹配。城市街角这一帧如果突然从 16 ms 变成 28 ms，先查是否有 streaming upload 阻塞 render queue 构建，再查 async compute 是否被 depth 依赖拖到主路径，最后查 command building 是否因为材质变体编译或 descriptor 更新串行化。

107.5 质量分析：引擎整体渲染表现评估方式

引擎整体渲染表现评估需要同时回答六个问题：画质是否符合目标，帧时间是否稳定，内存是否受控，资源和同步是否安全，工具是否可观察，平台覆盖是否一致。单个平均 FPS 无法回答这些问题，因为平均值会隐藏一帧贴图 streaming 卡顿、透明排序错误、GPU barrier 过重或低端平台资源降级失败。质量分析应围绕 frame 证据组织，具体指标负责承接视觉反馈和 profiler 观察。

画质评估关注图像契约。城市街角这一帧的图像契约包括：主角描边只出现在交互状态，玻璃门透明排序正确，霓虹灯参与 bloom，高分辨率外墙贴图切换无黑块，阴影和角色姿态匹配，UI 覆盖在后处理之后。每个契约都应能落到 pass、resource 或 shader 输出。描边错误看 mask pass 和 material toggle；玻璃错误看 transparent queue 和 depth state；贴图错误看 resource version 和 sampler binding；bloom 错误看 emissive threshold 和 post-process input。

帧时间评估关注稳定性。实时渲染更怕 spike，因为 spike 会造成输入延迟、动画停顿和镜头抖动。评估时应同时看 CPU main thread、render thread、worker jobs、GPU graphics queue、copy queue、compute queue 和 present。平均帧时间只能说明长期负载，P95 / P99 帧时间和连续 spike 才能说明体验稳定性。若城市街角镜头转向建筑时出现 40 ms spike，而平均仍保持 16 ms，问题大概率在 streaming、shader variant、visibility rebuild 或 resource transition 上。

内存评估关注预算和换入换出。纹理、mesh、animation buffer、shadow map、G-buffer、post-process target、descriptor pool 和 transient attachment 都占用显存或统一内存。评估应同时看总量、峰值、驻留资源、可回收资源、streaming backlog 和 transient aliasing。外墙高分辨率贴图加载后，如果旧 mip、旧 material variant 或临时 upload buffer 没有及时进入 retire 队列，内存峰值会持续上升。内存问题经常表现为帧时间波动，因为驱动或系统内存压力会反过来影响提交和分页。

同步安全评估关注跨线程和跨队列证据。CPU 线程之间要看 job dependency、double buffer 或 lock；GPU 队列之间要看 barrier、semaphore、fence 或 frame graph dependency；CPU-GPU 之间要看 readback、resource release 和 ring buffer reuse。一个资源问题通常能从三个角度复查：资源版本是否正确，读写 pass 是否有依赖，释放是否晚于最后一次 GPU 使用。这个顺序比直接猜测“驱动问题”更稳定。

工具可观察性是集成质量的一部分。一个引擎若只能给出“这一帧慢了”，还没有完成渲染集成；它需要把对象 ID、pass name、resource name、material key、pipeline state、job name、thread name、frame index 和 GPU marker 写进工具。RenderDoc、Nsight、Xcode GPU tools、平台 profiler 或引擎自研 frame debugger 只是观察入口，真正决定排查效率的是引擎是否把语义标签传到这些入口。城市街角的一条 draw call 应能显示“CharacterBody / OutlinePass / Material_Interactable / frame 203”，这样匿名 pipeline 和匿名 vertex buffer 也能回到具体引擎对象。

平台覆盖评估关注相同渲染契约在不同后端上的可执行性。移动 tile-based GPU、桌面 discrete GPU、主机平台、浏览器 WebGPU、Metal、Vulkan、Direct3D 的资源绑定、内存模型、同步成本和工具能力都有差异。引擎集成层应把差异收束成 feature profile、quality tier 和 backend capability。质量评估时要记录某个效果在哪些平台使用完整路径，在哪些平台使用降级路径，降级后哪些画质契约仍然成立。比如透明玻璃可以在高端平台使用 refraction 和 SSR，在低端平台使用简化透明材质，但排序、alpha、基本反射强度和 debug 标记仍要稳定。

可复用的评估顺序可以固定为“先图像，再时间，再资源，再同步，再工具，再平台”。先图像能确认问题是否影响视觉契约；再时间能确认它是否影响交互；再资源能确认数据是否到位；再同步能确认读写顺序；再工具能确认是否可复盘；再平台能确认问题是通用集成错误还是后端差异。这个顺序适合大多数引擎渲染表现评估，也适合把美术反馈、程序 profiler 和平台 bug 汇总到同一套证据里。

最小自检任务

给定一帧场景：主角进入商店门口，脚本打开主角描边；动画系统更新主角骨骼；物理系统推动透明玻璃门；资源系统完成商店招牌高分辨率贴图上传；渲染管线包含 depth prepass、shadow pass、opaque pass、transparent pass、outline pass、bloom pass 和 UI pass。当前表现是：招牌贴图偶尔闪黑，主角描边晚一帧出现，玻璃门有时按旧位置绘制，GPU timeline 中 async compute 没有和 graphics queue 重叠。

请按照本章的集成方法，给出排查顺序。要求说明每一步检查的管线阶段、资源状态、可观察证据和可能结论。

答案要点

先检查 frame boundary 和 render snapshot。脚本描边晚一帧出现，重点看脚本事件属于哪个 simulation frame，render snapshot 在哪个 render frame 写入 outline flag，outline pass 的 draw item 是否带有正确 pass mask。若事件在本帧已经提交而 draw item 缺少 outline pass mask，问题在 render queue 构建；若事件下一帧才进入 snapshot，问题在跨线程提交边界。

接着检查玻璃门 transform 的来源。物理系统应在固定提交点输出刚体 transform，render snapshot 应记录玻璃门对象 ID、transform version 和 bounds。若 transparent pass 中 draw call 使用旧 transform version，问题在物理到渲染的同步或双缓冲切换；若 transform 正确但透明顺序错，问题转向 transparent queue 的排序 key、depth state 或相机距离计算。

然后检查招牌贴图的资源生命周期。查看 asset GUID、material slot、texture resource version、resident mip 和 upload 完成信号。贴图闪黑通常说明 render queue 绑定了尚未 resident 的资源、descriptor 指向已释放资源，或 fallback resource 缺失。正确路径是 upload 完成后再切换 resource version，release 请求进入 RetirePending，并等待 GPU fence 通过后释放旧资源。

再检查 frame graph 和 pass 依赖。Depth prepass 输出被 opaque、transparent、outline 或 async compute 读取时，需要有明确读写关系。Async compute 没有与 graphics queue 重叠时，先看它是否依赖 depth 完成，再看它的输出是否阻塞 bloom 或 composite。若 compute pass 位于主路径并需要等待 graphics queue 和后处理读取，它名义上是 async，实际仍在延长关键路径。

最后检查工具语义标签和平台差异。Frame capture 中 draw call 应能回到主角、玻璃门和招牌资源；profiler 中 job、pass、queue 和 frame index 应能对齐。若某个平台才出现问题，继续检查该后端的资源绑定、barrier、descriptor 更新和 quality tier 降级路径；若所有平台都复现，优先回到 snapshot、render queue 和资源生命周期契约。

本章知识点总结

• 帧边界：渲染模块读取的是一帧稳定快照，脚本、动画、物理、资源和相机状态都要通过明确提交点进入该快照。
• 快照职责：Render snapshot 把游戏对象转换成 transform、bounds、mesh、material、light 和 debug tag 等渲染可消费数据。
• 模块协调：脚本产生意图，动画输出姿态，物理输出稳定 transform，资源系统报告 resident 状态，渲染模块负责构建可见性和队列。
• 时间编号：simulation frame、render frame 和 GPU frame 需要可追踪，跨线程延迟和跨帧资源问题才能被复盘。
• 资源阶段：Asset import、runtime handle 和 GPU resident resource 属于不同生命周期阶段，所有权和释放规则要分开管理。
• 延迟释放：CPU 移除资源引用后，GPU 仍可能执行旧命令，RetirePending 或 deferred deletion queue 用于等待完成信号。
• 队列契约：Render queue 应记录 mesh、material key、resource version、pass mask、sort key 和 debug label，命令构建阶段才能稳定执行。
• 场景路径：Scene graph 输出渲染候选，visibility、LOD、material system、render queue 和 frame graph 逐步把候选转成 GPU pass。
• 材质翻译：Material system 把美术参数映射到 shader variant、pipeline state、descriptor layout 和 uniform 数据。
• 任务依赖：多线程收益来自清晰输入、独立输出和显式 job dependency，线程池本身不能替代依赖设计。
• 异步计算：Async compute 的收益取决于 GPU timeline、资源依赖和关键路径，队列名称不能证明实际重叠。
• 帧间缓冲：Per-frame buffer、descriptor、command allocator 和 transient resource 需要结合 frame index 与 GPU completion 管理。
• 质量维度：整体渲染表现要同时评估画质、帧时间、内存、同步安全、工具可观察性和平台覆盖。
• 工具标签：对象 ID、pass name、resource name、material key、frame index 和 GPU marker 是 frame capture 能回到引擎语义的基础。
• 评估顺序：先图像，再时间，再资源，再同步，再工具，再平台，可以把视觉问题和性能问题放入同一套证据链。