三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

从零构建DOTS渲染框架：七步打造高性能游戏渲染系统

发布时间：2026/8/9 6:40:34 三亩地 编程学习日记
从零构建DOTS渲染框架：七步打造高性能游戏渲染系统

1. 项目概述与核心价值

最近几年，游戏和实时图形应用对性能的渴求达到了前所未有的高度。玩家期待更宏大的世界、更密集的交互和更逼真的画面，而这一切都建立在强大的计算能力之上。传统的面向对象编程（OOP）模式，在应对成千上万个动态实体时，常常会遇到CPU缓存命中率低、GC（垃圾回收）卡顿、多线程难以利用等瓶颈。这正是我决定深入探索并动手“从零构建DOTS渲染框架”的初衷。这个项目标题听起来可能有些宏大，但其核心目标非常明确：利用数据导向技术栈（DOTS）的思想，设计并实现一个彻底摆脱传统OOP束缚、能极致压榨现代多核CPU性能、且具备高度模块化扩展能力的渲染系统。

简单来说，这不是对Unity引擎现有渲染管线的简单封装或修改，而是一次“造轮子”式的底层实践。我们旨在理解DOTS（Data-Oriented Technology Stack）的精髓——数据与行为分离、面向缓存的设计、作业系统（Jobs）与实体组件系统（ECS）的协同——并将这些理念应用于图形渲染这一特定领域。最终产出的，是一个可以独立运行或作为核心模块嵌入的、高性能、可扩展的渲染框架。无论你是对引擎底层感兴趣的技术爱好者，还是正在为项目性能瓶颈寻找突破方案的开发者，这个从零开始的构建过程都将提供一套完整、可落地的思路与解决方案。

2. DOTS渲染框架的核心设计哲学

在动手写第一行代码之前，我们必须彻底厘清DOTS渲染框架与传统渲染流程在根本设计哲学上的差异。这决定了我们整个系统的架构走向。

2.1 从“对象”到“数据”的范式转移

传统渲染中，一个“敌人”或“树木”通常是一个GameObject，上面挂载着MeshRenderer、Material、Transform等组件。系统需要遍历这些游戏对象，调用它们的Update和Render方法。这种模式直观，但存在致命问题：数据（顶点、矩阵、材质属性）分散在内存各处，CPU为了渲染一帧，需要在内存中“跳跃”访问，导致缓存利用率极低（即“缓存不友好”）。同时，管理这些对象的生命周期会带来GC压力。

DOTS渲染框架的核心哲学是“数据优先”。我们不再关心“渲染哪个物体”，而是关心“需要处理哪些渲染数据”。这些数据被组织成紧密排列（Archetype）的内存块。例如，所有需要渲染的实体的世界变换矩阵，被连续存储在Translation和Rotation组件数组中；所有网格信息被存储在RenderMesh组件数组中。渲染系统的工作，变成了对这几块连续大数据的高效处理。

2.2 并行化与作业系统（Jobs）的深度集成

现代CPU是多核的，但传统的MonoBehaviour.Update循环是单线程的。DOTS通过C# Job System，允许我们安全、轻松地将工作分摊到多个CPU核心上。对于渲染框架，这意味着：

  1. 视锥体剔除（Frustum Culling）：判断成千上万个物体是否在相机视野内，这是一个完美的并行任务。我们可以创建一个IJobParallelFor作业，让每个线程处理一部分实体的包围盒与视锥体的相交测试。
  2. 骨骼动画计算（Skinned Animation）：如果支持蒙皮网格，动画矩阵的计算是另一个计算密集型且可并行的任务。
  3. 数据准备与批处理（Batching）：将可见物体的渲染数据（世界矩阵、材质属性等）从ECS组件格式转换并填充到GPU所需的缓冲区（如Constant Buffer），这个过程也可以并行化。

设计时必须时刻思考：“这个步骤能分解成相互独立的小任务吗？” 如果能，就用Job来实现它。

