Unity 最新DOTS系列之《Baking与Baker的详解》
Unity DOTS Baking与Baker详解
Unity DOTS Baking与Baker详解
最近DOTS终于发布了正式的版本, 我们来分享一下DOTS里面Baking 与Baker的关键概念，方便大家上手学习掌握Unity DOTS开发。
Unity DOTS开发模式,为了让大家在”创作”游戏的时候使用原来组件方式来编辑游戏场景与资源，同时Unity提供了一种Baking机制，把普通的GameObject数据转成ecs模式下的entity数据，程序运行的时候，直接加载转换好的ECS模式的数据。在深入了解Baking与Baker机制之前，我们先熟悉几个概念:
Authoring: 英文单词是”创作”的意思，上文提到ECS模式开发的时候创作游戏节点可以使用原来的方式，再通过baking转换。所以那些待转换成ecs 模式的GameObject与Component被称为Aurthoring。
Authoring Scene: 要转换的传统的GameObject与组件所在的场景称为Authoring Scene;
Authoring Component: 待转换的传统模式下的组件;
Authoring GameObject: 待转换的传统模式下的GameObject;
Baking: 指的是把传统GameObject+组件数据转成ecs模式下所需要的数据的过程;
Baker: 指的是某种Authoring转ECS模式的具体执行者与执行逻辑;
有了这些概念以后，接下来我们来详细地分析Unity DOTS的Baking与Baker。
Unity DOTS Baking 机制核心剖析
Baking是一个单向不可逆的过程，主要是负责把传统的GameObject+Component数据转换成ECS模式下的Entity+Component数据。在DOTS开发模式下，数据可以分成两种，一种是创作数据Authoring data，一种是运行时的ECS模式的数据runtime data。Authoring data灵活，直观,方便我们的创作(即以前的创作模式)，ecs模式下的运行数据runtime data,高效,运行时能快速地生成entity数据。Baking这个过程是发生在编辑模式下，在游戏运行之前就完成了Baking转换，游戏中直接使用bake好的数据即可。如果在游戏中做Baking转换，那么会消耗游戏的运行性能。
Authoring Data: 当你在编辑你的游戏项目应用的时候，像传统的脚本,资源，以及其它的一些游戏数据的依赖，这种编辑方式非常灵活，方便用户查看，与使用。这些编辑的数据，我们叫做Authoring data。
Runtime Data 是ECS模式运行的时候需要的数据，当你运行程序时，作为游戏数据来进行处理。这种模式的数据有高效的性能与高效的存储。它是为计算机运行处理而设计，换句话说对开发者的直观性，没有传统的GameObject模式那么友好。
开发者需要在Unity里面把Authoring Scene作为SubScene加载进来,当编辑Authoring场景中的Authoring 物体时,Baking过程会被触发,并在后台完成。
Baking有两种模式:
Full Baking(全局Baking): 对Authoring Scene里面的所有物体做Baking操作;
Incremental Baking(增量Baking): 只对变化了的物体进行Baking操作;
当整个Authoring Scene被导入的时候，会触发Full Baking。FullBaking是在编辑器的后台模式下处理的，运行的时候不带任何的GUI界面。当一个场景需要被Baking的时候，编辑器就在后台启动执行Baking。Baking是异步操作的,Baking的时候不影响你正常的Unity的操作。但是第一次打开场景的时候可能需要等几秒钟，等场景Bake好后,后面再使用就会快很多。Full baking 只会发生在 ECS data需要加载的时候，不会发生在创作与编辑 GameObject的数据的时候。以下一些情况会导致Full Baking:
1:烘培好的ECS模型下的 entity场景数据不在磁盘上，就会发生Full Baking;
2:Authoring Scene的内容被修改，同时烘焙好的entity scene数据(Runtime Data)过期;
3:如果baking code 在编译Baker代码后发现包含了一个 [BakingVersion] 的attribute (特性), 这个意味着 bake代码被改变了，entity scene 过期了，就会引发full baking;
4:Baking code 的 [BakingVersion] 的属性被修改了，会导致full baking;
5:Project Setting里面的关于Entities 的设置有改变，会导致full baking;
6:在inspterctor 检查器中，点击了 "ReImport"重新导入subscene, 会导致full baking;
7:你在编辑器的 Preferences (偏好设置)清理了baking cache,会到导致full baking;
Full Baking会输出一些文件到存储到硬盘上，当编辑器运行程序会加载这些文件。
当使用subscene机制, 加载一个"创作场景"的时候，同时也初始化了 incremental baking。当在场景中执行一个incremental baking 的过程时,意味着当你编辑一个 "创作创景"的时候，可以直接访问和使用你的baking的结果。它只针对变化的数据与组件进行Bake。
Unity DOTS Baker 机制核心剖析
本身Baking这个过程也是基于ECS模式的,一个简单的 Baking system(baking算法) 需要一个 Baker 从场景中读取里面的"authoring data",并把数据生成到entity 的组件中。创建一个Baker, 新建一个类 Baker
每个组件数据的Baker还需要向系统来注册它执行时候的依赖关系，这样当它依赖的数据发生变化的时候，才会触发这个组件的Baker调用。默认情况下一个Baker只能访问一个 authoring component，但是有时候仍然需要从其它的组件, GameObjects 或者各种各样的资源, 所以整个baking 处理需要知道这些依赖关系，如果其它的这些对象改变了，那么这个baker也需要重新执行。例如，如果是一个 authoring GameObject 是一个cube, Unity在bake的时候，就会把这个entity 渲染成一个cube,如果这个authoring GameObject 随后被修改成了一个 球体, 那么 ECS也必须要相通地做出改变，要把这个entity渲染成球体，这个就意味着unity要删除以前早期的Cube Entity, 并创建一个新的球的entity,或者改变entity让他显示一个球体。又比如 一个GameObject 有一个材质, 依赖一个 scriptable object。Baker需要定义一个资源依赖，这样才能确保资源 scriptable object被改变的时候，这个object 会被重新Baker。整个过程全部都是自动发生的，我们普通开发者可以不用管。
最后给大家展示一个普通MonoBehaviour Component的Baker，代码如下:
ECS Component:
publicstructDependentData:IComponentData
{
publicfloatDistance;
publicintVertexCount;
}
Authoring Component:
publicclassDependentDataAuthoring:MonoBehaviour
{
publicGameObjectOther;
publicMeshMesh;
}
定义从Authoring Compongt到ECS Component的Baker:
publicclassGetComponentBaker:Baker
{
// Bake的时候调用Bake函数
publicoverridevoidBake(DependentDataAuthoringauthoring)
{
// 声明所需要Baker的依赖关系
DependsOn(authoring.Other);
DependsOn(authoring.Mesh);
if(authoring.Other == null)return;
if(authoring.Mesh == null)return;
vartransform = GetComponent
vartransformOther = GetComponent
if(transform == null)return;
if(transformOther == null)return;
varentity = GetEntity(TransformUsageFlags.Dynamic);
AddComponent(entity,newDependentData
{
Distance = Vector3.Distance(transform.position,transformOther.position),
VertexCount = authoring.Mesh.vertexCount
});
}
}