Three.js: 实用程序：弃用导出器（Blender、3DS Max 和 Maya）

为此+1 - 回购中存在维护不善和过时的出口商对于新手来说是不必要的混淆点，特别是因为@Mugen87指出现在有更好的选择。

注意：官方 GLTF Blender 导出器 (https://github.com/KhronosGroup/glTF-Blender-Exporter) 目前不允许正确的动画导出（目前每个对象仅支持 1 个动画）。
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnul与此 repo 中的 Blender JSON 导出器相比如何？

@looeee
Blender JSON 导出器可以很好地导出动画。 在某些情况下，UV 或顶点法线会出现一些奇怪的故障，而这些故障在 GLTF 导出器中不存在，但那是另一回事了。

好吧，我不使用 Blender，所以我不会进一步评论。

但是，我可以根据经验说，尝试使用 3DS Max 导出器（几年未更新）是一件令人头疼的事，我强烈支持将其从 repo 中删除，以支持 FBX 格式。
FBXLoader 现在支持 3DS Max FBX 导出器导出的几乎所有内容，并且由于该导出器由 AutoDesk 维护，我们可以指望它保持最新状态。

与 Maya FBX 导出器类似，尽管 FBXLoader 仍需要更新以正确支持那里的枢轴点。

如果我没记错的话，当您选择BufferGeometry时，Blender 不会导出动画。 变形目标肯定有问题，请参阅#10932。 此外，导出器使用“旧”动画层次结构格式，而不是当前动画系统中的一种。

我认为我们也应该删除 Revit 导出器自述文件 - 它只是链接到一个单独的存储库，看起来在过去几年中几乎没有被触及。

可能有数百个 Three.js 工具我们可以像这样链接到，但除非我们愿意确保它们得到积极维护和正常工作，否则我认为我们不需要在此处包含指向它们的链接。

谷歌搜索“three.js revit exporter ”发现repo 无论如何都很好。

我认为我们也应该删除 Revit 导出器自述文件 - 它只是链接到一个单独的存储库，看起来在过去几年中几乎没有被触及。

👍

回购中存在维护不善和过时的出口商对于新手来说是一个不必要的混淆点

我只想强调这个声明，因为我认为它对three.js非常重要。 当用户遇到这些导出器时，他们希望工具能够正常工作。 但在大多数情况下，他们会感到困惑，并且可能对整个项目产生不好的印象。 那不好。 😢

作为一个无辜的用户，我敢不敢发表意见……

关于搅拌机：
如果 Three.js 有一个原生的 .blend 格式导入器，
显然不需要出口商。

Blender 端无需安装，
没有通过 python 代码从 Blender API/structs 编译到 javascript ......

用python编写JSON导出器付出了巨大的努力，
我想知道为什么你们合作者没有选择这种方式......？

@wolfgangvonludwigsburg
这是一个相当简单的问题。 Blend格式不是很接近three.js内部表示，所以需要一些转换。 Three.js 的 JSON 格式非常接近内部表示，因此无论您选择将其称为 Exporter 还是 Loader，从 Blender 表示到three.js 的转换工作都存在。 话虽如此，.blend 不是一种常见的传输格式，除了 Blender 之外没有任何东西真正支持它，因此拥有一个加载器会满足相当少的受众，因为即使是大量使用 Blender 的人也倾向于使用其他软件，而 .blend不是作为交换格式的选择格式。 通常是 obj、fbx 或一些开放标准，如 gltf 或 collada。

@wolfgangvonludwigsburg如果您要考虑构建 .blend 文件加载器，这可能是一个不错的起点：

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

许多感谢您的意见！

但是为什么 Blender JSON 导出器如此容易出错......
=> 这取决于 Blender API，是用 Python 编写的，应该理解 Blender 数据结构，
并编译为 JSON 格式，three.js 重新转换为其内部结构......

很多任务都可能（而且确实会！）失败，主要是在 Blender 版本更改上。
好吧，我更喜欢“直接数据编译”的方式......

好吧，我更喜欢“直接数据编译”的方式。

这可不是什么好办法。 将blend文件直接加载到应用程序中是一种误用。 相反，您应该使用一种用于数据传输和资产交付的文件格式。 glTF是第一个从应用程序的角度关注这一方面的标准化格式。 这就是我多次宣传glTF的原因之一😇。 它应该成为所有即将推出的 3D 应用程序的标准。

好吧，我更喜欢“直接数据编译”的方式......

不幸的是， .blend这种方式使用.blend格式进行逆向工程。

对于最初的问题，我将跳过添加是/否投票，因为我不太熟悉 3D 创作工作流程。

但作为维护者，主要是 JS 开发者，能够专注于加载和支持 FBX 和 glTF 等格式（它们积极维护第三方创作工具）确实更有可能提供可靠的结果。

此外，如果当前的 glTF 生态系统存在任何问题，使其无法成为解决此类需求的足够好的工作流程，那么这也是有用的反馈。 🙂

我没有争论使用 Blender .blend 格式作为通用交换格式，
但它可能会简化 Blender 和three.js 之间的协作......

我无法估计在 Blender 框架下维护 Python 导出器 + GUI 的努力，
但我想，这很容易成为一种恐怖……;-)

@donmccurdy
顺便说一句，Wavefront .obj、3D Studio .3ds 也是原生格式，广泛使用......

顺便说一句，Wavefront .obj、3D Studio .3ds 也是原生格式，广泛使用......

是的，我认为这里没有提到 OBJ，因为该格式不支持一些流行的功能，例如动画，但是three.js 肯定会在很长一段时间内继续支持 OBJ — 它是一种经典且可靠的格式。

3DS Max 的.3ds与 Blender 的.blend或 Maya 的.mlt或 Cinema4D 的.c4d属于同一类别。 每个编辑器都有自己的内部格式，这些格式会随着软件的变化而变化。 与使用编辑器自己的开发人员提供的导出格式相比，为每个建模工具的私有内部格式维护加载器要困难得多且容易出错。 值得注意的是，3DS 和 Blender 都内置了 FBX 导出——由它们的作者维护——并且 Blender 也将在未来版本中内置 glTF 导出。

最后一投...

我们已经有一个独立的前/进口商的建模工具：Collada，
但出于某种原因，这些似乎并没有被广泛接受。

最好我确实有这种实现方式：
基于Google Protocol Buffers的加载解决方案

https://developers.google.com/protocol-buffers/

它是

...用于序列化结构化数据的语言中立、平台中立、可扩展的机制——想想 XML，但更小、更快、更简单。

由于我们必须处理的 2D/3D 矢量数据本质上并没有那么复杂，因此开发一个 Blender 数据文件模式应该是简单可行的......

javascript 中实际上有一个混合文件解析器😁
https://github.com/Galactrax/js.blend

呃，我得到了支持...... - 谢谢 mrdoob ;-))

最大（Terrabyte的条款）3D模型中的应用（谷歌地图3D）采用这种高效实现的那种（protobufs）...

沿着加载 .blend 的路径走下去可能不是很理智。 但与加载 .dae 和 .fbx 并没有什么不同......

无论如何，我同意贬低出口商的想法。
但是，我会等到 gltf 更加成熟并经过测试。 2018 年夏天？

我也同意删除这些出口商。 您甚至可以将它们移动到其他一些可以 RIP 的存储库 :)

但是，我会等到 gltf 更加成熟并经过测试。 2018 年夏天？

等待对我来说似乎是合理的。 特别是对于 glTF，最好先准备一些东西：

• [ ] 内置 glTF 导出的 Blender 运输，以及多种动画支持。
• [x] 改进了从 Maya 和 3DS Max 到 glTF 的工作流程，或者只是对FBX2GLTF 进行了更多测试。
• [x] glTF 2.0 官方 COLLADA2GLTF 转换器的更新。

在 2018 年夏季重新审视这个问题听起来是正确的。

但是，我会等到 gltf 更加成熟并经过测试。 2018 年夏天？

对于 Blender 出口商，我倾向于同意。 但是我建议至少立即删除 3DS Max 导出器，因为 FBX 中已经有一个成熟且更好的替代方案。

但是我建议至少立即删除 3DS Max 导出器，因为 FBX 中已经有一个成熟且更好的替代方案。

对我来说很好听👌

好的，3DS Max 导出器不见了。 让我们在几个月后重新审视其他出口商（Blender 和 Maya）。

我认为那个时候 Maya 导出器不会有太大变化。

我们现在应该评估一下。 我会测试一下，看看是否值得在接下来的几天内保留它。

好建议👍。

只要我们在这里， https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx的状态如何？ 似乎可以用像 obj2three 转换器这样的 node.js 脚本来代替，只需使用 THREE.FBXLoader 并在最后进行序列化。 目前转换器有很多未解决的问题：

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

还有 msgPack、UTF8 和 CTM 转换器——它们已经很多年没有接触过了。

它们仍然对任何人有用吗？

@donmccurdy恐怕您无法在 node.js 脚本中使用FBXLoader因为您无权访问 DOM。 所有使用TextureLoader加载器都依赖于ImageLoader ，因此依赖于document 。 我们会得到像ReferenceError: document is not defined这样的运行时错误。 从FileLoader访问的window对象也存在同样的问题。

作为临时解决方法，也许我们可以在fbx2three.js文件中重新定义ImageLoader和FileLoader ？

也许我们可以在 fbx2three.js 文件中重新定义 ImageLoader 和 FileLoader？

我认为这很简单，而且仍然比现在的 python 转换器需要的代码少得多……我会试一试。

也许我们可以在 fbx2three.js 文件中重新定义 ImageLoader 和 FileLoader？

好主意：脸红：

3DS Max 的 .3ds 与 Blender 的 .blend 或 Maya 的 .mlt 或 Cinema4D 的 .c4d 属于同一类别。

这可能不完全正确，.max 更像是同一类别，.3ds 相当精简。

我喜欢将 3ds max 导出器作为如何编写导出器的示例，以及在 maxscript 上。 我不认为我曾经能够通过 fbx 从 3ds max 导出正确的切线空间，使用 maxscript 很容易进行实验并获取您需要的东西。

值得放入一个带有适当免责声明的新仓库吗？ 所有这些都是关于如何编写导出器的示例，但如果它没有维护并且 FBXLoader 现在更可靠，我们不希望人们认为这是将资产从 3DS Max 引入到three.js 的推荐方式。

是的，如果有的话，我会投票支持新的回购。

只是想在完全放弃 json 格式之前添加：我们正在使用 Blender 导出器进行场景导出，即使用动画和自定义属性以及占位符对象设置相机和场景层次结构，然后在运行时由真实网格动态替换（加载以其他方式）。 由于这只是 json，因此很容易在 js 中进行内省和修改并执行此类操作。 我不确定例如 glTF（至少在它的当前形式中）是否适合作为场景格式，所以希望 Blender 导出器和 json 格式会坚持更长时间

@pjoe我希望 JSON 格式和 Blender 导出器在短期内比本线程中提到的其他东西（例如 3DS Max + Maya 导出器）更有可能

但同样如此，如果能得到您对 glTF 和Blender exporter 的反馈，那就太好了。 您提到的所有内容均受支持：

• 设置相机
• 场景层次
• 动画（对于多个 Blender 操作，您需要不同的导出器）
• 自定义属性（在选项中选择“Export extras”）
• 材料、元数据等的“只是 JSON”。 网格数据被优化为单独的二进制有效载荷

@donmccurdy必须承认我没有大量的 glTF 经验（至少目前是这样）-尽管我确实尝试阅读规范 :)

我想我的主要“牛肉”与 glTF（我认为这是一种很好的传输格式，也非常适合尽可能快速直接地将“字节”放入 GPU 缓冲区）是所有 refs 都是基于索引的，这不是一个好适合可变场景格式。 因此，例如，如果您想删除条目或在中间添加内容，则需要在该位置之后更新对索引的所有引用。 做这个“索引管理”很快就会变得非常混乱。

从我与 Blender glTF exporter 一起度过的短暂时间来看，当时（大约两个月前）它似乎还很不成熟。 这显然可以通过帮助改进它来纠正:)

...所有 refs 都是基于索引的，这不太适合可变场景格式。 因此，例如，如果您想删除条目或在中间添加内容，则需要在该位置之后更新对索引的所有引用。

是的，它不是为这种意义上的手动编辑而设计的，作为运行时/传输格式，可能永远不会。 有各种可以使用它的

一般来说，我发现 glTF Blender 导出器比任何其他 Blender 输出提供更好的结果，但如果您发现特定问题，请提交错误。 :)

@donmccurdy同意 glTF 忠实于传输/运行时......关于它的一大好处，正是它没有试图成为适合所有格式（如 collada - 不要让我开始）。

我们正在尝试避免额外的库或转换开销，因为我们正在做一个需要小而快的 web 应用程序 - 到目前为止，three.js JSON 格式非常适合作为这个用例的场景格式。 能够在 Blender 中设置整个场景，例如相机动画，只需导出、加载并在运行时动态替换模型（我们可能很快就会在某个时候使用 glTF）——这一切都使得管道相当流畅为了我们 ：）

作为旁注，我们还使用 webpack json 加载器将场景文件包含在我们的主包中 - 使其更容易处理。

我认为那个时候 Maya 导出器不会有太大变化。 我们现在应该评估一下。 我会测试一下，看看是否值得在接下来的几天内保留它。

@looeee我很好奇，你有这方面的消息吗😊？ 您认为我们现在可以删除导出器并改为引用FBX吗？

您认为我们现在可以删除导出器并改用 FBX 吗？

我只做了少量测试，计划做更多，但我没有时间。 但我会说是的，我们应该删除它并努力使 FBXLoader 完全支持 Maya。

作为 Blender 导出器的用户，在这里插一句：拥有 JSON 的一个优点是导出后修改非常简单。 Blender 只是我们自动化工具链的一部分，我们对导出的 JSON 进行了大量处理，然后才准备好进入我们的 Web 查看器。 拥有与内部 Threejs 格式如此接近的传输格式，对我们来说是一个重大的收获。

此外，我们还对其他导出格式进行了一些测试，发现 JSON 格式在传输大小方面还不错，一旦压缩得当，比 Collada 或 FBX 好得多，例如。 我们做了一个基于 protobuffers 的快速试验，这样可以做得更小一些，但对我们来说没有什么值得麻烦的。

对于大场景和慢速客户端，解析转换为内部 ThreeJS 模型的速度也变得很重要。 由于 JSON 解析在浏览器中进行了大量优化，并且模型结构非常相似，我们假设 JSON 格式在这方面做得很好。 没有实际测试过这个。

Soft8Soft 刚刚为 3ds Max发布了

谢谢@alexkowel ，很恭喜！）。 如果您可以在此线程上添加链接，我们会将其与其他 glTF 资源一起列出。 🙂

@dherben优点，谢谢-

关于解析速度，我希望您会发现 glTF 更快。 本质上的区别在于元数据仍然“只是 JSON”，而有效载荷的大部分（顶点位置、动画数据）位于 ArrayBuffer 块中，可用于为THREE.BufferAttribute构造函数创建类型化数组。 在完全优化的加载器中（我不知道 THREE.GLTFLoader 是否已经存在），您不必在 JS 中读取或复制该数据。

但是对于作为管道一部分的数据修改，我同意纯 JSON 更容易使用，正如您所说。 有各种语言的库可以使用 glTF，但工具还不是很成熟。

此问题的当前状态：

出口商：

• [X]玛雅出口商
• [X] 3DS Max 导出器
• [X]搅拌机出口商
  
  
  
  • 现在哪儿都不去，以后可能会再去。
  
  
  • 2018 年 5 月删除。
  
  

转换器：

• [ ] FBX
  
  
  
  • 提议的简化替换为https://github.com/mrdoob/three.js/pull/13013； 需要测试
  
  
• [ ] CTM（未讨论）
• [ ] utf8（未讨论）
• [ ] obj2three（未讨论）

编辑：2018 年 5 月更新。

@donmccurdy只是想在对 glTF Blender 导出器和 Three.js 加载器进行更多实验后回来。 事实证明，到目前为止，它实际上作为我们用例的场景格式工作得很好。 我现在要做的是将导出的 glTF 文件加载到 Three.js 场景，然后在第一次渲染之前操作 Three.js 场景层次结构（用动态加载的东西交换占位符）。

