3.9 KiB
SceneRenderRequestPlanner
命名空间: XCEngine::Rendering
类型: class
头文件: XCEngine/Rendering/SceneRenderRequestPlanner.h
描述: 负责从场景和可选 override camera 生成实际要提交给 CameraRenderer 的相机请求列表。
概览
SceneRenderRequestPlanner 处在 SceneRenderer 和 SceneRenderRequestUtils 之间。
它不亲自渲染任何东西，而是把“应该渲染哪些相机、按什么顺序、哪些请求应该被丢弃”整理成一组 CameraRenderRequest。
这种“先规划 request，再执行 request”的拆法很接近商业引擎里常见的 camera scheduling 思路。它的价值不是抽象更漂亮，而是把两类会频繁变化的逻辑拆开：
- 场景侧规则：相机收集、stack/depth 排序、clear 推导、viewport 解析
- 执行侧规则：scene extraction、主管线、object-id、post/overlay pass
这样 Editor、离屏渲染和手工 request 注入都能复用同一套规划规则，而不用直接碰 CameraRenderer 内部执行链。
公开方法
| 方法 | 说明 |
|---|---|
| CollectCameras | 收集本次应参与渲染的相机列表。 |
| BuildRequests | 把相机列表展开成可执行的 CameraRenderRequest 数组。 |
当前规划规则
CollectCameras()
当前规则是：
- 如果
overrideCamera可用，则只渲染它自己。 - 否则从场景里查找全部
CameraComponent。 - 过滤掉不可用相机。
- 按 SceneRenderRequestUtils 里的稳定排序规则整理顺序。
BuildRequests()
它会按相机顺序逐个调用 BuildCameraRenderRequest()，并维护：
renderedBaseCameraCount- 已成功生成的 request 数量
这两个计数会影响自动 clear flag 的推导。
如果某个相机最终解析出的 render area 宽高为 0，该请求会被直接丢弃，而且不会错误地推进 base camera 计数。
设计取舍
当前 planner 故意保持“只做一件事”：
- 负责决定 request 集合
- 不负责 request 执行
- 不负责附加 pass 组装
这是一种比很多早期引擎实现更稳的做法。否则 Scene View 一旦要加 object-id、grid、selection outline、editor overlay，规划逻辑和执行逻辑很容易在一个类里互相缠死。
另一个重要取舍是：当前只支持 base / overlay + depth 的线性排序，而不是更复杂的 stacking 依赖图。 这不是文档漏写，而是当前实现的真实边界。它优先保证顺序简单、稳定、可测试。
真实使用位置
engine/include/XCEngine/Rendering/SceneRenderer.h持有一个SceneRenderRequestPlanner实例。engine/src/Rendering/SceneRenderRequestPlanner.cpp实现具体收集与构建逻辑。tests/Rendering/unit/test_scene_render_request_planner.cpp覆盖了 override camera、稳定排序和零尺寸 viewport 的行为。
当前实现边界
- 它只规划相机请求，不处理
objectId或各类RenderPassSequence的具体填充；那部分通常由更上层调用方补充。 - 当前没有 camera stacking 的更复杂依赖分析，只有 base / overlay 与 depth 的线性排序。
BuildRequests()只返回成功构建的请求，不单独报告被过滤掉的相机原因。