首先，感谢其他两位回答者。同样 basszero 你对混合文件的看法是对的，我应该先检查一下维基百科！这是一个几乎没用的 Blender 内存的二进制转储。
写完这个问题后不久，我决定继续写一个 OBJ 加载器，因为 1）它会给我加载 3D 文件格式的体验，以及 2）它看起来不错，常用但也很容易载入。这最终成为了一个伟大的决定，因为它让我意识到，我实际上并不知道对象和组之间的区别，而且我对材料也不太了解。它帮助我建立了这些 3D 结构的代码。
两个答案都推荐基于 XML 的格式。我不想要 XML 格式。我认为这不是 XML 的正确位置。我相信创建这些格式是因为 XML 灵活、通用且易于为其创建模式，但这不是我想要的。我想要一种可以快速加载的格式（相对而言，XML 不是），它不必是灵活的或人类可读的，并且我可以为它编写一个导入器，而不是依赖于 XML 库。 basszero 甚至说，“以成为 XML 为代价”，他完全正确；这是我觉得不值得承担的成本。
我的 OBJ 加载器已完成。我将它与实际的模型类分开，并使用 MeshFactory 接口实现它，以便将来我可以根据需要编写不同的加载器......这是计划。过去几天我一直在做更多的研究，并决定使用 ms3d 格式。
ms3d 格式支持骨骼绑定（关节）和关键帧骨骼动画，此外还支持纹理贴图和 Alpha 贴图。此外，它是一种易于计算机读取的二进制格式，不浪费空间（如 XML 和 OBJ），带有人类可读的标签和标签等。
不幸的是，Blender 没有（工作的）ms3d 导出脚本，所以我将自己编写一个脚本。幸运的是，这不是一个艰难的过程，您可以阅读 Blender 的文档并使用其他导出器作为示例。我将不得不复习我的 Python，但除此之外，从我在其他脚本中看到的情况来看，它似乎非常简单。
Java 方面的东西应该很简单，实际上它比 OBJ 格式更容易，因为 ms3d 更加结构化。我在网上找到了 specifications 用于 ms3d 格式的 C 风格（天才！），因此它们非常不言自明，我对格式没有进一步的问题。我将根据这个规范来实现我的实现，尽管我以后可能会实现我自己的变体；这是编写自己的导入器和导出器的好处，我可以根据需要修改格式。
总而言之，我认为这是最好的解决方案。
basszero，你是绝对正确的，正如我从我的 OBJ 加载器中看到的那样：“一旦你把它全部读入，数据的组织（显示列表、纹理、顶点数组、顶点缓冲区等）和渲染是完全不同的野兽。”
Cruachan：我没有 Java3D，我坚持使用 JOGL。我确实拥有那本书（尽管目前无法访问）虽然我不记得他是如何加载模型的，但我很确定他使用了自动加载的 Java3D 格式加载器。不是我打算使用的东西...对不起！
-佝偻病