坚叔：让科幻片的概念变成产品丨编程挑战赛 x 嘉宾分享

Posted 2022-08-22 声网

前言

本文基于资深创业者@坚叔在「RTE 2022 创新编程挑战赛」宣讲活动中分享内容二次整理。

嘉宾简介：陈坚（坚叔），国内二次元 AR/VR 资深创业者，国内第一批空间虚拟数字化从业人员，获得政府颁布的数字城市专家证书，是首批数字仿真专家之一，也是最早一批提出“跨次元偶像”概念并付诸实践的人。

01 科幻作品中的虚拟世界

如今，大量科幻作品当中其实都有对虚拟世界的描绘，比如《头号玩家》《刀剑神域》等，都展示了这种全沉浸式的虚拟世界，可以说这种虚拟世界是所有虚拟赛道或 RTE 创业者都梦想实现的目标。既然是科幻片，那么肯定不可能当下就能实现，但是不是说我们就什么都不做只是躺平呢？当然不是。

今天我们就来看一下，在这些描绘未来几十年甚至更长时间的客观作品中，大家所向往期待的虚拟世界在已有的技术是如何实现的。

我们选择以《头号玩家》为原型进行介绍，因为《刀剑神域》描绘的脑插管太遥远了，而《头号玩家》描绘的场景有一个非常具体的时间节点—— 2045 年，他们的产品生产于 2030 年，相对来说离我们比较近，并且是有机会通过现有技术来实现。

我们对《头号玩家》当中的一些科技或技术要素进行剖析，其中包含短轴 VR 眼镜，如果大家对 VR 行业比较留意或关注的话，会知道很多的 VR 厂商，比如刚入局的网鱼发布的Pancake方案（超短焦光学方案），就是类似这种短轴 VR 眼镜。最早涉足万向跑步机的是 KAT VR，今年入局的有 step VR。这样，实际上就已经涵盖了两大硬件，其余还包括全姿态姿态捕捉、体感模拟等，图 1 梳理了相关的技术要素。

■图 1

我们会发现，当中有一些技术已经可以实现了，只不过成本很高，体验还没达到电影中描绘的程度，导致没有办法落地。

02 我们是如何做的

1、对科幻概念进行筛选的标准

为了将这些科幻概念变成想法，我们对其进行了筛选，标准如图 2 所示。

■图 2

图中提到的三点其实都是非常关键的，因为首先，如果技术不能初步实现，那么这个产品就不成立；其次，比如描绘几十万人同在一个场景，以现在的技术肯定是不能实现的，那么是否能够降为几千人，甚至几百人，这种特定的应用场景下是成立的；最后，图中展示了 VR 眼镜，目前高规格的短轴 VR 眼镜其实还很贵，不管是 Meta 的 Oculus Quest 2 还是国内的 Pico 3，都要达到一定的消费级别。

2、我们最终选择的方向

（1）（一定精度）的用户虚拟化身

根据以上筛选标准，我们确定了最终的选择方向，首先就是在一定精度下的用户虚拟化身。《头号玩家》中的虚拟化身精度是非常高的，目前如果我们采用虚幻 5，以及 3090 甚至是 4090 的显卡单独跑一个角色，其实可以达到《头号玩家》中的效果，但是把一定数量的虚拟化身放在一个场景中并且实时运算，那基本上是不可能的事情。因此，我们就选择了一个合理的终端，比如一台普通显卡的电脑，可能是 750 甚至是手机都能跑得动的虚拟化身来代表用户，如图 3 所示。

■图 3

左边是两个二次元人物，我们测试过，大概两年前的一台 2000 块钱左右的国产安卓手机，能跑那个 200 个左右这样的角色，帧率能保持在 30 ～ 40 帧之间。如果是右边的这种小电视人，则可以跑到几百人。

（2）（一定数量）的多人实时交互

