如何实现场景的保存和加载

[greyishsong]

功能设想

我的设想是加载保存的文件后，可以还原保存时几乎所有内容，类似 Blender 保存的 .blend 文件。为了达成目标，就应该允许用户保存场景中所有可见的内容（地面棋盘格除外），具体包括：

• 现有的组和物体名称、变换、材质等属性
• 各物体下的所有 mesh
• 相机和光源

实现方案设想

实现保存和加载就是实现序列化和反序列化。按照一般的技术习惯，把场景保存成一棵树，利用节点关系保存场景结构是比较清楚的。按这样的思路，调用过程从浅到深依次是：

1. 场景的序列化接口
2. 各组、相机、光源的序列化接口
3. 各物体的序列化接口
4. mesh、材质等的序列化接口

问题

现在我有几个主要的问题：

• 到底要不要序列化场景中所有的数据（这决定我们要不要按上面的思路来）
• 主相机要不要被序列化，或者说观察视角要不要保存
• mesh 是只保存文件路径（引用）还是直接保存数据
• 用什么文件格式保存，JSON 还是 XML（我们这种 Group-Object 两层的简化结构好像和大多数通用场景文件的多层树结构不兼容）

[geezmolycos]

我理解的原则和用户的需要是，保存的场景要能恢复上一次工作的状态，所以我认为应该：

• 序列化所有的数据，包括相机位置、观察视角等。但有一些信息可以看作「全局设置」，可以不存在场景存档中
• mesh 因为咱们的程序里面能编辑，要是保存文件路径，那要不然需要覆写原来的文件，要不然就要生成额外的文件。blender 两种都实现了，让用户选择可以内嵌或者外部链接。但是我想咱们精力有限，还是直接内联到场景存档里就行了
• 应该把场景保存和 mesh 导出这两个功能分开（后者也可以不做），所以 mesh 数据内联到场景存档中，不会造成劣势（如果采用了 glb 这样可以在3d软件里互通的格式，根本就不用单独实现 mesh 导出了）

然后就剩下最后一个问题了。文件格式的选择我有两种方案，GLB 是我认为更合适的，但是实现上可能会稍麻烦一些

保存为 GLB 格式的方案

这个方案就是实现一个 GLB 格式子集的保存和读取。咱们用的「Group-Object 两层的简化结构」可以当成树状结构的子集，读取的话不符合的可以不读。gltf 里面没有的东西，比如光源，可以和 blender 一样用扩展的对象。

GLB 格式大概就是场景架构用 JSON 表示，mesh 这些二进制数据附加到后面。这样灵活性和性能都还可以。

我分析的好处是：

• 有具体的文件规范，兼容性不用怎么考虑，还能用现成库
• 咱们需要保存的东西，基本上都支持，不支持的也可以用扩展
• 其他软件可以读，方便检查结果

不好的地方是：

• 有人可能会尝试导出其他软件生成的 GLB，只支持子集，不支持的地方会出问题，可能被当成 bug。对一般用户来说，文件里面的结构是透明的
• 没有的特性和格式不同的地方可能需要 workaround

自己规定一种格式

如果要考虑性能，不用可读性，感觉还可以使用 protobuf。XML 感觉太重了，容易出问题的地方比较多。

这个方法也包括 JSON / XML 这样虽然通用的格式，但是要自己制定语义和规范。如果要选这个的话，我分析的好处是：

• 实现起来比较快
• 不用考虑已有格式的具体细节，减少妥协
• 框架扩充独特的功能了以后，可以很方便新增到保存格式中
  不好的地方是：
• 需要维护一个格式规范，还要考虑向前向后兼容
• 别的软件不能读取，不方便检查问题（比如读取里面的 mesh 检查几何处理算法有没有问题）

[greyishsong]

我自己更倾向于用 JSON 做载体，主要是轻量且可读性比较好。不过直接用原生 JSON 来存储大量的数值（比如导出的 Mesh 几何数据）性能太差，我们多半会需要混合一些二进制方案。

这个方案就是实现一个 GLB 格式子集的保存和读取。咱们用的「Group-Object 两层的简化结构」可以当成树状结构的子集，读取的话不符合的可以不读。gltf 里面没有的东西，比如光源，可以和 blender 一样用扩展的对象。

GLB 确实是一个比较直接的解决办法，而且可以部分使用 Assimp 的导出功能，不过自己维护扩展对象也是一种麻烦。@geezmolycos 提到的自有格式问题，我的看法是：

• 需要维护格式规范，这个问题用 GLB 的话也存在（因为需要维护扩展对象）
• 需要考虑向前向后兼容，我们可以在 minor 版本保持兼容，major 版本破坏兼容
• 别的软件不能读取，用单一文件导出基本无法解决

所以我有一个新想法，就是将项目导出成目录而不是单个文件，用 JSON 和 OBJ 混合的办法平衡通用性和处理自有数据的便捷性两方面要求。直接将项目中每个 Group 导出成一个 OBJ 文件，解决几何数据导出以后不能通用的问题；而将其他所有数据（包括材质数据）都导出到同目录的 JSON 文件里，这部分数据的格式我们自己维护。

[geezmolycos]

如果采用导出成目录的设计，我想也可以导出成zip或tar文件。这样的话好处是也方便编辑，而且单文件对提交和发送都比较方便。这个思路和docx等格式类似

[greyishsong]

可以导出成压缩包，不过如果导出时就压缩的话想用其他工具检查模型岂不是不太方便了吗？另外 zip 不包含文件名编码信息，跨平台很容易出问题，如果要打包的话还是建议用 tar 或者 7z 之类的东西。

[geezmolycos]

考虑到咱们框架主要是教学用，感觉保持透明度还是比较有必要的。因此我感觉你提出的用 json 和 obj 的设计挺可行的。我想我们可以先规定 json 格式的语法。至于我说打包提交和发送方便，现在还没遇到这个问题，可以先直接输出文件夹，如果要改也很直接

[greyishsong]

那咱们就在这个话题下写 JSON 格式草案吧，我每一部分开一个 comment，要修改就在这个 comment 下回复。

[geezmolycos]

我今天看了一下 JSON Schema 还有 C++ 读写 JSON 的库，准备先实现一下，会建一个分支更新进度

[greyishsong]

Scene 序列化格式

暂定包含版本等元数据和场景中组、光源和相机列表。

[greyishsong]

Group 序列化格式

暂定包含 Object 列表，并记录导出的文件名

Object 序列化格式

暂定包含材质、物理属性和 Mesh 列表

[greyishsong]

文件导出方式

暂定和导入文件的逻辑保持一致，每个 Group 导出为一个 OBJ 文件。