4

从 Codecity 到元宇宙:元宇宙的软件形态会怎样的?

 2 years ago
source link: https://www.phodal.com/blog/codecity-metaverse-thinking-in-metaverse-software/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

从 Codecity 到元宇宙:元宇宙的软件形态会怎样的?

Posted by: Phodal Huang Nov. 15, 2021, 7:15 p.m.

PS:作为一个技术人员,虽然对于元宇宙的未来持观望态度,但是并不妨碍我研究它。

为了向某人证明我买 Oculus Quest 2,是为了用于正道软件开发,而不是用于玩游戏,又或者是玩游戏。我在这周的业余时间,为 Inherd 开发小组之前构建的 Coco 研发效能分析工具,简单开发了一个新的可交互的~~前端界面~~:Codecity。哦,不,Codecity 是一个用于元宇宙的系统重构与分析工具。

在有了这个简单的 demo 之后,我就能向某人证明我的 Oculus Quest 2 的经费没有白花 —— 至少有一篇文章和一个开源软件。

在编写了 MVP 版本的 Codecity 之后,我又双叕一次思考起了软件的交互形态是怎样的?上一次相关的思考,大概是在 6 年前,当时我在玩 Leap Motion、Oculus Rift、Google Glass 等相关的设备。当时的结论是,现在还不是时候。那么,现在是不是合适的时间呢?

想法:从 3D 的 Codecity 说起

尝试一个新的领域,自然要从擅长的地方着手,Codecity 便是这样的一个合适的场景。我最初接触到它的时候,是公司大佬推荐的《Your Code as a Crime Scene》一书。Codecity 是一个用于软件分析的模式,早在 2007 就有 Richard Wettel 编写的 codecity。在这个版本里,他对于 Codecity 的定义是:

CodeCity 是一个用于软件分析的集成环境,其中软件系统被可视化为交互式、可导航的 3D 城市。 类表示为城市中的建筑物,而包表示为建筑物所在的区域。 城市工件的可见属性描述了一组选定的软件度量,如 CodeCrawler 的多度量视图。

我们在 Coco 实现了一个 2D 版本的可视化,由于其采用的是 D3.js 作为渲染引擎,结果是 2D 的,其的交互能力比较有限。为了结合上热闹驱动开发的元宇宙概念,便构筑出了 3D 版本的,结合 WebXR(VR + AR)的 Codecity —— 一个多姿多采用的虚拟代码世界。如下图所示:

PS:由于我的 Oculus 还在路上,所以我暂时不保证在 XR 下的效果。我使用的是 Firefox 上的 WebXR 模拟器模拟的,如果有小伙伴有对应的工具的话,欢迎尝试和 PR。

好在于,据说 WebGL 的性能是接近于 GPU 上的原生应用程序,要不 Codecity 可能并不是那么实用,在线Demo:https://phodal.github.io/codecity/

对于编写 Codecity 来说,从代码层面来说它很简单,任何一个稍有图形经验的前端都能完成这样的功能:

  • D3.js 简化图形与数值计算,通过 Treemap 生成图形。
  • Three.js 构建 3D 世界,并添加可交互原型
  • GitHub Actions,自动化 CI 和 CD。
  • 测试,TBD。

对于有过游戏开发经验的人,诸如于使用过 Unity、Unreal Engine 的人来说,这样的应用更加地简单。唯一的问题是,它们是收费的。顺便一提,我觉得这一类软件的付费模式,在未来应该会发生一些变化,诸如于采用生态共建的方式。

有了这个 MVP(最小可行化产品),我们就进入了元世界的边缘了。

数字孪生:将物体从物理世界复刻虚拟世界

