吉姆·汉森公司以创造角色而闻名。像布偶这样的低技术角色不需要太多技术，但从沙鼠到恐龙的电子动画就需要技术，更不用说我们的 3D 计算机图形木偶了。为了能够实时现场表演，以便它们可以与人类演员互动并被拍摄下来，从技术的角度来看，这些角色有一系列特殊的需求。

吉姆·汉森最初的表演目标之一是每个人都应该控制一个角色，从而带来“委员会表演”（几个人一起表演一个木偶）难以实现的自发性和个性。一个实现这一目标的生物最吸引人的地方在于，人们会忘记是谁或什么在控制它，而只是简单地与它互动。演员和观众都开始像对待人类一样与狗、青蛙或雪人交谈。

随着伺服电机技术在 20 世纪 80 年代早期在电子动画木偶中的普及，管理越来越多的伺服电机成为一项挑战，因此计算机控制系统被设计出来。在过去的 15 年中，吉姆·汉森生物商店开发了几代控制系统，其中包括一个在 1992 年获得技术成就学院奖的版本。最新的汉森表演控制系统 (HPCS) 包含了以前系统的最佳功能，同时添加了只有今天的硬件和计算环境（如 Linux）才能实现的新技术。

PCS/HDPS 系统示意图

该系统于 1998 年初在计算机/电子主管杰夫·福布斯 (Jeff Forbes) 的指导下开始。我们有一个愿景，即一个基于标准架构的系统可以满足公司的所有需求。史蒂夫·罗森布鲁斯 (Steve Rosenbluth) 在那时作为控制系统设计师加入了该项目，迈克尔·巴布科克 (Michael Babcock) 作为多媒体程序员加入。事实证明，我们的需求相当广泛，而 Linux 似乎是唯一能够胜任这一切而毫不退缩的系统。

该系统必须支持两个后端：一个是电子动画，另一个是计算机图形。因此，我们的木偶要么是真实世界的机器人，要么是由多边形和像素制成的虚拟木偶。我们可以单独处理其中任何一个，也可以同时处理两者。

一旦木偶的软件“设置”进入系统，即使是刚接触这项技术的木偶师也能在几个小时内上手并表现出色。使用输入设备类似于演奏乐器。在某个时刻，木偶师就像音乐家一样，不再需要思考自己在做什么，而只是表演。

电子动画木偶的 PCS 设置，显示输入控制和显示 GUI 的控制系统笔记本电脑。

汉森输入设备不是运动捕捉技术。运动捕捉既直接类似于表演者，又在很大程度上是不可编程的。在运动捕捉中，表演者的手臂简单地对应于生物的手臂，膝盖对应于膝盖等等。表演者无法增强或重新编程这些关系。汉森输入方案既是非类似的，又是用户可编程的。我们的输入设备是抽象的。例如，木偶师的食指可以成比例地控制生物整个面部的真诚或讽刺。木偶师可以轻松地在表演之间甚至在表演期间重新编程木偶的运动。穿运动捕捉服的人很难表演章鱼。操作我们控制系统的人可以轻松应对。

系统的核心是一台控制计算机，运行 RTLinux，它处理并将运动数据分发给木偶。在控制计算机上运行运动混合算法的进程称为运动引擎。史蒂夫·罗森布鲁斯用 C++ 编写了它。表演者的运动通过来自外部世界的输入传感器，通过运动引擎到达联网的木偶。在运动引擎内部，对实时数据执行各种算法，解析最终的执行器位置。执行器就像木偶的肌肉；它可以是电子动画中的机电或液压伺服电机，也可以是计算机图形木偶中的“虚拟伺服”（网格变形）。运动混合关系可以在软件中配置为一对多或多对一，并且可以在这些关系之上执行复合混合。物理效果（例如重量或平滑）可以在性能数据通过运动引擎时添加到性能数据中。

运动混合算法通过一个名为工具服务器的进程提供的软件工具来提供。工具服务器使用对共享内存中的对象和数据集的直接访问，建立实时性能数据与运动引擎将对其执行的算法之间的关系。它由迈克尔·巴布科克设计，顾名思义，它是一个异步服务器，与连接到它的图形用户界面客户端进行通信。

GUI 是一个“不太薄”的客户端，通过套接字连接到工具服务器。迈克尔·巴布科克使用 GTKmm 编写了实际的应用程序，基于顾问罗伯特·麦克纳利 (Robert McNally) 的原始高级界面设计。客户端/服务器架构允许技术人员在其他机器上或额外的木偶师运行用户界面的多个实例。

HDPS GUI 示例窗口的屏幕截图

在制作过程中，有时技术人员会协助木偶师处理管理任务，因此联网的 GUI 意味着技术人员可以执行这些任务，而无需将任何人从系统中踢出。GUI 和工具服务器之间使用自定义协议进行通信。技术人员远程管理我们的控制系统应用程序的能力对我们来说非常有价值，因为制作地点可能在世界各地，而生物商店的支持人员可以完全访问以进行调试或协助。