2.3 可扩展性的系统化设计

“可扩展”不仅指能渲染更多物体，更指能灵活地支持新的渲染特性（如不同光照模型、后处理效果、渲染路径）。在ECS架构下，我们通过“系统”（System）和“共享组件”（SharedComponent）来实现扩展性。

  • 系统（System）：是行为的执行者。例如，FrustumCullingSystem负责剔除，RenderDataPreparationSystem负责准备GPU数据，RenderDispatchSystem负责提交渲染命令。要新增一种渲染效果（比如描边），我们只需创建一个新的OutlineRenderingSystem，并让它依赖于数据准备系统即可。系统之间通过组件依赖关系自动排序。
  • 共享组件（SharedComponent）：用于对实体进行分组。最典型的例子是RenderMesh，它包含网格和材质引用。所有使用同一份RenderMesh的实体，会被ECS自动分组在一起，这天然地支持了静态批处理（Static Batching）。我们可以定义自己的共享组件，如RenderPass，来指定实体属于前向渲染路径还是延迟渲染路径，从而实现多渲染路径的并存与扩展。

这样的设计使得框架像一个乐高积木，每个系统都是一个功能明确的模块，通过组合和添加新模块，就能构建出复杂的渲染管线。

3. 框架的七步构建蓝图

“七步打造”是一个概括性的路线图，它将构建过程分解为七个逻辑上层层递进、可独立验证的阶段。下面我们来详细拆解每一步的核心任务、技术选型与实现要点。

3.1 第一步：奠定基石——ECS架构与基础组件定义

这一步的目标是搭建整个框架的数据骨架。我们不急于渲染任何东西，而是先定义“什么东西可以被渲染”。

核心任务：

  1. 定义渲染实体组件：创建最基本的ECS组件。
    • LocalToWorld：存储实体的世界变换矩阵（可由Translation,Rotation,Scale组件通过LocalTransform系统自动生成）。
    • RenderBounds：实体的轴对齐包围盒（AABB），用于视锥体剔除。
    • RenderMesh（Shared Component）：引用UnityEngine.Mesh和UnityEngine.Material。共享组件特性使得同网格材质的实体被高效分组。
    • PerInstanceCullingTag：一个标签组件，用于标记需要参与每实例剔除的实体。
  2. 创建原型（Archetype）：通过组合上述组件，定义几种常见的实体原型，如StaticMeshArchetype（包含LocalToWorld,RenderBounds,RenderMesh）、DynamicMeshArchetype（额外包含PerInstanceCullingTag）。
  3. 搭建基础系统框架：创建RenderSystemGroup，这是一个ComponentSystemGroup，用于容纳和排序所有渲染相关的系统。我们后续创建的所有渲染系统都将作为它的子系统。

实操要点与避坑：

  • 组件设计原则：组件应只包含数据，无逻辑。尽量使用Blittable类型（如float3,quaternion）或NativeArray的引用，以确保它们能在Job中安全使用。
  • 共享组件的使用：RenderMesh作为共享组件非常高效，但要注意，修改实体的共享组件会导致其原型（Archetype）改变，引发一次内存块（Chunk）间的数据移动，这是一项较重的操作。因此，对于动态改变材质的物体，需要谨慎设计，或考虑使用材质属性覆盖（Material Property Override）的方式。
  • 使用Entities Graphics（原Hybrid Renderer V2）：对于从零开始的实践，我强烈建议基于Unity的Entities.Graphics包进行开发，而不是完全从最底层的Graphics.DrawMesh开始。Entities.Graphics提供了将ECS组件数据与Unity SRP（可编程渲染管线）桥接的标准方案，它已经处理了底层渲染数据的组装和提交，让我们能更专注于渲染逻辑和性能优化。

注意：在项目初期就明确是否使用Entities.Graphics。如果使用，我们的RenderMesh组件可以直接替换为MaterialMeshInfo和WorldToLocal等组件，框架设计会有所不同，但核心的DOTS思想不变。

3.2 第二步：建立视野——相机系统与视锥体剔除

没有相机，渲染就无从谈起。这一步我们要让相机在ECS世界里“活”起来，并利用它进行高效的可见性判断。

核心任务：

  1. 创建ECS相机实体与组件：
    • CameraComponent：存储相机的关键参数（FOV、近远裁剪面、纵横比）。
    • LocalToWorld：相机的位置和朝向。
    • CameraFrustumPlanes：一个动态缓冲区（DynamicBuffer），用于存储计算好的视锥体六个平面方程（Plane）。这个计算可以在一个CameraUpdateSystem中完成。
  2. 实现并行的视锥体剔除系统（FrustumCullingSystem）：
    • 这是一个IJobEntity或IJobChunk作业。
    • 它遍历所有拥有RenderBounds和LocalToWorld的实体。
    • 对于每个实体，将其RenderBounds（局部空间）通过LocalToWorld矩阵变换到世界空间，然后与相机视锥体的六个平面进行相交测试。
    • 将测试结果写入一个名为VisibleTag的标签组件，或者更高效地，写入一个NativeArray<bool>可见性列表，其索引与实体在查询中的顺序对应。

技术细节与优化：

  • 平面方程与包围盒测试：使用Plane.GetSide或手写点积测试。为了提高效率，通常先进行粗略的球体测试（计算包围盒中心到每个平面的距离），快速剔除明显不可见的物体，再进行精确的包围盒测试。
  • 层次化剔除（Hierarchical Culling）：对于超大规模世界，这是必须的。我们可以引入Grid或BVH（包围盒层次结构）系统。为世界分区，或动态构建BVH树。剔除系统首先在粗粒度层级（Grid Cell或BVH节点）进行测试，只对可能可见的节点内的实体进行细粒度测试。这步复杂度较高，初期可以用简单的网格划分实现。
  • 使用Entities.Graphics的剔除：如果使用Entities.Graphics，它内部已经集成了高效的剔除系统。我们更多需要做的是配置和扩展它，例如自定义剔除距离（Culling Distance）或图层（Layer）。

3.3 第三步：数据驱动——渲染数据准备与批处理

剔除之后，我们得到了可见实体列表。这一步的任务是将这些实体的ECS数据，转换成GPU能够直接消费的渲染数据，并尽可能地进行合批（Batching）以减少Draw Call。