在我们进入元宇宙之前,还需要大概地了摸索一下如何从物理世界到虚拟世界,一个非常有意思的入口点就是数字孪生(digital twins)。多年以前,这一系列相关的概念主要是物联网领域,当时主要的入口点是设备孪生(device twins) —— 我还翻译过一系列的相关文章。在 2017 年时,Azure IoT 就提供了设备孪生的服务,它用于:

  1. 将设备特定的元数据存储在云中。
  2. 从设备应用报告当前的状态信息。
  3. 在设备应用程序和后端应用程序之间同步长时间运行的工作流的状态。
  4. 查询您的设备元数据,配置或状态。

Eclipse 还构建了 Eclipse Ditto 框架,用于构建“数字孪生”的软件模式。

简单来说,为了让周遭的设备进入虚拟世界,我们需要对进行进行“面向虚拟世界”的建模。不论是对于构建物理世界的 3D 模型,还是物体的联网设计,都可以通过现有的成熟的软件构建出来。

基于这种模式,Codecity 勉强算得上是元宇宙里的代码分析工具,将代码的物理属性:行数、变更频率、层次结构等映射到了虚拟世界。唯一,还有待改进的是交互方式,以及将虚拟世界映射回代码的“物理世界”。

虚拟世界:从平面软件到物体建模

从某种意义上来说,我们采用的智能家居设备,便具备了一定的数字孪生的特性。还有所欠缺的是,需要这些家电在现实世界的属性进行建模,以映射到虚拟世界中。

在这之后,我们还需要将房屋也进行建模,才能在虚拟世界中进行对应。它并非是一件容易的事情,因为我们还拥有一系列不带任何电子属性的家居物品,它还依赖于我们实时地对设备进行建模。这种实时性建模,会带一系列的隐私问题 —— 当然,如果家里已经有摄像头的另说。除此之外,它还要应对你们家的猫带来的挑战。

在游戏、电影等行业的角度来考虑这个领域,它已经相当的成熟了。唯一,有待研究的是,如何通过物理设备快速地对物理世界的“物”进行建模。

元宇宙:虚拟化与沉浸式

维基百科上对于元宇宙的解释是:

元宇宙被描述一个未来的未来化和去中心化的线上三维虚拟环境。这个虚拟环境可以通过虚拟实境眼镜、虚拟实境眼镜、手机、个人电脑和电子游戏机进入人造的虚拟世界。

对于去中心化一点来说,我从来不抱任何的信心,哪怕是 0.000001%。举一个非常简单的例子,在虚拟的货币世界里,计算资源决定了一切。这也就意味着,谁强谁是中心。同时,从另外一个方面来说,每个一定体量的公司都会推出自己的元宇宙,所以会有一堆宇宙。而在这些元宇宙的强弱,依旧是计算资源决定了一切。直至,元世界成为了标准,成为了一种基础设施,它便又被中心化了。

上述的内容里,我们已经对于虚拟化有了基础的认知。与虚拟化相比,我相信元宇宙会带来更好的设计体验。特别是作为一个 VR 头晕的早期 VR 体验者,AR 反而给我带来了更好的体验。这大概也是 Oculus 多了两个 hand 可以用来~~玩游戏~~体验现实的原因。鼠标与键盘带来的交互体验,并不是友好。在玩游戏时,反而通过手柄、健身环等能带来更好的体验。所以,与多年前相比,我看到越来越多的“成功案例”,证明了沉浸式协作的可能性。

PS:顺便一提,作为一个早期的 Leap Motion 用户,与各类 VR 设备的手柄相比,我更喜欢它这种无设备束缚的体感控制方式。不过,它对于编程能力的要求更快,也对设备拥有更高的计算能力。

元宇宙的支点:沉浸式协作

作为群居动物的人类,协作是我们生产力的基础。

在过去的两年里,COVID-19 大大加速了企业的数字化进程。我们所处的软件开发行业,出现了越来越多的远程办公工作,还有大量地线上会议、线上协作等。而且,多地多中心协作,也是大型企业所要面临的挑战。尽管,人们可以通过飞机在一天之内到达任何地方,但是这种差旅带来的时间成本是具高的。而今,大量地实践表明,这些差旅都可以转变为线上的形式,唯一不足的是在协作上颇为困难。