由于 Linux 本身提供了远程访问操作系统其余部分的机制，因此生物商店的技术人员可以为我们在路上的系统提供无与伦比的支持。

正如您在示意图中看到的那样，控制系统的后端，超越运动引擎，可能会有所不同。我们可以使用远程板载计算机 (ROC) 场景中的嵌入式处理器来执行电子动画，并且我们可以使用查看器后端来执行 3D 计算机图形木偶。

在一个 60Hz 的帧中，运动引擎将获得物理输入设备的模数转换器 (ADC) 快照，根据角色设置执行运动混合算法，并将数据传输到 ROC 客户端。

我们的电子动画 ROC 是运行 DR DOS 的嵌入式 PC。史蒂夫·罗森布鲁斯用“有点面向对象的 C”编写了 ROC 代码以提高速度，因为它是一段相当精简的代码。ROC 协议允许通信链路上的多个设备，目前是 RS-232。这种老化的接口不如现代网络硬件的带宽高，但它是通过光纤、铜线和无线电最容易使用的。RS-232 是一种具有可预测触发和延迟的硬实时接口，这是我们需要的。当生物被束缚时，我们使用塑料光纤传输 RS-232，当生物是无线的时，我们使用扩频。

计算机图形查看器是在计算机屏幕上渲染和显示计算机图形 (CG) 木偶的软件模块。示意图中表示的查看器可以是能够足够快地渲染以实时显示 OpenGL 场景的 CG 建模软件包或游戏引擎阵列之一。在 20 世纪 90 年代初期，数字主管哈尔·伯特伦 (Hal Bertram) 在伦敦生物商店率先使用了汉森公司的计算机图形木偶技术。最近，迈克尔·巴布科克为其编写了控制系统插件的一些基于 PC 的 CG 应用程序包括 Discrete 的 3-D Studio Max、Side Effects 的 Houdini、Kaydara 的 Filmbox 和 Alias|Wavefront 的 Maya。

在 CG 领域，控制系统执行器是可以移动 3D 网格变形或混合形状的标量通道数据。来自控制计算机运动引擎的 UDP 网络连接将实时运动数据流式传输到查看器中。从运动引擎的角度来看，查看器的行为类似于 ROC 客户端，因为它们使用相同的 ROC 协议。

使用双 AMD Athlon 机器，我们获得了高于 100FPS 的帧率，足以在一个场景中放置多个木偶。角色技术总监杰夫·克里斯蒂 (Jeff Christie) 通过完善 3D 角色设置，从我们的 CG 模型中获得快速、逼真的性能，从而帮助完成了这幅图景。

查看器支持来自多个运动引擎的连接，这意味着，对于具有多个角色的场景，每个角色都可以由其自己的控制系统和木偶师执行，有点像联网游戏。

运动和声音可以由迈克尔·巴布科克开发的名为录制器的非线性多媒体编辑器录制和回放。该架构由迈克尔和史蒂夫设计，由通过 UDP 网络连接到运动引擎的多线程进程组成。录制器与运动引擎同步，因为它将其输出作为 ROC 客户端进行从属，但录制器也将存储的数据流式传输回运动引擎，以便广播到其他 ROC 客户端。这种联网结构允许每个进程都有自己的定时和 I/O 要求，而不会相互干扰，就像工具服务器/运动引擎关系中一样。

由于录制的运动可以被提示和实时回放，木偶师可以像制作多轨音频录音一样分层表演。这对于口型同步场景尤其有用，在口型同步场景中，生物嘴巴的表演可以在离线状态下进行完善，然后在木偶师实时表演角色的其余部分时回放。

丹·赫尔夫曼 (Dan Helfman) 为 SDL（我们在录制器中使用的开源多媒体 API）贡献了一个声音录制工具。

运动引擎中的一个模块称为链接主管，可以广播和管理与多个 ROC 客户端的连接，而不管它们的网络类型或实现如何。结果是，一个木偶师可以控制多个媒介中的多个木偶。例如，电子动画猫可以与其计算机图形对应物同时表演。当电子动画的身体和面部被摄像机捕捉时，同时表演的计算机图形嘴巴可以实时在监视器上观看，甚至与片场摄像机拍摄的图像实时合成。

用于 3D CG 角色的 HDPS 机架式设置，显示手控器、GUI 屏幕和查看器。

这允许每种媒介发挥其最佳作用。我们在片场获得了“真实”生物的复杂照明和物理效果，并且 CG 嘴部数据可以在后期制作中进一步完善，然后再与胶片合成。这种实时预览允许导演真正指导片场的生物表演，同时允许演员与他们的生物合作演员互动。