多人的实时交互会更加复杂，除了刚才提到的渲染云引擎的瓶颈和限制，还包括了大量的数据交互限制，包括用户的状态、语音、动作、表情等，其实这也是有承载上限的。所以说，要控制在一定的数量范围内，但在同屏或同场景的百人规模下上线的运营场景，基本上可以进行切入，如图 4 所示。

■图 4

（3）（一定范围）的用户创造和交易

《头号玩家》中是用户自己创造和交易，目前我们也会开发编辑器使用户可以自己搭建场景或者做活动的交互事件，但它相当于是一个类似游戏的地图编辑器，其中的资源素材包括商城渠道，以及现在主流 3D 格式的转化，因此可以实现一定范围的用户创造和交易，如图 5 所示。

■图 5

3、我们选择的应用场景

以上三点更多的是在技术层面进行考量，这样我们能组合出一个怎样的应用场景呢？现在市场上很多的虚拟应用，可以用于会务、在线办公、购物场景、演唱会、展会等，我们对这些场景进行调研和逐一分析，会发现其实就是前面提到的 3 个维度。其中精度方面涉及的就是用户 Avater，如果需要每一个用户的 Avater 精度都非常高，可以允许用户自己导入一个精度比较高的模型做实时运算，同屏人数，基本上是有一个舞台，有表演者或主持人的概念，那么观众相对来说就可以弱化，他们选择的模型精度更低，这种情况对多人实时交互的数量要求更高。

结合公司/团队自身的优势，我们选择了娱乐、年轻、社交、二次元等应用场景。针对演唱会这类娱乐场景，我们可以确保一定的数量、精度和实时交互，因为我们是从虚拟偶像业务开始切入虚拟世界的。另外，我们更多的是从电竞、音乐、ACG 等多种年轻化场景进行切入，转成线上虚拟化。我们还配置了大量虚拟空间，支持各类社交活动，最终虚拟场景实际运行的产品化场景基本上同屏是 100 人左右，在这样的应用场景下，其实用户的 Avater 形象的精度基本上是满足最基本的期望值，可以把足够的资源分配给场景、道具、甚至是舞台上。此外，我们在二次元领域已落地大量项目。能力和行业资源的积累是促使我们做出选择的非常重要的依据。

基于此，我们的关注点更加聚焦，选择以虚拟偶像演出和虚拟漫展作为更精准的切口，因为除了在技术层面、应用层面可行之外，它们还有一个非常重要的特性，就是市场空间足够大，而且能形成一定的高频效应，产品越高频，越能广泛地被用户所接受。所以即便产品有更大的应用场景或能覆盖更多的人群，也可以先关注一到两个突破口，从而使公司的发展更加稳健。

4、技术选型

（1）跨终端的渲染管线

确定突破口之后，我们还需要做更多的工作，比如技术选型。虚拟世界中肯定会涉及三维引擎，另外，由于我们的目标是要进行跨终端，所以还涉及 PC 、平板、手机甚至 VR 等，进行跨终端的渲染管线。我们的技术人员在很多的这个工作来解决跨终端的算法项目问题，最终我们选择了 unity 引擎的 urp 管线，原因是现在 unity 的开发门槛相对来说比较友好，很多 3D UGC 生态和 unity 的兼容性也比较好。综合考虑 unity 的开发门槛，结合我们产品的定位、UGC 的友好度以及它的性能优化，我们最终做了这样的选择。

（2）资产精度管理

除了渲染管线，资产精度也需要进行管理。因为刚才提到，其实很多时候我们考虑的不是一场虚拟活动或者一个虚拟场景能支持多少人，而是更加关注同屏显示多少人。目前因为渲染性能包括引擎的渲染性能和设备的算力，所以它对在线人数的限制是远远大于由 RTC 造成的限制的。以声网为例，它的一个音频通道基本上可以保证几万人在一个频道中。另外，默认是同时开 16 个麦，并且已经在测试一个频道同时开 128 个麦，所以目前其实 RTC 的在线承载力问题不大，所以我们更多是从渲染层面考虑承载力。这就涉及设备的算力，如果运行的环境在 PC ，特别是如果是云端提供的渲染节点，那么算力是完全可以满足的，但是不可能无限支持超高精度的大量同时人员在线。我以图 6 所示的四个模型为例。