所以,从个人的角度来看,如果元宇宙要带来价值,那么“沉浸式协作”可能是一个不错的出发点

回到现实:构建产生创意的技术储备

从上述的内容里,我们大概已经阐述了元宇宙所需要的一系列技术。回到现实,我们作为一个个体,可以考虑准备一点基础的技术作为储备。从个人的试验来看,一些潜在的点可能是:

  • 游戏编程。
  • 数字孪生。包含物联网所需要的相关内容。
  • 交互设计。
  • 协作模式。

所以,从一个开发者的角度来看,我们并不一定要追随这个热潮。只是呢,可以考虑以轻量级的 hackday 的形式,让自己拥有一定的技术储备,诸如于我在:

  • 7 年前,在一次 Hackday 活动上,我参与到团队构建的看房机器人的构建上,
  • 5 年前,在新一次的 Hackday 活动上,我们构建了 3.0 版本的小机器人,添加了 VR 的支持。
  • 3 年前,在一个售前的项目上,构建在线 VR 看车的 demo。

我是一个沉淀导向的开发者,所以代码 + 文章的产出是我所觉得储备的证明,如本文结尾所留下的一系列文章。

而从一个中大组织的角度来看,我们可以尝试性:

  1. 构建一个试验性团队。从 Apple、Amazon、Google 等公司的试验性产品里,。我见到另外一个反面的案例,可能是国内的些实验室,过于依赖与业务结合。
  2. 持续性的结合业务探索。用小的成功作为积淀。
  3. 采用开放性基础设施。
  4. 学习其它领域的成功案例。

当然了,收购一个团队的成本显然会更低。

未来的软件形态是怎样的?

最后,回到标题上来。

如上述,对于交互性的延伸是软件形态的老大难问题。从某种意义上来说,可交互的设备决定了软件的形态,而 AI 也在尝试性地减少相关的交互。这样一来,两者之间的博弈会变得非常有意思。好在,这种改变只是一定范围地,因为人还是要吃饭的。

除了上述的内容,我觉得还会有:

  • 云即全部。
  • 云端渲染。除此,我们在移动设备端有了越来越强大的 GPU,只是它可能不足于应对元宇宙带来的挑战。依赖于更快的网络速度,如 5G,云端可以完成这些渲染,客户端只需要作为展示性的存在
  • 开放基础设施。对于中小型企业,意味着:我们需要采用业内的标准、开源的工具与软件。对于大型企业来说,则是提供一个开放的环境与生态,以及底层基础设施的开源。与历史上的诸多时刻相比,开放的世界里更需要这样的开放标准。
  • 也许,还有 6G。尽管,我还没有用过 5G,但是我相信 6G 将针能对于元宇宙,提供更好的数字传输格式与算法,能高效地、智能地处理各类元数据。5G 所针对的更快地网速等诸多的特质,可以应对于元宇宙初期带来的一系列挑战。但是,从个人的角度来思索,因为网络带来诸多的不确定性,基站可能会成为元宇宙的各种核心节点。

同时,为了构建元宇宙 ,将需要更多的工作岗位,使用更多的电力。所以,与上述的结果相比,我觉得投资到元宇宙的一系列周边,可能更具备行业壁垒,比如程序员培训、绿色能源。

你觉得它会是怎样的?

我高中最喜欢的两个领域,一个是 Linux kernel,一个是游戏编程。如果将这两者相比较,我对于游戏引擎的兴趣,远大于对 Linux kernel。作为一个男孩子,开发一款游戏大概是多数人儿时的梦想。而当线上变成虚拟世界时,是不是游戏已经不那么重要了。

当然了,这篇文章的开头并不是为了嘲讽。

Codecity:https://github.com/phodal/codecity

我编写的其它相关的内容:


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK