Voices of VR 播客

介绍

大家好，我叫 Kent Pye，欢迎来到 Voices of VR 播客。

在网络上有很多不同的网页框架可以使用，它们最终会编译到 WebGL 和沉浸式网页上。其中 3.js 是一个非常流行的库，很多人使用它。3.js 被像 A-Frame 这样的声明性语言使用，这种语言允许你编写这类标记，最后将其编译到 WebGL。

另一个框架是由 Facebook 提供的 React 360，还有一个由微软开发的框架，叫做 Babylon.js。在 2019 年 5 月 5 日，Babylon.js 4.0 发布。去年在 2018 年的微软 Build 会议上，我有机会深入了解到 Babylon.js 的背景和历史，能够与 Babylon.js 的两个联合创始人交谈，并了解它与 GLTF 的不同集成方式，以及微软整体是如何支持 GLTF 的，这实际上是一种开放标准格式，用于 3D 对象。

他们还支持 Babylon.js，让它成为一个更具企业级框架，能够实现不同版本控制、发布和非破坏性更改，并使用 TypeScript 编写这种更高阶语言，然后编译为 JavaScript。这是一种不同的方式，Babylon.js 是由微软维护并在内部使用的。随着 2019 年微软 Build 的到来，Babylon.js 4.0 又进行了全新发布。虽然这次访谈是在一年前的 2018 年进行的，但我想当我再次参加微软 Build 时，希望能与他们再聚一聚，了解 Babylon.js 的最新动态。

今天的节目内容

今天的节目中，我们将讨论的是在 2018 年 5 月 8 日，Kent 采访了在西雅图举行的微软 Build 大会上与 Saurabh、David 和 David 的访谈。

访谈开始

酷！你好，我是 Saurabh Pachir，我是 GLTF 和 Babylon.js 的项目经理。我与社区合作，推广 GLTF 规范，帮助在 Babylon.js 中实施，并确保微软的所有产品都在采用它。

你好，我叫 David，我在微软工作，通常做产品经理，与网络技术以及 VR 和 Unity 相关的工作。但我与另一个 David 和另一位法国同事共同创建了 Babylon.js。

我是 David Katia，来自法国，我负责推动微软的 Babylon.js 项目。我们在 2013 年创建了它。今天，我们是引以为傲的开发者，能够继续在过去的项目上工作。

关于 GLTF 和 Babylon.js 的讨论

那么，GLTF 是何方神圣？它是一个用于 3D 建模的数据格式，是一种开放的规范。在网页开发方面，很多做 WebVR 的人都在使用像 3.js 这样的库，或者在其之上有一个框架，比如 A-Frame，它能拥有一个声明性语言，然后将其传递给 3.js，最后渲染到 WebGL。

Babylon.js 可以看作是这样一层，能够做 3.js 做的事情，即处理 JavaScript，转换为空间的 3D 对象。可以谈谈你们为什么会启动这个项目，以及它与其他框架（如 3.js）相比有什么独特之处吗？

Babylon.js 的独特之处

我们启动这个项目的主要原因是，我们想要一个企业级的框架，意味着没有破坏性更改，用户能够无畏地升级到下一个版本。其次，我们最初使用 JavaScript，但我们希望使用 TypeScript。而且因为使用 TypeScript，如今我们可以轻松使用所有的 ES6 特性，只需改变一个标志。

公正地讲，由于我们处于开放源代码领域，当有拉取请求时，使用 TypeScript 让我们更容易进行检查，因为它具有强类型系统。

你说得对，所有东西都通过 Babylon.js 进行，但我们没有一个基于 WebVR 的上层框架，我们也希望 Babylon.js 成为一站式解决方案。要在网页上进行 3D 开发，我们提供物理引擎、碰撞检测、WebVR 以及未来的 Webexa 都在同一个框架下可用。也就是说，如果你想加载 GLTF，就可以，根本不需要经过其他报告，我们维护一切，这样可以保持所有事物的一致性。

使用 TypeScript 的说明

