元宇宙时代，国产物理引擎的新机会在哪里？ | Founder 100

目标是用一个引擎驱动

虚拟世界所有的运动

Founder Park：物理引擎和动作引擎有什么区别？

崔汉青：物理引擎是利用物理规则去模拟运动的引擎。英伟达的 PhysX、Havok、还有开源的 Bullet 是市场上比较成熟、主流的物理引擎。游戏中有不少地方会运用到物理效果。比如：游戏中角色的头发可能会随着运动而飘动，衣服也跟着人运动；在足球类游戏中，人和足球的碰撞，其实就是一个物理的过程；还有像《人类一败涂地》这样利用物理模拟做出的非常有意思的玩法的游戏。

动作引擎是利用动作数据去驱动运动的引擎。典型的游戏引擎里会集成一个叫「角色动画」的系统。比如 Unity 里面有用来做角色动画的 Animator；UE 里面有 AnimGraph。单独的动作引擎现在在市面上还是比较少见，比如 NaturalMotion 公司旗下的产品。现在 R 星 (Rockstar) 的 GTA5 里面很多角色的动作非常真实，就是用了他们的技术。

Founder Park：动作物理引擎的核心是什么？

崔汉青：我们是把虚拟世界里的运动分为两种模式。

一种是数据驱动的运动。游戏中的 NPC 为什么可以跳舞？在游戏里面通常的做法是，请舞蹈演员穿上动作捕捉的服装，把数据记录下来，成为角色背后的数据源。也有可能是手工制作，动作/动画师用专业的工具去扣帧，得到动作序列。也可能是通过相机拍摄一段视频，通过 AI 的方式去把里面的人物动作提取出来。但不管是什么样的方式，它最后其实都是形成了一系列数据，最后游戏引擎再用数据去驱动 NPC 运动。关于由 AI 生成的运动，我的理解是，AI 本质上还是基于数据的。不管是监督式学习还是非监督式学习，背后的 AI 都是采用数据编码到模型里面的，最后由模型来驱动。其本质上是一种泛化，我们把这样的运动也定义成「数据驱动的运动」。

另一种就是规则驱动的运动。用更基础的东西，比如物理定律去模拟各种物体的运动。用打台球举个例子，只要我们一开始确定了台球出杆的力度和击球点之后，那么之后所有的运动的都是由初始状态决定的，这个过程并不需要任何数据。

我们认为「数据驱动的运动」和「规则驱动的运动」这两种模式，可以囊括虚拟世界里面的一切运动。以上就是我们对虚拟世界里面运动的认知。

而动作物理引擎，就是我们希望用一个引擎去驱动虚拟世界里面的所有运动。我们公司的名字 Motphys 也是一个合成词，把 Motion 和 Physics 这两个词拼在一起，同时代表了动作和物理。

Founder Park：在你看来，未来是数据驱动的运动会越来越多，还是规则驱动的运动越来越多？

崔汉青：我们其实觉得这两部分运动是缺一不可的。

比如现在非常火的 AIGC，AI 其实是在代替人类去产生越来越多的数据的，常见的像是 AI 作图，或者 ChatGPT 这样的 AI 生成的各种文本。运动的数据也会越来越多由 AI 去产生，这其实意味着数据驱动的运动增量也会越来越大，而且在不久的将来应该会出现一个爆发性的增长。

另一方面，随着人们对虚拟世界真实性的要求越来越高，对于像物理引擎这样的规则驱动运动的需求，也会不断增长。比如游戏里模拟角色的头发/衣物，原先可能直接是用离线的方式去把数据算出来，「烘焙」到动画里。现在则是越来越多地采用实时计算的方式去模拟角色的头发和衣物。未来随着算力的增长，模拟的精细度也会越来越高。

到了最后的终极阶段，在虚拟世界里，一切能被模拟的物理现象，可能都会被模拟出来，并且越来越精细，最后达到算力和需求的平衡。综合下来看，我们是认为这两方面的运动模式，在未来都会有增量，并不会存在此消彼长。

Founder Park：为什么动作和物理引擎在过去的发展是分开的？

崔汉青：从引擎和游戏的发展历史来讨论一下。物理引擎存在的时间更长一些，现在的游戏一般会集成一些物理引擎在内部，满足物理模拟的需求。至于动作引擎的部分，游戏里通常会内置一套满足简单游戏开发需求的、数据驱动的动画系统。但是，游戏在不停向前发展，游戏的品质是越来越高的，人们对虚拟世界中运动模拟的真实性的期待也会有更高的要求。

举例来说，FIFA 游戏中一名球员在球场上跑，如果 TA 被附近的人撞了一下，目前对这个场景的处理办法，还是使用预先捕捉好的动作来进行数据驱动。在被撞的过程中，规则驱动的物理引擎就变得非常重要，因为球员被撞的反馈不可能是提前录制好的。TA 可能是从各个方向被撞，被不同的力度撞。如果球员的反应是提前录制好的，它的数据量会是非常庞大的——这显然不太现实。所以会采用实时物理模拟的方式，去模拟球员被撞的反应。

从这个例子我们可以看到，这样高精度角色在赛场上运动的场景，动作和物理引擎确实是缺一不可的。

但是，到目前为止，这样的技术并没有放在典型的通用游戏引擎里，而是在顶级 3A 大厂以及自营工作室里（像 EA 或者育碧的自营工作室）没有开放出来。我们的团队之前积累了相对较的体育类游戏经验，我们看到了当下业界对更真实的模拟的需求，并且预判这样的需求在未来会越来越多。所以就选择去顺应这样的需求，把这两种能力融合在一起，实现出来，再把这样的能力开放出来，帮助更多的厂商去做更真实的运营。

Founder Park：国产的动作物理技术发展的现状是怎样的？

崔汉青：从动作技术和物理技术两方面分开来讲。

动作技术方面，我们习惯性地会把它分为三代。绝大部分国内厂商还是在用游戏引擎自带的功能去做角色动画，播放原始的动画数据。我们把它定义为第一代动作技术。在国内一些顶级游戏工作室里，他们开始在 Motion Matching 这样的第二代动作技术上做尝试，不过还没有见到商业化落地的成果。

《黑神话：悟空》可能是一个尝试 Motion Matching 技术的例子。我们也很期待看到他们的落地成果是怎样的。相比较于国外的情况，国内落后的其实算是比较多。国外很多研发能力比较强的大厂，已经有不少第二代动作技术落地的案例，典型的是以育碧和 EA 这些大厂为代表。

把视野放长，第三代的动作技术，我们认为是 AI 加持的动作技术（AI 生成动作）。目前来看，这样的技术在全球范围内也是在一个非常早期的阶段。国内的发展也是非常不充分。但这也正是我们创业的机会。在第二代到第三代的动作技术方面，随着需求的增多，国内的技术是有弯道超车的机会的。

再说物理技术方面。这两年国内是有一些厂商在他们的产品中涉及到了物理方面技术。比如：专业在服装做布料/面料模拟的凌迪科技；做影视动画工具链的泽森科工，主要是离线模拟和渲染的工作；还有在 Python 上做图形学编程语言的 Taichi，也可以用来去做一些物理模拟的工作。他们都是跟物理技术有一定关系的。

相比较于国外成熟的商业引擎，国内物理相关的技术还处于萌芽阶段。但是由于上述国内厂商的存在，我们还是觉得国内的技术已经处于一个很好的发展势头之上。

Founder Park：物理动作引擎过去这些年的商业化是怎么样的？为什么一直没有成熟独立的物理引擎公司出现？

崔汉青：之前的物理引擎的形态，像 PhysX、Havok，还有 Bullet，都是以 SDK 的方式提供给开发者的——嵌入在游戏或第三方的游戏引擎里面。比如 Unity 和 Unreal 里面都嵌入了英伟达的  PhysX。如果是独立的公司将这种形态的产品卖给开发者，就得一笔一笔卖授权，在商业上的可持续性是没有那么高的。

被收购的古早物理引擎公司，主要是两方面：一方面它们做的东西确实很重要，战略价值很高；另一方面，商业上的模式有限制，没有办法作为独立的引擎公司养活自己。Unreal 和 Unity 靠卖引擎授权的商业模式也不怎么赚钱。Unreal 是靠像《堡垒之夜》等游戏获得收入，Unity 靠广告也不能完全覆盖整个公司的成本，需要通过引擎授权之外的方式去补充商业模式的短板。引擎业之前就是这样一种情况，因为商业模式的问题，做技术也很难，所以说做引擎很苦。