■图 6

会发现这四个模型同屏的人数其实差异很大，这四个资产中有一个是卡通写实，他的样子是卡通的，但是质感是写实的。有一个纸片人是我们通过三渲二 技术让它看起来特别像 3D 模型。还有精细度更高的一个数字人，以及一个二次元风格但是精度更高的融合风格。

其实这四个资产的风格中，左边两个是能在手机中运行的，右边两个则不能。因为第一个人物的毛发是我们自己写的 shader，当然如果是多个角色也无法承载。第二个人物则主要因为它是一种 三渲二 的风格，在同屏多人的情况下可以运行，但是数量也会有限制。这里面可能看不清楚，我们其实对人物加了一个轮廓线，如果要把轮廓线的抗锯齿拉得很高，其实也很耗费性能。至于右边两个人物基本上在手机中不可能达到这样的效果，都要进行大面积的处理。所以除了定好算法，我们也会根据应用场景进行资产的精度管理。比如对于演出场景，我们会把资源更多地集中在表演者身上，提高表演者的资产精度，而观众的资产精度进行控制。而对于一些偏社交的场景，比如用户聊天室，其中可能最多有十几个人，在这种情况下，我们就会把算力和资源平均分配给每一个用户的 Avater，使其资产效果更好，精度更高，这样用户的体验就更好。

（3）实时交互数据

第三个就是最复杂的实时交互数据，以虚拟活动应用为例，实际上它至少包含了图 7 所示的数据。

■图 7

我们会把这种实时交互的数据维度进行分析，最后把它拆成是四种数据，如图 8 所示。

■图 8

一种是音频，比如用户间的语音互动，我们采用了声网的 RTC 方案。另外，在虚拟世界中其实也存在虚拟的屏幕，比如发布会或演唱会的投屏，其中的视频不会放在客户端，因为这样无法实现实时操作和数据同步。所以要用到视频流的实时分发推送，对此我们也同样用了声网的 RTV 方案，但这个 RTV 是我起的，它属于 RTC 的视频范畴。第三个就是信息，其中包含用户的状态，在实际场景中不可能每个用户都穿戴捕捉设备，绝大部分用户在场景中其实还是显示用户状态，比如向前走、向左转、鼓掌、发文字信息等，统称为用户状态。对此，我们采用了声网的 RTM 方案，它以信息队列的方式进行传输，而且可以跟声网的 RTC 等进行同步。最后是我们自己的原创技术，叫作结构数据。对于结构数据我们目前将重点放在虚拟人物的动作和表情上，主要用于表演者，假如要执行一场演出场景，以图 9 右上角的舞台为例。

■图 9

这里用户在一个虚拟的三维空间中，他可以操作自己的Avater在舞台上自由行走，并控制实时观看的角度，这个画面是在用户侧生成的，因此不能全是视频，必须要传输台上偶像的动作和表情，这样才能在用户端接收到，以进行实时渲染。结构数据是把虚拟人物或者用户的 Avater 所呈现的动作表情，映射到虚拟世界中的 Avater，同时结合 异地 和多人的同时同步，才能实现像舞台效果。

所以如果说我们要尝试复刻虚拟世界中的活动或行为，交互的数据维度是非常多元化的。所以虽然很多人可能对元宇宙的定义五花八门，但是我觉得不管怎样，元宇宙一定是高维度的数据交互，以及高仿真的虚拟世界，这个前提我认为是必须要存在的。

03 一些建议

接下来给大家分享一些小小的建议。

首先，产品是妥协的艺术，因为我们要做一款产品会遇到很多困难，特别是实时互动的虚拟产品，其在技术层面有很多局限性，需要在技术层面、成本层面和体验层面达到最佳的平衡，所以妥协的艺术也可以说是一种平衡的艺术，我们要考虑什么地方是可以妥协的以及妥协到什么程度，这其实是产品经理要着重思考的地方。

然后是多通过产品手段来打破技术限制。比如用户要在终端运行虚拟舞台演出的场景，我们一般会同屏显示 100 个角色，但也要考虑到视觉密度、能耗发热、用户体验等。我们在一个场景内即便用了简化模型，也会只显示 100 个观众。但如果是做一场演唱会，要求几千名观众同时在线该怎么办呢？这就需要用到产品手段，用户是分线路显示自己的实时虚拟形象，考虑到是演出场景，所以我们设计不同线路的观众彼此之间看不到对方，但都能看到舞台上的内容，舞台内容包括表演者和被邀请上台的观众。这里线路显示受算力和其他客观因素的影响，但是不同线路的观众之间可以正常互动，包括文字交互、弹幕交互，这些都是可以跨线路运行的。我们将线路以及声网的频道概念进行了组合。其实无论在任何一个时代技术都有存在一定的局限性，我们可以通过产品手段打破这种技术限制，使产品可以更好地满足用户体验，并能创造出更多的应用场景。

最后是和底层的技术伙伴多沟通，多上开发者社区。声网现在官网上的版本只能支持一个频道有 16 个人开麦，但实际上内测的版本是可以支持 128 人是开麦的，这种内测的资格其实是跟技术合作伙伴 py 过来的。我们跟很多的技术合作伙伴关系都非常好，不管是在 RTC 领域、引擎领域，还是捕捉方案领域，因此很多时候都能得到一些内测版本或者定向邀请测试版本，在这种情况下，就能得知技术伙伴未来的规划或者即将实现的指标，这些可以提前用在产品开发上，也让自己的产品在正式上线的时候具备先发优势。

04 问答环节

1、实时交互应用的前景如何？

实时交互的前景肯定是巨大的，因为以前别说视频，就连看一张图片都非常奢侈，基本上都是依靠文字交互，而且也是通过离线方式，现在听起来可能是天方夜谭，所以信息交互一定是向越来越的高维度发展的。纵观整个互联网信息交互的演变过程，你会发现两个规律，第一个就是往越来越高维度的信息方去走一维二维，再到现在三维，第二个就是交互的效率越来越高。我以大家最习以为常的直播为例，现在的直播其实并不是真正意义的实时互动，因为加上 cdm 的延时，其实很多时候交互延时普遍在 3 秒以上，在网络不太好的情况下，直播的弹幕跟直播者的延时甚至超过 10 秒。对于这种情况，大家肯定希望延时能够进一步缩短，最终在直播的环境下实现类似视频通话的即时性，同时画质跟现在的直播没有区别。我相信这个很快就可以实现，因为包括声网在内业界已经在测试更低延时的直播方案。我认为实时互动的赛道很宽，甚至实时互动这个词太接地气了，不然在我眼里其实实时互动比元宇宙更能描绘下一代互联网的特性。

2、元宇宙和 AR、VR 等的区别是什么？

在网上有个梗——元宇宙是个筐，什么都可以往里面装。所以如果把元宇宙看成是下一代互联网，或者 3D 互联网、 3D 虚拟世界，其实 AR、VR 是我理解中的元宇宙在视觉层面技术的非常关键的组成，甚至它们会成为元宇宙的主力载体。现在我们运行的 3D 环境主要还是通过 2D 屏幕呈现给观众的，它并不是真正意义上的 3D 虚拟世界，因为其中是没有纵深感的。比如我在 VR 中能非常准确地判断跟对方的距离和防卫，甚至能捕捉到手来碰触对方的耳朵，这是在 2D 互联网中呈现 3D 虚拟事件，只是一个过渡阶段。我的理解是，AR、VR会是元宇宙时代真正到来，或者即将到来时主流载体，也就是说，在进入元宇宙时代的时候，AR、VR 的普及是必经的节点，而在 AR、VR 普及之前，其涉及的内容和交互反思是要按 3D 环境设计的，这又是必须要走的一步。

3、元宇宙场景主要用到的哪些技术呢？

元宇宙涉及的技术太多了，首先要关注引擎，包括主流的 UE 和 unity，还有国内的新兴虚拟引擎、 Cocos3D 、WebGL 2.0，与三维相关的引擎和开发环境大家是一定要了解的。虽然现在也有像 Gather.town 这种 2D 的元宇宙，但是我个人认为这只是一种过渡状态，因为现在 3D 门槛比较高，对算力要求也比较大。这种 2D 的元宇宙更像是一个图形化的聊天室，我认为它会有瓶颈，所以现在入局的创业者我更加支持直接从 3D 切入，因为 3D 的开发环境越来越成熟，配套的生态也越来越完善。

第二个要掌握的技术就是 RTC，因为对所有虚拟世界中的元宇宙来说交互是必然的，所以 RTC 是少不了的。我在 12 年前做过一款类似 Gather.town 的产品，但是采用 fresh 实现，形态和现在的 Gather.town 可以说是一模一样，但这些我都基本上在 12 年前就做了，但是没有成功，这真的和网速、机器性能都没关系，我自己分析认为就是因为没有 RTC 技术，因为那时候我做的那个 Gather.town 的交流方式还是以文字交流为主，并没有提升互动的效率和互动的体验，甚至这种以文字交流为主的方式跟图形可视化的环境其实是脱节的。所以我认为除了这种 3D 引擎技术，第二个推动元宇宙发展的就是以 RTC 为代表的 rt 实时互动技术，它代表了信息交互的维度和密度。

4、声网哪些技术可以支撑虚拟活动？

这里主要是我前面提到的四个数据的维度，分别是音频 RTC 、视频、信息和结构数据。关于结构数据，声网现在虽然还没有推出专门的产品，但实际上声网一直也在探讨更高维度的结构数据的传输。所以我都觉得其实现在声网的这些能力对于虚拟活动来说帮助很大，当然声网也会推出一些周边能力，推荐大家关注和留意。比如声网的 AI 声纹技术，它可以在聊天室中实现实时的变声效果，但这个实时是相对的，还是有几百毫秒的延时，但是在网络聊天中基本上与实时没有差别了。

另外，声网基于现在的 RTC 和 R rtm 技术，也已经发布了很多 meta 系列的解决方案，比如原直播、原语流、原 K 歌、互动游戏等，这些都可以在声网官网的解决方案中都可以看到，包括其中更加详细的技术。

5、个人实现虚拟活动时需要注意什么吗？

个人开发者开发实时虚拟活动会有点压力和难度，当然也不是不可能，如果为个人的发展想挑战一下，我会给以下几个建议：第一个是不要做太复杂的数据交互，先实现最基本的声音和用户状态；第二个是尽量用现成的美术素材，以独立游戏开发者为例，其实最头痛的是美术素材，所以要多用一些现成的美术素材，但这里不鼓励大家用盗版，但是如果不是商用，也可以考虑上网搜一些可用的美术素材；第三个才是考虑产品究竟是自己做得完的，还是要挑战技术难度，又或者只是毕业设计，如果是想开发虚拟活动作为商用，那么应用场景一定要选得非常准，因为现在虚拟活动入场团队的人数甚至过百人，个人挑这么一个大团队，就一定要选择准确的应用场景，不要怕这个场景小，最好选择小到其他团队不愿意去干的场景。

关于「RTE 2022 创新编程挑战赛」

RTE（Real Time Engagement）创新编程挑战赛，是声网自 2019 年开始，一年一度面向全球 RTC（Real Time Communication） 开发者、编程爱好者与极客举办的在线黑客马拉松。

本届大赛，我们共分为 2 个赛道，赛道一将继续延用经典赛题「声网 SDK 应用开发」。与此同时，今年我们还特别推出赛道二的新赛题「场景化白板插件应用开发」，给开发者提出更为聚焦的解题方向，探索场景应用与技术能力的边界。