我理解 TypeScript 是一种声明性语言，通过它你能做一些类似 A-Frame 这样的事情，定义事物，这样的想法是准确的吗？

TypeScript 确实是在 JavaScript 上添加类型的语言。这对于来自 C# 的人来说是非常有用的，因为他们已经习惯了 JavaScript 的语法，它还将提升 JavaScript 的生产力和质量。很多公司在企业环境中喜欢这样，我们作为 Babylon.js 开发者也享受到这一点。说实话，我们能够通过 TypeScript 找到一些复杂错误，这在其他框架中更难查找。

与 A-Frame 的声明性方法相比，今天我们没有一个完整的方法。我们有一个可以使用声明式方法的查看器，比如 HTML 元素，可以加载查看器并设置参数来配置它。但大部分东西还是要通过编写代码来完成，使用 TypeScript 或 JavaScript，这取决于开发者的需要。从某种程度上说，它是 JavaScript 的超集，你可以将其视作加了类型的 JavaScript，不容易出错，更易于维护以及与社区协作，因为有了类型，大家对交付的代码更加放心。

关于 GLTF 的适配与 Babylon.js 生态系统

你能结合一下 GLTF 是如何融入 Babylon.js 生态系统的？你提到你在两者之间有工作，这有关系吗？

对我来说，GLTF 加载器现在是 Babylon.js 的一部分。我也在与 GLTF 规范合作。在我们撰写规范时，关键在于验证它是否能够正常工作。同时与 3.js 的社区合作，确定我们描述的内容是否在不同的引擎中都能正常工作。与社区分享 Babylon.js 和 3.js 并确保它在所有引擎中工作的过程对验证 GLTF 规范至关重要。

WebVR 与 WebXR 的集成

你提到不需要做任何事情来实现 WebVR 或 A-Frame。我听 Diego Marcos 说过，WebVR 1.1 但总有一天会更新到 2.0。用户只需将 A-Frame 更新到最新版本，所有 WebVR 规范的复杂性将会自动维护。对于 WebVR 的集成，用户需要做些什么？

没什么要补充的，正是我们所提供的。目前，我们的代码中只需一行， literally 是 scene.CreateDefaultVRExperience，这将为你处理所有事情，包括初始化 WebVR 1.1，确保我们为你找到控制器。所有这一切都由 Babylon.js 在后台完成。当 WebVR 1.2 可用时，它将完全透明。用户只需切换到最新版本的 Babylon.js，就能够无缝使用新版本。

结论与未来展望

总的来说，我认为 specification 有时也会在网络上移动，有时也会打破某些东西。这也是框架的重要性所在。正如你所说，使用 A-Frame、3.js 或 Babylon.js 的用户将不得不导航这些复杂性。对于 Unity 库来说，它们有时更新更快并且可能会打破重要的功能，导致开发者必须修改代码。我认识一些人正是因为这一原因不得不在不同的 Unity 版本间调整代码。

我们知道使用较小的变化相较于其他框架更有优势，他们来的时候更多地是因为我们支持较少的破坏性变化。但这并不仅仅是由于 W3C 规范，更重要的是我们在 Microsoft 内的需要。我们与大型团队合作，比如 PowerPoint 与 Remi 3D 等等。在公司内部，我们不能允许破坏某些东西，因为这样会导致麻烦；与外部客户（例如 Adobe）也是如此，他们不希望我们破坏所有东西。

目前来说，我认为 WebXR 是未来的关键。Microsoft Edge 浏览器支持 Windows Mixed Reality 头显，虽然 HoloLens 还不能使用 AR 能力，但我们希望未来的 WebXR 能够实现 VR 与 AR 的共同能力。这是为什么 WebXR 的设计是要达到这个目标。

结束语

感谢您聆听 Voices of VR 播客。如果您喜欢这个播客，请传播给您的朋友，并考虑成为 Patreon 的会员，这是一个虚拟支持的播客，我依靠您的捐赠来继续为您提供这些报道。请今天就成为会员并捐款。