近几年需求端出现一些「蛛丝马迹」的变化。人们对于画面效果的追求越来越高，游戏的精品化趋势也是不可逆的。最近几年还有非常热的「云游戏」出现，它和以前的游戏形态是不一样的。不再是跑在用户的设备上，更多是迁移到云上，甚至渲染也在云端完成，做完渲染后再用视频流或者是直连的方式发送到客户端，提供给用户去体验。这种形态在以前是没有出现的。

游戏上云之后，物理引擎在里面提供了所有运动的基础设施的生态位。这种情况下，它有可能会变成 PaaS 类服务化的商业模式，不再以传统的、卖引擎给单个游戏的方式进行授权，而是以服务的方式卖给像云游戏这样的新生态。这就是我们最近几年看到的新的商业模式的可能性，我认为如果这种模式可行，是能够支撑独立的引擎公司活下去的。

Founder Park：包括 PaaS 在内，行业中对引擎的商业模式探索上有哪些方向？

崔汉青：在当下的时间点，引擎如果往 PaaS 方向做，大家可能不太容易看到机会或是趋势。但我觉得它会是长期的趋势。

现在不管是 Unity 还是 Unreal 这样成熟的商业引擎，或者是一些细分的物理引擎等，还是以单机 SDK 或者是开发套件被用到的，肯定是 PaaS 这样的形态。

我们再把眼光放长一点，看以后会是怎么样的。

如果我们相信元宇宙在很远的未来会来，我觉得必然会有这样一种需求：很多人都接入到同一个虚拟世界当中，在这样的世界里，除了渲染以外还需要什么样的基础设施？很重要的一点是，它一定是一个一致的世界，是一个低延迟的世界（性能要足够好，不能特别卡），它是可以横向拓展的（接入的人多了以后，容量必然是很大的）。这样一些特征映射到底层的基础设施来看，必然是像我们现实世界一样，统一的基础设施来管理这个世界里的运动和状态，它就是一个 platform，那时候 PaaS 就到来了。

Founder Park：为什么物理引擎已经发展了这么多年了，还有新的机会？

崔汉青：本质上是因为看到了需求的变化和历史演进的趋势，这是促使我们去做这件事最根本的原因。

第一个方面，我们觉得动作和物理技术在未来相比较于渲染技术更具有成长性，这也是来源于历史变迁的大趋势。我们现在正处于人和虚拟世界的交互从 2D 交互时代变迁到 3D 交互时代的过程中。

我们现在看的屏幕，不管是电脑屏幕还是手机屏幕，都是一个二维的平面；我们用手指或者鼠标点击屏幕，它与屏幕的交互也是二维的。这些都是二维的，所以我觉得它算是 2D 交互的时代。3D 交互是什么？如果你戴上 VR 头显，置身于一个全三维的虚拟环境里面，它的交互模式跟平面的交互模式很不一样，交互的升维会导致运动的真实性变得非常重要。

这是第一个历史大趋势：交互模式从 2D 到 3D。这样的变迁使得我们想去做这样的技术。

第二个方面，尽管现在还没有完全过渡到 3D 交互时代，但在当下也是有一些需求没有被很好满足。比如很多游戏需要多人在线一起玩，典型的像王者荣耀这样的游戏。那么，就需要在不同的设备间做同步。如果不能保证每个终端计算的结果完全一样，就得做状态同步。状态同步的量越大，带宽消耗就越大，这样会导致延迟的上升。如果我们能保证各个设备的计算结果是一致的话，那么就可以采用带宽消耗更小的叫 LockStep（帧同步）的同步方式。王者荣耀就是比较典型的采用这种技术的游戏，这样能保证有很好的实操体验。不过，因为王者荣耀里面很少出现物理逻辑，所以在这方面也相对比较好做。

如果现在的游戏一旦对物理逻辑有一定要求，成熟的物理引擎（包括 PhysX、Havok 和 Bullet）没有办法保证跨设备运行后计算结果还是一致的。最后开发者只能退而求其次，去控制物理状态量和状态同步时的数据量，以保证游戏体验。技术和需求之间没有实现均衡。类似这样的情况，在现在这个时代也还是被需要，并且没有被很好地解决掉。

第三个方面，在未来需求极大增长的 3D 交互时代，我们需要算力的按需分配。因为人们对于算力的需求是无止境的，所以它最好是按需分配的。这个时候就需要用到云算力，甚至是云、边缘节点和端的算力同时进行。在这个过程当中，引擎是有机会的。因为在这样的未来，显然是没有什么基础设施能够去支撑，需要引擎有跨端的能力。甚至需要引擎+算力+网络变成一体化的基础设施，真正实现动态的、分布式的、按需分配，这样才能顺利分配物理算力。