我可能仍然希望在 glTF 导出器中看到一些功能，将尝试在那里发表评论或做 PR :)

我可能仍然希望在 glTF 导出器中看到一些功能，将尝试在那里发表评论或做 PR :)

厉害了，拜托了！ 🙂

Blender 出口商现在不会去任何地方，将来可能会重新访问。

那么有人会处理当前的 Blender 导出器错误吗？ 我希望答案是否定的。 在这种情况下，我们应该这样说。

如果在我之前没有其他人这样做......我想，至少，尝试解决轮换问题。 #13130

那么有人会处理当前的 Blender 导出器错误吗？ 我希望答案是否定的。

我没有阅读整个讨论，而是我的两分钱。

上周，我被要求帮助一家拥有解决方案的公司，该解决方案在永久展览内的内容交付中使用 Three.js。 带有用户可以探索和互动的 3D 模型的标牌。 早已不复存在的原始开发人员使用Three.js JSON 格式。 准备和获取新模型（以更改运行时代码为条件）是一场真正的噩梦。

恕我直言Three.js应该专注于支持已建立和快速增长的格式，例如FBX和glTF 。 优先考虑那些可以容纳多个 UV 数据箱的格式（因此不应该鼓励心爱的 OBJ）。 然后动画。 我知道 Blender 导出插件应该支持两者，但 FBX 也是如此。

想象一下 Blender 的东西出去的工作流程

1）WebGL
三.js 明显😃

2) OpenGL 3.3+
原料/煤渣

3) RISC 上的 OpenGL ES 2.0
从智能手机到树莓派

4) 游戏引擎

5) 与媒体服务器集成的实时图形应用程序（Hippo、D3 伪装）
那些舞台 VFX 人使用。

目标是使用 1，最多 2 种格式，而不是必须为不同的输出使用许多不同的导出器。 在前3种情况下编写OGL时……应该使用相同的模型格式，仅此而已。 对于最后两点，FBX 是王道（跨包对 COLLADA 的不同实现使其难以使用）并且实际上模型并未“暴露”。
我不是在抨击Three.js JSON 格式或 Blender 插件（ @mrdoob 🙇 🙏），它有（有？）它的用途，并且可能是为了解决其他格式当时无法解决的问题而发明的（而且我确实这样做了）也有 NIHS 综合征）。
我只是想从一个必须不断地向行业内的不同输出交付的角度来分享这一点。 Three.js JSON 格式不适合这种环境，它是多余的。

@kroko绝对同意👍

我认为格式格局开始变得更加清晰。 三.js json格式做的，因为当时没有json格式。 当我已经在做渲染引擎和 API 时，定义文件格式是我最不想做的事情 😩

作为一个新手，Three.js JSON 导出器很有教育意义，因为它让我能够看到原始数据和输出几何的底层结构。 其他导出器尽管效率很高，但不会让您看到数据，因为它们大多采用二进制格式。

我同意从这个 repo 中删除它是今天最好的选择，但正如@hccampos所说，也许可以将它放在自己的 repo 中以保留用于教育目的。

我同意从这个 repo 中删除它是今天最好的选择，但正如@hccampos所说，也许可以将它放在自己的 repo 中以保留用于教育目的。

始终可以选择从http://threejs.org/editor/导出为 JSON

在https://github.com/mrdoob/three.js/pull/14117 中关闭

我建议我们现在关闭所有与 Blender 导出器相关的未解决问题。 同意吗？

我认为有人可能会为 3D 模型导出/导入（用于基本和特殊功能）、常见故障排除以及修剪或更新所有过时的文档和示例编写一些“官方”文档/管道。 考虑到您不再有搅拌机 json 导出器，例如，骑士示例非常令人困惑。 也许 3d 模型的 JSONLoader 应该只是为了兼容而保留，但我们必须阅读它，等等。

@stmaccarelli这里有一些新文档： https : //threejs.org/docs/#manual/introduction/Loading -3D-models，但是请让我们知道还有什么有用的！

@donmccurdy我认为
现在整个 3d 导入/动画系统，考虑到文档、示例和来自不同时代的互联网上的东西的混合，令人困惑。