运动引擎、工具服务器、GUI 和录制器之间存在有意的划分。由于更复杂的多媒体和网络模块需要可能损害进程定时或稳定性的软件技术，因此史蒂夫·罗森布鲁斯和蒂姆·麦吉尔 (Tim McGill) 设计了一种在运动引擎周围构建一道墙的架构。目标是让运动引擎具有最少的复杂性，以便它可以持续运行。预计会变得庞大而复杂的工具服务器被允许崩溃并重新启动，而不会影响运动引擎。该架构还允许 GUI 在不负面影响工具服务器或运动引擎的情况下来来去去，录制器也是如此。为了实现这一点，系统被分段为通过 UNIX IPC 和网络进行通信的进程模块。

工具服务器和运动引擎有一个 System V 共享内存块。这使得可以立即更新关键数据对象。它们还通过两个 FIFO 进行通信，用于对顺序至关重要的消息传递。运动引擎和录制器之间还存在 UDP 网络套接字，它们以软实时方式相互流式传输数据。运动引擎是我们所谓的近乎任务关键型应用程序，因为其在现场的故障可能会给我们带来负面后果。片场停机时间每小时可能会花费电影制作公司数千美元。电影行业的性质也决定了演员和工作人员可能与电子动画机械密切接触。如果技术人员登录并重新启动应用程序时，电子动画狗咬了演员，那将是一件糟糕的事情。这就是为什么运动引擎中没有 GUI 或其他不必要的代码的原因。鉴于我们近乎任务关键型的要求，Linux 操作系统本身的稳定性是一个巨大的优势。

独立的进程架构也通过允许各个程序员编写和测试更模块化、自包含的代码块来帮助开发。它使开发人员可以自由地安全地使用自定义的，有时甚至是尖端的编程技术，而这些技术对于其他进程模块来说不是必需或不合适的。

系统的定时要求是多种多样的。运动引擎必须具有精确的 60Hz 调用频率，才能平稳地更新电子动画电机。发送到木偶的电机位置数据中的时域抖动会向该数据添加高频加速度，并可能导致木偶肢体抖动。我们的最终目标是拥有精确的 60Hz 运动引擎频率，但我们计划在系统上线时通过三个架构迭代来实现目标。

为了对系统进行原型设计，使用了周期性软件中断来将运动引擎作为处理程序调用。此外，POSIX.1b SCHED_FIFO 优先级用于确保一旦运动引擎被调用，它就不会被内核调度程序抢占。这使得运动引擎可以在用户空间中轻松运行，最重要的是，可以在调试器中运行。警报处理程序的缺点是双重的：1) 它们可能具有一个时隙或更大的抖动幅度，这是由繁忙的内核调度程序引起的，以及 2) 无法非常精确地指定它们的周期，因为它以内核计时器滴答为单位。我们重新编译了我们的内核以增加每秒计时器滴答的数量，原因有两个：将运动引擎周期舍入到接近 1/60Hz，并帮助确保较低优先级的控制系统进程更频繁地取消调度，从而帮助它们都与运动引擎状态保持同步。

对于第二个架构迭代，我们创建了一个频率为 60Hz 的 RTLinux 硬实时周期性线程。由于此线程在 RTLinux 空间中运行，因此它比内核调度程序精确大约三个数量级。我们将此线程称为我们的硬实时步调器。当它唤醒时，它将一个标志从 RTLinux 空间放入 RTLinux FIFO 中，而我们的运动引擎在用户空间中阻塞此 FIFO，并在标志到达时唤醒。尽管运动引擎仍然依赖 Linux 内核进行调用，但事实证明，此架构比我们预期的要精确得多，因为 I/O 延迟在内核中具有比信号处理更高的优先级。当没有其他繁重的系统活动时，FIFO 阻塞器步调器的典型延迟小于 40 微秒，这意味着运动引擎确实具有真正的 60Hz 调用频率，与 CPU 计时器可以提供的精度一样高。

在重负载下，内核可能无法及时解除对运动引擎的阻塞，因此这不是一个确定性的硬实时解决方案，但当我们开始将系统用于生产工作时，它为我们提供了很好的服务。双处理器 Athlon 主板可以在繁忙的循环中渲染 OpenGL 场景的同时，保持运动引擎调用精度，同时运行 GUI、工具服务器和查看器！

对于第三个也是最终的架构，我们与 FSMLabs 签订合同，以向 RTLinux 添加一个扩展，该扩展允许对 Linux 用户空间进程进行确定性调度。该机制称为 PSC，允许从 RTLinux 周期性线程“跳转”到用户空间，我们在用户空间中运行我们的运动引擎，然后我们回退到 RTLinux 并完成。我们的合同的一部分是代码将捐赠回开源 RTLinux 供所有人使用。