所以，从历史变迁的趋势、当下的需求、还有在未来「真正云化、算力增长之后，怎么去做算力协同」这三点来看，新的运动模拟引擎都会有成长的机会。

Founder Park：Motphys 主要落地场景有哪些？

崔汉青：我们现在来自游戏行业的客户会多一些，还有一些数字人，或者是元宇宙相关的行业也有不少。主要是在实时模拟的领域：像数字人这样的行业，通常会有一些需求是对角色身上可能需要物理模拟的部分进行实时模拟，比较典型的就是像头发或者布料这种需求。到元宇宙这样的行业，我们看到对「多人同时在线的物理互动」的这一类场景是有需求的。

客户对于画面确定性的需求还是比较普遍的——也就是游戏中的同步；在尽可能做到低延迟、省流量的同时，还能实现想要的物理效果。现在商业上的物理引擎，满足不了这样的需求，但我们是可以做到的。我们提供的确定性方案，是可以帮助游戏行业的客户去减少带宽占用和实时同步的问题的。

还有一部分诉求是性能优化方面。我们做了大量的跨端性能优化，在移动端取得比较好的性能。有时候甚至会超越现在的商业引擎，帮助客户的游戏跑得更快、更省电。

还有像 Motion Matching 方面的应用。我们是国内移动端非常早直接落地 Motion Matching 方案的公司。利用这样的技术，帮助客户提升角色动画和视觉上的表现力，也可以提升它的响应速度和操控的反应速度。这是客户认可的价值。

Founder Park：你们的产品/服务的形态是什么样的？

崔汉青：我们的产品其实现在是有不同形态的。引擎可以以插件形式存在于商业引擎之中，我们也有一些做好的编辑器工具，可以像用商业引擎原生的系统一样去用，尽可能减少两个系统之间的迁移成本。

作为 SDK 嵌入到商业引擎里，这是人们通常所预期到的一种模式。还有一种模式，我们可以提供一套底层的 API。程序员可能会更喜欢这种方式——如果你有自己的引擎，在这种情况下可以直接通过 API 调用的方式，这样的话工作量会比较大一些，但最终也是可以完成。

我们可以提供网络 API 的方式去调用，但是现在这种方式仅限于个别的客户能够使用。这种通常是分布式的需求，比如你要做云上的分布式渲染，因为游戏可能很大，同时需要一个分布式的物理算力，这个时候我们可以提供一个云上的 API，通过网络的 service call 的方式进行调用。这个模式目前还没有非常成熟，还处于测试期，可能需要再等一段时间。等初期的案例跑得比较好之后，我们才会认为比较成熟。

Founder Park：为什么选择去做通用的物理引擎？对于不同垂直行业的需求是怎么看的？

崔汉青：物理引擎其实不仅限于实时泛娱乐互动这样的行业，其它很多行业像数字孪生、工业仿真、航天模拟其实都会对物理引擎有需求。这些需求其实从「第一性原理」来看，背后都是一些非常底层的物理规律，所以通用化应该是一种比较必然的选择。

对于引擎设计本身来说，其实也是需要通用的，这样才能够用一份代码去适应各种各样不同的场景，它应用的范围才能更广。像英伟达的 Omniverse 生态系统，里面的物理部分也是通用的。我们也是这么认为的：一定要去做通用物理技术。

现在来看，虽然从技术上来看是要去做通用物理技术；但是从商业上，不同行业的 know-how 是不一样的，在产业/商业上的运作方式也不太一样。所以，从公司的战略来讲，我们不会一下子就进入到所有的行业里面。我们会先选择比较熟悉的、擅长的那些领域去做。所以，肯定是从游戏领域切入，再到游戏相关的一些领域，像数字人、元宇宙，再慢慢扩展到更多的行业中去。

Founder Park：围绕着产品，你们做了哪些核心创新？

崔汉青：第一方面是，动作和物理引擎的融合，这个是其它引擎没有做的。现在的游戏引擎通常是自研动作系统，外挂一个外部的物理引擎。如果在中间做同步和通信，需要去把数据驱动的数据和规则驱动的数据状态同步。我们把动作和物理融合在一起，这是一个比较不一样的创新。也来源于我们对虚拟世界运动的认知：数据驱动的运动和规则驱动的运动，是需要融合在一起去覆盖所有的运动。这样可以减少两个系统之间无意义的通信开销，极大程度地去提高系统的运行效率。同时我们也把不同的物理材质进行了统一求解，在单纯的物理模拟方面也有着相比传统方案不错的效率提升。

第二个是浮点数计算的确定性，这也是很重要的一点。在现在 2D 交互的时代，不同设备之间同步数据的时候，浮点数计算的确定性可以让开发者用 LockStep (帧同步) 的同步方式，无需同步大量后台数据，减少通信量，优化通信延迟，并且使得不同的异构设备协同成为可能。在未来的 3D 交互时代，云、边缘节点和端融合的渐进式的历史进程之中，浮点数计算的确定性也可以让我们在算力融合的过程中，去很好的借用不同端的算力。

第三点，分布式的引擎，也是其它引擎没有提供的功能。我们看到了很多对于运动模拟算力需求的增长，尤其是元宇宙起来之后，对于大量物理量进入同一个产品，有了天然的需求。分布式物理技术本质上是突破了单机动作物理计算的算力瓶颈，可以做到远超单机算力的超大规模的实时动作物理仿真场景，所以我们特地去做了这件事。

现在游戏的开放世界，还没有达到物理开放世界的程度。要么是单机的地图很大，用一些类似 Level Streaming（场景动态加载）的方式达到类似于开放世界的视觉效果；要么是在联网的情况下做开放世界，这种情况下通常是同步一些比较简单的状态，比如角色的位置、朝向、角色当前的动画，类似这样一些数据。再往后是什么样？各种物理状态都可以在设备之间/云上同步。世界可以无限扩展，并且世界里面的各种物理状态可以互相交互。它是一个更真实的、被物理模拟的世界，这只有一个分布式的引擎才可以满足这样的需求。这也是我们非常重要的一个创新点。

Founder Park：动作物理引擎如何搭建自己的商业生态？

崔汉青：做引擎通常会把生态看得非常非常重要。真正活下来、活得比较好的，还是在生态方面建设得比较好的公司。

从我们的引擎往下看，是和硬件的结合。我们很早就在跟一些设备厂商进行接触。设备厂商会需要一些能力，比如在设备的 SDK 或是操作系统里面附带应用模拟的能力。比如苹果的 ARKit，它有一部分运动模拟的能力。国内的设备厂商也想要这方面的能力——能不能将运动模拟能力内置到它的 SDK 或是系统里面。作为一种设备/系统的服务组件提供给上游的开发者，这样就会跟我们产生比较好的结合点。

再往下，就是芯片厂商。我们知道先辈们创业的历程，PhysX 是卖给了英伟达，HavoK 现在是在微软手上，但是它最早的时候是先卖给了芯片巨头英特尔。从这个角度来看，这些物理引擎跟芯片有很强的结合点。为什么是这样？因为做物理仿真对算力的要求是很高的。现在的各种优化都是在软件层面。但是如果想要做得更好，就需要下沉到硬件层。英伟达的显卡自带物理加速能力，这样的能力是可以被硬化到芯片里面去，更大程度上去提升物理模拟的算力。这方面我们是非常重视，也在跟国内的一些国产芯片厂商去做很多讨论。

从引擎层往上走，那就是要服务好开发者，所以我们积极探索跟通用引擎厂商的合作。我们作为通用引擎中的可选模块——现在还不是不可或缺的模块，我们至少可以作为一个可选的模块，融入引擎的生态里面去。我们没有意愿去做、从现实角度考虑也很难去做现在通用引擎厂商的颠覆者，能融入到生态里面去就可以。

我们作为可选模块，把文档、Demo 和易用性做好，开发者可以无缝切换。让开发者用最小的代价用到更好的能力，这个就是服务好开发者。

我们其实是有考虑开源方面的。我自己是开源生态的受益者，也非常希望能够给开源社区去做贡献。但实话实说，我们目前的技术阶段，还没有达到成熟的开源阶段。等它真的到了那个阶段的时候，我们还是希望它开源。关键点是在于，我们现在的成熟度，尤其是在工作链方面的成熟度，还是一个创业公司的引擎状态。当我们确实把这些东西打磨好的时候，就是一个比较合适的把它开源出来的时机。