如果单个对象的引用是正确的，那么主动画系统文档就可以了。
让我们以 AnimationClip 参考为例。 我不确定我是否以正确的方式导出 morphTargets，但在这里我读到：

_.CreateClipsFromMorphTargetSequences ( name : String, morphTargetSequence : Array, fps : Number, noLoop : Boolean ) : Array
返回从几何体的变形目标序列创建的新 AnimationClip 数组，尝试将变形目标名称排序为基于动画组的模式，例如“Walk_001、Walk_002、Run_001、Run_002 ...”_

问题是，如果我导入一个 glTF 文件，则没有 morphTargetSequence 数组...这里和那里存储了一些 morphTargetSomething 对象，但我不知道使用什么以及如何使用。

我认为我们应该有一些文档以非常简单的示例来描述 3D 模型管理/工作流程。
并且 3D 加载器引用都应该遵循相同的模板。
让我们说
1-简单的3D模型导入
2- 材料导入（所有的花里胡哨，如不同的贴图、贴图参数、多材料管理等）
3- 整个场景导入（例如如何遍历/管理导入的场景，例如来自 glTF 的场景）
4- 骨骼动画导入和管理
5-变形动画导入和管理

我们还应该检查所有具有 3D 模型加载功能的示例是否遵循相同的模式。

我们应该更新示例，虽然不可能，但我们应该清楚地写下某些部分已弃用以及什么（例如在 Knight 示例中...）

_EG-如果我们决定不推荐使用 3D 模型的 JSON 文件格式，而是支持 - 比如 - glTF，那么唯一具有骨骼动画和 morphtargets 特征的动画示例是旧的骑士动画示例，它使用10 个版本以前的 JSON 模型，存储不再使用的数据结构。_

@stmaccarelli没有单一推荐的端到端工作流程； 我认为鉴于不同的技能水平、对免费与付费建模工具的偏好以及特殊需求，我们很难提供这些。

我认为您通常不需要CreateClipsFromMorphTargetSequences方法。 上面的文档没有详细介绍使用任何特定加载器的细节（正如你提到的，它们是不一致的），但是GLTFLoader 文档做了——

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

在这种情况下，剪辑是 TRS、蒙皮还是变形目标并不重要——您可以播放所有动画。 我已经使用 Mixamo 和 Blender编写了另一个使用 Maya 的。

我们还应该检查所有具有 3D 模型加载功能的示例是否遵循相同的模式。

并且 3D 加载器引用都应该遵循相同的模板。

这是一个公平的观点，我们在这里还有一些改进的空间。

唯一具有骨骼动画和变形目标的动画示例是旧的骑士动画示例，它使用 10 个版本之前的 JSON 模型，存储不再使用的数据结构，这是没有意义的。

严格来说，JSON 格式和数据结构并没有被弃用，它仍然是一个完全合理的 [反] 序列化场景的方法，但需要注意。 @mrdoob您如何看待我们替换一些动画示例？ 如：

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

您如何看待我们替换一些动画示例？

+1 为此。 我投票赞成至少用 Mixamo 的更现代模型替换animation / skinning / blending a 中的士兵，例如这个：

我们可以在空闲/步行/跑步之间进行混合，如果愿意的话，可能可以将模型转换为 glTF。

模型大小约为 9mb，而当前模型以及所有相关文件为 71mb！

对于animation / skinning / morph我们可以使用我一直在测试 FBX 变形目标的模型：

它的大小与当前的骑士模型大致相同，但由于变形目标更常用于面部表情，我认为这个更有意义。 同样，它目前采用 FBX 格式，但如果愿意，可以将其转换为 glTF。

以下是一些需要考虑的示例：

| 截图 | 链接 | 尺寸 |
|---|---|---|
| | 链接| 6 MB |
| | 链接| 3 MB |
| | 链接| 5 MB |
| | 链接| 12 MB |

它们都是动画的，在three.js 中正常工作，并且可能比Sketchfab 下载版本更多地压缩或优化。 我没有一个具有良好跑步/步行周期的操纵角色，但Mixamo->glTF 工作流程还不错。