我们的愿景 🔮

3D Web 的未来

我们相信未来几年 3D 在网络上的使用将大幅扩展。虽然如今原生应用是常态，但越来越多的内容正作为 Web 应用或 PWA 提供。新的 VR 和 AR 设备将扩展到网络，产生一个有趣的问题：响应式突然不再仅仅意味着“小屏幕”或“大屏幕”，你还需要处理空间、3D、空间布局以及潜在的眼镜和控制器！

再加上向更高交互性和协作性的推动，你就拥有了一个有趣的挑战组合。

在 Needle，我们相信在这个空间中构思和创建应该很容易。我们决心加快进程——创建我们自己的运行时来达成这些目标。这就是为什么我们将部署到 AR 和 VR 的能力直接内置到我们的核心组件中，并持续测试新想法是否跨平台工作。

为什么还要为网络上的 3D 平台？不是已经有很多选择了吗？

选择确实很多，这是事实！我们发现当前的系统¹大致可以分为两类：一些拥有出色的资源处理、工具和艺术家友好的工作流程，但输出某种二进制块；另一些则更侧重代码、对开发者友好，并允许很好地集成到现代 Web 工作流程中²。

我们希望连接这两个世界，并结合两者的优点：艺术家友好的工作流程和现代 Web 技术。结合现代格式和流畅的工作流程，我们相信这将使更多创作者能够将其内容带到网络上。我们还看到了从一开始就正确处理 AR、VR 和协作的机会。

¹: 例子包括 Unity、PlayCanvas、three.js、react-three-fiber、Babylon、A-Frame、Godot 等等。²: 这比引言段落中能容纳的内容要微妙得多！所有引擎和框架都有其优点和缺点，并且在不断发展。

创建工作流程，而非编辑器

我们认为下一波网络 3D 应用将伴随着更好的_工作流程_：每个人都应该能够组装一个 3D 场景、一个艺术画廊、在网络上展示产品或 3D 扫描，或者制作简单的游戏。实现这一目标需要的不仅仅是支持某个特定系统并从中导出到网络。

我们的目标是让人们能够从_他们自己_的创意工具中将数据带到网络上：无论是 Unity、Blender、Photoshop 还是其他什么。我们知道这是一个宏大目标——但我们不想一次性完成所有事情，而是希望一起迭代并逐步接近它。

开放标准而非专有容器

Needle Engine 的核心是 glTF 格式及其使用自定义扩展进行扩展的能力。目标是：一个 .glb 文件可以包含你整个应用的数据。

值得注意的是，将实际代码打包在 glTF 中并非目标；交付和运行代码是现代 Web 运行时和打包的工作。我们当然可以想象，逻辑的抽象表示（例如图、状态机等）可以在一定程度上标准化，并允许互操作的世界，但我们尚未达到这一步。

阅读更多关于我们使用 glTF 和扩展的内容

目标与非目标

目标

迭代应该快速，部署应该迅速。
处理 3D Web 项目应该像处理 2D Web 项目一样容易。
开发者和艺术家应该能够直接协作。
响应式 Web 扩展到屏幕之外——AR 和 VR 应该是内置的，而不是事后补丁。
我们希望回馈开源项目。
开放讨论 3D 和 Web 标准。
能够在开放格式中导入和导出你的数据。
能够选择使用的 Web 框架，而不是锁定到特定的框架和供应商。
常见用例可以在没有或只有有限编码经验的情况下工作。

非目标

目标不是 100% 覆盖所有编辑器版本、功能集、渲染管线的组合。
目标不是提供一个完整的无代码环境。
目标不是匹配其他引擎的功能集、能力或运行时性能。

与其他引擎和框架的关系

在与 Unity 合作多年后，我们发现尽管引擎和编辑器发展迅速，但 WebGL 输出却有所落后。将 Unity 播放器集成到基于 Web 的系统中相当困难，“与”周围网站的通信需要许多变通方法，最重要的是，由于 Unity 通过 IL2CPP 将所有代码打包到 WebAssembly 中的方式，迭代时间非常慢。这些技术非常棒，能带来出色的运行时性能和极大的灵活性。但与现代 Web 开发工作流程相比，它们实在太慢且封闭，于是我们决定自己动手。

Needle Engine 和 three.js

Needle Engine 构建于 three.js 之上。所有渲染都通过它进行，glTF 文件通过 three 的扩展接口加载，我们的组件系统围绕 three 的 Object3D 和场景图展开。我们致力于将我们的一些更改和改进向上游贡献，在此过程中创建拉取请求并报告问题。

Page automatically translated using AI 页面由 AI 自动翻译