AFrame / Three.js：加载复杂的 .obj 文件时，为什么内存中有这么多（JS）字符串？答案

【问题标题】：AFrame / Three.js : why so many (JS)Strings in memory, when loading complex .obj files?AFrame / Three.js：加载复杂的 .obj 文件时，为什么内存中有这么多（JS）字符串？
【发布时间】：2018-11-30 19:30:24
【问题描述】：

我们有一个非常复杂的网络场景，我们在其中动态加载非常复杂的 .obj 和 .mtl 文件。在将没有任何这些对象的场景与内部有多个对象的场景进行比较后，我们注意到了一种奇怪的行为：

firefox 内存堆显示大部分内存（>100MB 用于 5 个对象）用于 JSStrings。其余的内存用于对象，当我们在其中有复杂的对象文件时，这是不言自明的。
但是为什么会有大量的字符串，我们能减少它吗？ AFrame 是否将 .obj 文件的内容转换为字符串？

我们考虑过最小化 .obj 文件本身并减少顶点。也许你们当中有人有类似的经历和/或可以给我们建议如何解决这个问题。

提前谢谢你:-)

【问题讨论】：

它必须获取并加载原始 OBJ 文件（作为文本），它是一个字符串。然后它解析为对象。 OBJ/MLT 文件有多大？
我们的文件大小在 1 到 50 MB 之间
是的，那是唐的回答。您看到的内存是获取并缓存的模型文件的文本（然后对其进行解析）。您可以尝试从three.js 网络缓存中释放内存。 (delete THREE.Cache.files['someurl'])
是的，我认为转换是唯一真正的选择。不过你的删除方法看起来也很有趣，我试试看，谢谢！

标签： javascript web memory three.js aframe

【解决方案1】：

OBJ 文件是基于文本的，不幸的是，它不是一种特别有效的 3D 数据传输方式。 A-Frame 必须解析该文本才能将您的数据上传到 GPU。

如果您需要避免这种情况，我建议您尝试将您的 OBJ 文件转换为二进制格式，例如 glTF (.glb)。您可以使用 obj2gltf (CLI) 或 https://cesiumjs.org/convertmodel.html (web) 进行转换。 glTF 文件的加载速度会更快。

【讨论】：

感谢您的良好解释和建议。 gltf 文件的问题是我们的设计师使用“Rhino”并且只能以 OBJ 格式导出模型。但是转换的东西是一个非常好的点。也许我们应该测试将 OBJ 文件转换为 glTF 并加载它们是否比仅加载 OBJ 更快。你知道我们还能做些什么来减少字符串的使用吗？减少 OBJ 中的行数，减少顶点数，甚至操作一些 AFrame 函数？
恕我直言，OBJ 是一种糟糕的格式。它的材料处理非常有限..它需要多个文件来打包资产..它基于文本..它不支持压缩。它不能真正处理分层/嵌套对象，并且随着不同的公司试图解决它的缺点，格式有无数种变化。
GLTF otoh 是一种非常现代的格式，专为互联网内容交付而设计。它支持完整的场景描述和 PBR 等现代材质格式。它支持网格压缩，二进制风格允许您将所有相关的模型组件打包在一个文件中。它还支持元数据，因此您可以将自己的应用程序数据存储在文件中，从而允许单个文件资产交换。我们越早采用它，所有建模软件就能越早实现无缝互操作。
它也有两种风格，文本和二进制......所以如果你真的需要文本数据来调试你的管道，它就在那里，并且人类可读。
“也许我们应该测试是否将 OBJ 文件转换为 glTF”——好吧，用 JavaScript 转换它们不会更快。但是您可以提前离线转换它们，然后在您的应用程序中使用 glTF 文件。也许 Rhino 将来会获得 glTF 支持：mcneel.myjetbrains.com/youtrack/issue/RH-42754