控制系统中使用的输入设备是线性输入电位器的特殊组合，专为人体工程学和灵活使用而设计。它们非常适合产生木偶师所需的运动类型。我们从在 Linux 笔记本电脑上运行整个控制系统的相当激进的设计目标开始，以实现“现场”的最大便携性。只有在为 CGI 服务时，我们才开始创建 19 英寸机架式控制系统。

木偶师在 HDPS 数字木偶工作站上工作。

笔记本电脑的挑战之一是将 64 个通道的模拟数据输入机器。没有可用的 A/D 转换器 (ADC) 驱动程序，因此史蒂夫·罗森布鲁斯为 Computer Boards DAS16s/16 编写了一个驱动程序。迄今为止，没有 PCMCIA ADC 卡提供超过 16 个通道，因此史蒂夫还设计了一个外部模拟多路复用器。为了在一个运动控制帧 (16.6 毫秒) 内通过四个库切换多路复用器，我们依赖于 RTLinux，它为我们提供了亚 20 微秒精度的确定性。

虽然编写低级 ADC 驱动程序可能很有意义，但这并不是花费我们可用研发资源的最佳方式。我们很高兴在 2000 年发现 United Electronics Industries 为其 Powerdaq ADC 卡提供了 Linux 和 RTLinux 驱动程序，我们在 PCI 总线系统中使用了这些驱动程序。他们的 64 通道 PD2-MF-64-333/16L 工作起来像一个魅力，UEI 对我们在驱动程序开发过程中的需求做出了积极响应。

虽然我们的设计理念的一部分是尽可能多地使用现成的硬件，但我们确实必须为我们的特殊需求设计硬件。大多数制造商对“小型”的理解根本无法与电子动画仓鼠内部的尺寸相提并论。

数字电机控制器 (DMC) 是一种特殊的硬件，大约有两个邮票大小，对于电子动画至关重要。它将数十个 PWM（脉冲宽度调制）信号分配给木偶内部的电机。史蒂夫在格伦·穆拉夫斯基 (Glenn Muravsky) 的帮助下，设计了一个基于德州仪器 320LF2406 电机控制器 DSP 的 SBC。该芯片上可用的并行性使其能够完成 PC 总线上无法完成的事情。史蒂夫还在芯片上实现了闭环 PID 算法，用于控制定制电机伺服电机。

Linux 最初并非在内核级别为硬实时设计的，但随着实时扩展的出现，我们发现我们能够在拥有通用操作系统的同时，优先处理我们的关键任务。

抢占式多任务处理、内存保护、进程间通信、网络和多媒体 API 对于我们想要实现的所有非硬实时功能至关重要。我们发现 RTLinux 架构（其中 Linux 本身作为最低优先级任务运行）使我们可以选择在运行实时任务的同一台机器上添加大量支持应用程序。

这个项目的挑战不是任何一个特定领域，而是在不损害任何一个拼图的需求的情况下，同时协调许多不同的需求。我们的软实时代码需要一个运行的机会；我们的运动控制代码需要运行而不会受到较低优先级任务的干扰；我们需要保护关键代码段免受不太重要的代码段的侵害；我们需要使用通用内核设施；我们需要使用实用程序应用程序作为我们发行版的一部分。核心操作系统和周围实用程序的设施加速了我们的开发，因为我们不必自己滚动一切的版本。但是，如果我们真的陷入困境，我们知道我们拥有源代码，因此可以控制自己的命运。因此，最终，Linux 是唯一能想到可以满足我们所有需求的操作系统。

顺便说一句，我们已经 24/7 全天候运行这些新的控制系统三年了，我们的正常运行时间平均为几个月。我们经常有理由将机器从一个位置移动到另一个位置，但我们从未发生过控制系统在生产中崩溃的情况。

在哪里可以看到我们新控制系统的产品？我们在 1999 年使用在汉森网站 www.muppetworld.com 上发布的以布偶为主角的“网络剧集”进行了首次尝试。我们已经在贸易展览会上进行了多次现场表演，其中包括为 SIGGRAPH 2000 的主题演讲制作的互动式 CG 青蛙科米特。

新的控制系统在电影中的首次航行是在 2001 年沃尔特·迪斯尼的 雪狗 中。这部电影中的主角哈士奇犬，名叫 Demon，有一个电子动画替身，用于拍摄困难的镜头——试着找出它们。正如我们所希望的那样，系统运行完美。我们在 2001 年还为 精灵鼠小弟 2 表演了一只电子动画猎鹰。Horace D'Fly 是一个 CG 角色，他将出现在即将上映的汉森家庭录像带专题片 科米特沼泽年 中。我们目前计划将该系统用于华纳兄弟的 猫狗大战 的续集，以及其他涉及电子动画的专题制作。娱乐行业对使用我们的 CG 后端制作电影、电视节目和电子游戏的角色非常感兴趣。因此，我们电影院见！