核心任务：

  1. 创建渲染批次（Batch）：批次的核心思想是将使用相同网格、材质、渲染状态（如混合模式、深度测试）的多个实体，在一次Draw Call中绘制出来。我们需要一个数据结构来描述一个批次：
    public struct RenderBatch { public Mesh Mesh; public Material Material; public int SubMeshIndex; public NativeArray<Matrix4x4> WorldMatrices; // 该批次下所有实体的世界矩阵 public int Count; // 实体数量 }
  2. 实现渲染数据准备系统（RenderDataPreparationSystem）：
    • 查询所有可见的（拥有VisibleTag）、具有RenderMesh的实体。
    • 根据RenderMesh（共享组件）对实体进行分组。ECS的底层存储（Chunk）已经天然地按共享组件进行了分组，这极大地便利了我们。
    • 对于每个分组（即每个唯一的Mesh+Material组合），收集组内所有实体的LocalToWorld矩阵，填充到RenderBatch.WorldMatrices中。
    • 将创建好的RenderBatch添加到一个NativeList<RenderBatch>中，供后续渲染系统使用。

高级批处理技巧：

  • GPU Instancing：这是现代渲染中减少Draw Call的利器。我们需要确保材质球启用了GPU Instancing。在准备数据时，我们收集的不是Matrix4x4数组，而是将矩阵数据打包到一个大的GraphicsBuffer（即Structured Buffer）中。在渲染时，通过MaterialPropertyBlock或直接设置Shader的_InstanceData缓冲区，并调用Graphics.DrawMeshInstancedProcedural或Graphics.RenderMeshInstanced。
  • 动态合批与静态合批：对于动态物体（矩阵每帧变化），我们使用上述的每帧数据准备。对于静态物体（位置、旋转、缩放不变），我们可以在初始化时就将它们的矩阵数据预先计算好并上传到GPU缓冲区，甚至可以将多个静态物体的顶点数据合并成一个大的网格（静态批处理），从而在渲染时实现零CPU开销。
  • 材质属性覆盖（Per-Instance Material Properties）：如果不同实体需要使用同一材质但不同的颜色、纹理偏移等，我们需要扩展RenderBatch结构，使其包含一个MaterialPropertyBlock数组或一个包含所有自定义属性的Structured Buffer。

3.4 第四步：发号施令——渲染命令提交与管线对接

数据已备好，现在是时候告诉图形API（如OpenGL, Direct3D, Vulkan）该画什么了。这一步是框架与底层渲染管线的桥梁。

核心任务：

  1. 创建渲染调度系统（RenderDispatchSystem）：这个系统在RenderSystemGroup中应排在最后执行。它遍历上一步准备好的NativeList<RenderBatch>。
  2. 提交绘制命令：
    • 对于每个RenderBatch，设置渲染状态（绑定材质、网格）。
    • 如果使用GPU Instancing，则绑定包含实例数据的GraphicsBuffer，并调用Graphics.DrawMeshInstancedProcedural。
    • 如果不使用Instancing，则遍历WorldMatrices数组，对每个矩阵依次调用Graphics.DrawMesh（性能较差，仅用于调试或特殊情况）。
  3. 与SRP（如URP/HDRP）集成：在真实的Unity项目中，我们通常不会直接使用Graphics.DrawMesh，而是通过SRP的ScriptableRenderContext来提交绘制命令。我们需要创建一个System，在SRP的渲染循环中（如RenderPipelineManager.beginFrameRendering事件）被调用，将我们的RenderBatch列表转换为SRP的DrawingSettings和FilteringSettings，并通过context.DrawRenderers提交。

实现细节：

  • 命令缓冲（CommandBuffer）：对于复杂的渲染管线（如延迟渲染、多Pass渲染），使用CommandBuffer来录制一系列渲染命令会更加灵活。我们可以为每个RenderBatch或每一类渲染对象（不透明、透明、天空盒等）创建并填充不同的CommandBuffer，然后在合适的时机（SRP的某个Render Pass中）执行它们。
  • 渲染顺序与状态管理：正确的渲染顺序至关重要。我们需要对RenderBatch列表进行排序。常见的排序键包括：
    • 材质/Shader：尽可能合并相同Shader的绘制调用。
    • 渲染队列（Render Queue）：尊重材质中定义的Queue值（如Background, Geometry, AlphaTest, Transparent）。
    • 深度（Depth）：对于透明物体，需要按从后到前的顺序渲染。
    • 距离：在某些情况下，按距离排序可以优化Overdraw。
  • 使用Entities.Graphics的渲染：如果使用Entities.Graphics，这一步的大部分工作已被封装。我们需要做的是在OnCreate时向RenderPipelineManager注册一个回调，并在回调中通过RenderPipeline.GetRenderBatchRenderer获取到渲染器，然后调用其Render方法。我们的自定义逻辑（如自定义排序、自定义渲染Pass）可以通过扩展RenderBatch或创建自定义的RenderPass来实现。

3.5 第五步：光影交织——光照系统的集成

没有光，世界将一片黑暗。DOTS渲染框架需要一套能与ECS高效协作的光照系统。

核心任务：

  1. 定义光源组件：创建DirectionalLightComponent（方向光）、PointLightComponent（点光源）、SpotLightComponent（聚光灯）。这些组件应包含颜色、强度、范围（点光/聚光）、角度（聚光）等属性。
  2. 实现光源管理系统（LightManagementSystem）：这个系统收集场景中所有激活的光源，并将它们的数据（位置、方向、颜色、强度等）打包成GPU友好的格式，通常是结构化的数组或纹理（如Texture2D存储光源信息）。
  3. 将光源数据传递给Shader：通过全局Shader属性（Shader.SetGlobalBuffer）或每个材质的属性块（MaterialPropertyBlock），将打包好的光源数据传递给着色器。对于前向渲染，可能只需要最亮的几个光源；对于延迟渲染，所有光源信息都会被存储到G-Buffer中，在光照阶段统一处理。
  4. 阴影映射（Shadow Mapping）：这是一个复杂的子模块。需要为产生阴影的光源（通常是方向光）创建专用的阴影渲染Pass。
    • 从光源视角渲染深度图。
    • 在主渲染Pass中，将像素位置变换到光源空间，与深度图比较以判断是否在阴影中。
    • 在DOTS框架下，阴影深度图的渲染本身也是一次完整的渲染流程，可以复用我们之前构建的剔除、数据准备、提交系统，但使用不同的相机（光源相机）和不同的Shader（只输出深度）。

挑战与优化：

  • 光源剔除（Light Culling）：和物体剔除一样，我们不需要为每个物体计算所有光源的影响。通常使用基于屏幕空间分块（Tiled）或集群（Clustered）的光照剔除。这需要将视锥体在Z轴上分层，并与屏幕XY方向的网格结合，预先计算每个“簇”（Cluster）受到哪些光源的影响。这是一个计算密集型但可高度并行化的Job。
  • 与SRP光照管线兼容：如果使用URP/HDRP，它们有自己成熟的光照和阴影管线。我们的DOTS光照系统需要与之协同。一种方式是将我们的光源组件数据“同步”到Unity的传统Light组件上，让SRP管线来管理。另一种更深入的方式是直接扩展SRP的Lighting和ShadowCasterPass，使其能够直接从我们的ECS组件中读取光源和阴影数据。

3.6 第六步：性能调优与监控

框架能运行只是开始，跑得快、跑得稳才是目标。这一步是持续的工程实践。

核心任务：

  1. 性能剖析（Profiling）：
    • Unity Profiler：深度使用Unity Profiler的CPU、GPU、内存模块。重点关注FrustumCullingSystem、RenderDataPreparationSystem、RenderDispatchSystem的耗时。
    • ECS专用分析：使用EntitiesProfiler模块查看Archetype数量、Chunk数量、实体数量，检查是否存在内存碎片或低效的组件布局。
    • 自定义性能计数器：在关键系统内使用Unity.Profiling.ProfilerCounter来记录自定义指标，如“每帧剔除实体数”、“平均每批次实例数”、“Draw Call数量”。
  2. 瓶颈分析与优化：
    • CPU瓶颈：
      • Job效率：检查Job的BatchSize。太小会导致调度开销大，太大会导致负载不均。使用IJobParallelFor的ScheduleParallel并尝试不同的批次大小。
      • 数据访问模式：确保Job中访问的数据是连续的，避免随机访问。使用NativeArray的AsReadOnly()、AsDeferredJobArray()来确保正确的依赖关系。
      • Burst编译：确保所有性能关键的Job都使用了[BurstCompile]特性，让Burst编译器将其编译成高度优化的本地代码。
    • GPU瓶颈：
      • Draw Call：目标是最大化每个Draw Call渲染的实例数。检查批次合并是否成功，材质球是否启用了Instancing。
      • Overdraw：使用Frame Debugger或RenderDoc查看Overdraw情况。优化透明物体渲染顺序，使用深度预通道（Depth Prepass）等技术。
      • Shader复杂度：优化Fragment Shader，减少纹理采样次数和复杂计算。
    • 内存瓶颈：
      • 避免每帧分配：使用NativeArray、NativeList并在帧间复用，或使用Allocator.Persistent。绝对避免在Job或每帧循环中使用new创建托管对象。
      • 组件布局优化：将频繁一起访问的组件放在同一个Archetype中。将很少访问或只在特定系统访问的组件通过Enableable Component或存储在另一个Chunk中（使用SharedComponent或CleanupComponent）。

实操心得：

  • “先测量，后优化”：不要凭感觉优化。Profiler的数据是指南针。一个看似复杂的系统可能并非瓶颈，而一个简单的内存分配可能是卡顿的元凶。
  • 分层优化：先确保单线程逻辑正确，再并行化；先确保功能实现，再追求极致性能。过早优化是万恶之源。
  • 压力测试场景：构建一个包含数万甚至数十万移动物体的测试场景，这是暴露性能问题的最佳方式。

3.7 第七步：功能扩展与生态构建

一个框架的活力在于其扩展能力。最后一步，我们着眼于如何让这个框架变得更强大、更易用。

核心任务：

  1. 支持复杂渲染特性：
    • 骨骼动画：创建BoneEntity和SkinMatrix组件，实现一个SkinningSystem，使用Compute Shader或并行Job来计算最终的蒙皮矩阵，并更新RenderMesh的顶点数据或传递给Shader的骨骼矩阵缓冲区。
    • 粒子系统：基于ECS实现一个ParticleSystem。每个粒子是一个实体（或使用一个ParticleBuffer组件存储大量粒子数据），ParticleUpdateSystem负责模拟，ParticleRenderingSystem负责将粒子数据提交为RenderBatch（通常使用GPU Instancing的Billboard网格）。
    • 后处理效果（Post-processing）：创建全屏渲染的PostProcessSystem。它通常不涉及ECS实体，而是直接使用CommandBuffer或ScriptableRenderPass来执行全屏Blit操作，应用各种后处理材质（如Bloom, Color Grading, AA）。
  2. 多渲染管线支持：
    • 定义ForwardRenderingPath和DeferredRenderingPath等标签组件或共享组件。
    • 创建不同的RenderSystemGroup子组，如ForwardRenderingGroup和DeferredRenderingGroup。
    • 在RenderDispatchSystem中，根据实体的渲染路径标签，将其分配到不同的渲染队列中，并调用对应的SRP Render Pass。
  3. 工具链与工作流：
    • 编辑器扩展：创建自定义的Inspector，方便设计师配置ECS渲染实体和光源。
    • 调试可视化：实现Gizmos系统，在Scene视图中绘制ECS的包围盒、视锥体、光源范围等，便于调试。
    • 资产管线：编写编辑器脚本，将传统的Prefab或模型文件，自动或半自动地转换为ECS所需的实体和组件配置。

扩展性设计思考：

  • 插件化系统：考虑将每个高级功能（如动画、粒子、后处理）设计为可选的插件模块。通过定义清晰的接口（如IRenderFeature），允许第三方开发者在不修改框架核心代码的情况下进行扩展。
  • 数据驱动配置：使用ScriptableObject或JSON配置文件来定义渲染质量等级、不同平台的特效开关等，使框架的行为更容易被控制和调整。

4. 常见问题与实战排坑指南

在实际构建过程中，你一定会遇到各种“坑”。以下是我在多个项目实践中总结的典型问题及其解决方案。

4.1 性能不升反降

  • 问题描述：使用了Jobs和Burst，但帧率还不如传统的GameObject方式。
  • 排查与解决：
    1. 检查Job依赖：错误的Job依赖会导致并行化失效，变成串行执行。使用JobHandle.CombineDependencies正确合并依赖，并确保读写同数据的Job有正确的依赖关系。
    2. 检查数据竞争（Race Condition）：在IJobParallelFor中写入共享数据是危险的。确保每个Job只写入自己独立的索引位置，或使用NativeQueue、AtomicSafetyHandle等线程安全结构。
    3. Burst编译失败：在Player Log或Editor Log中查看是否有Burst编译错误或警告。某些C#语法或.NET API不被Burst支持。
    4. 调度开销过大：如果每个Job处理的任务量非常小（比如只处理几个实体），那么创建和调度Job的开销可能超过其计算收益。尝试增大IJobParallelFor的batchSize，或者将多个小任务合并到一个Job中。

4.2 渲染出现闪烁或错位

  • 问题描述：物体位置不对，或每帧图像有细微差异导致闪烁。
  • 排查与解决：
    1. 矩阵同步问题：确保渲染系统读取的LocalToWorld矩阵，是在所有变换系统（如LocalTransformSystem）执行完毕之后。在RenderSystemGroup的OnUpdate顺序中，将渲染系统排在变换系统之后。可以使用[UpdateBefore(typeof(RenderSystemGroup))]或[UpdateAfter(typeof(TransformSystemGroup))]特性来显式控制。
    2. 相机数据不同步：用于剔除的视锥体平面，必须和当前帧用于渲染的相机参数完全一致。确保CameraFrustumPlanes的计算发生在渲染帧开始，且计算后立即用于剔除，中间没有其他系统修改相机状态。
    3. GPU Instancing数据错误：检查上传到GraphicsBuffer的矩阵数据是否正确。常见错误是矩阵数组的长度（Count）与实际实例数不匹配，或者矩阵数据没有在每帧正确更新。使用Frame Debugger检查Draw Call的实例参数。

4.3 内存泄漏与异常增长

  • 问题描述：游戏运行一段时间后，内存占用持续上升。
  • 排查与解决：
    1. Native容器未释放：所有通过Allocator.TempJob分配的NativeArray、NativeList等，必须在Job完成后（通过JobHandle.Complete()）或同一帧内手动调用.Dispose()。Allocator.Persistent分配的内存更需要谨慎管理生命周期。使用using语句块或确保在OnDestroy中释放。
    2. Entity泄漏：创建的实体在使用完毕后没有销毁。确保调用EntityManager.DestroyEntity(entity)或使用DestroyAtEndOfTick等组件。
    3. 共享组件引用：RenderMesh等共享组件持有对Unity引擎对象（Mesh, Material）的引用。即使ECS实体销毁了，如果共享组件数据还在某个Chunk中被引用，这些引擎对象就不会被垃圾回收。需要确保在不再需要时，正确地从所有实体上移除共享组件。

4.4 与现有Unity工作流不兼容

  • 问题描述：美术和策划习惯使用Prefab和GameObject，如何与ECS渲染框架协作？
  • 解决方案：
    1. 使用Hybrid模式：这是最直接的路径。继续使用GameObject和MonoBehaviour进行逻辑和编辑，但通过ConvertToEntity系统，在运行时或烘焙（Baking）时，将GameObject转换为ECS实体。渲染部分完全由我们的DOTS渲染框架接管。这需要仔细设计转换规则，确保所有必要的组件都被正确添加。
    2. 开发创作工具：创建自定义的编辑器窗口和Inspector，让美术人员能够直接在ECS的“实体”概念下进行资产分配和参数调整，并生成对应的“实体预制件”（Entity Prefab）。这需要一定的编辑器扩展开发工作量，但能提供更纯粹、更高效的DOTS开发体验。

构建一个完整的DOTS渲染框架是一场漫长的旅程，它要求你对计算机图形学、现代CPU/GPU架构、数据导向设计都有深入的理解。这七步蓝图提供了一个从核心到外围、从基础到高级的清晰路径。最关键的是动手实践，从一个简单的、只能渲染一个立方体的系统开始，逐步添加剔除、批处理、光照等模块，并在每一步都进行充分的测试和性能剖析。在这个过程中积累的经验和教训，远比最终得到一个“完美”的框架更有价值。当你看到成千上万的实体在屏幕上流畅飞舞，而CPU占用率却依然很低时，那种成就感就是对这场硬核技术冒险的最佳回报。

编程学习 学习日记 实战经验
← 返回列表