想象你是游戏公司的制作人,要办一场“物理盛宴”——在开放世界里摆放一千座会倒塌的塔楼、会飘动的布料和会飞溅的溪水。这时候来了两家搬家公司。第一家“极速联运”(PhysX)开着传送带车队,能同时吞吐海量小箱子,主打量大管饱;第二家“匠心安达”(Havok)是老师傅领衔的精工团队,每件货物都轻拿轻放、位置精确,主打稳准精细。你不会拍脑袋二选一:雕像数量、路况、预算、结账方式都会左右你的决定。这篇文章就用“搬家公司”的选择逻辑,带你看懂游戏物理引擎双雄——PhysX 与 Havok——的架构、能力、成本与选型方法。

岗位关联

理解两大物理引擎的架构差异、性能边界与授权成本,是游戏引擎工程师与技术美术做技术选型、控制预算、避免返工的核心竞争力。

目录
  1. 可视化演示
  2. 引擎概述:两张不同的名片
  3. 核心架构:流水线 vs 工坊分工
  4. 碰撞检测:如何避免箱子相撞
  5. 模拟能力:从整箱到碎屑的十八般武艺
  6. 性能对比:快与稳的取舍
  7. 平台与授权:能去哪、要花多少
  8. 选型指南:竞标决策模型
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

对比PhysX与Havok两大物理引擎的架构设计、碰撞检测流水线、GPU加速性能与选型决策。

本节配有交互动效(进入视口后自动加载,约 3KB)。

架构设计对比 PhysX组件化架构模块独立可并行计算 Havok整体优化架构跨平台一致性 PhysX = Scene + RigidBody + Constraint + Particle 两种架构各有优势适配不同场景需求

引擎概述:两张不同的名片

两家搬家公司递上名片。一家叫“极速联运”(PhysX),背后是显卡巨头 NVIDIA 的流水线装备;一家叫“匠心安达”(Havok),是微软麾下以老师傅手艺闻名的团队。卡片上写着同一个职业:搬运物体。但这张小小的名片背后,出身与哲学截然不同——这正是理解两家公司的第一把钥匙。

在游戏世界里,“搬家公司”就是物理引擎:它负责把场景中的物体从旧位置搬到新位置,并处理碰撞、变形与破碎。PhysX 与 Havok 是游戏开发中最常见的两大物理中间件,被上千款游戏使用。PhysX 由 Ageia 公司研发,2008 年被 NVIDIA 收购后深度绑定 CUDA,成为 GPU 加速物理的代表;Havok 1998 年在爱尔兰成立,先后被 Intel 与微软收购,以 CPU 多线程优化和高确定性著称。

无论哪家引擎,搬运动作的根基都是同一个运动学公式:物体新位置等于旧位置加上“速度 × 时间”。就像搬家师傅记下箱子当前位置,再按搬运速度走完一小段时间,就得到新位置。

名片背后的不同出身,决定了后面每一种“搬运方案”的风格。选谁,先要看懂这张名片。

xt+1=xt+vt×Δt\displaystyle x_{t+1} = x_t + v_t \times \Delta t
这个公式是说:每过一小段时间 Δt,物体的位置就前进“速度 × 时间”这么远,物理引擎每一帧都在重复做这件事。
  1. 位置状态 x_t当前帧物体在某个轴上的坐标,就像搬家师傅记录箱子此刻站在哪里。
    xtx_t
  2. 速度 v_t物体单位时间内移动的距离,对应师傅的搬运速度,单位是“米每秒”。
    vtv_t
  3. 时间步长 Δt物理引擎每帧推进的时间间隔,游戏里通常是 1/60 秒。
    Δt=160\Delta t = \frac{1}{60}
  4. 位置更新 x_{t+1}新位置 = 旧位置 + 速度 × 时间步长,一次“搬移”就此完成。
    xt+1=xt+vt×Δtx_{t+1} = x_t + v_t \times \Delta t

核心架构:流水线 vs 工坊分工

两家公司如何组织人手?PhysX 像一条自动化传送带:显卡上有上千个计算单元,能同时处理成千上万个细小包裹,主打“并行吞吐”;Havok 像一间老师傅工坊:把 CPU 的多核看作几位资深师傅,分工协作、每件活都做扎实,主打“多核调度”。

在架构层面,PhysX 通过 CUDA 把碰撞检测与刚体积分搬到 GPU 上执行,CPU 只负责控制流和结果回读;Havok 则实现了任务级并行(Job System),在主机多核处理器上把物理世界切成多个区域并行求解。两种架构带来两个隐藏属性:GPU 流水线擅长“广撒网”——海量粒子、碎片毫不费力,但数据在 CPU/GPU 之间往返有开销;CPU 任务调度擅长“深耕耘”——关节、角色控制器等精细约束更顺手,而且不依赖独立显卡。

并行计算的收益并不是“人多就一定快”,阿姆达尔定律揭示了天花板:加速比取决于能被并行化的比例 p 和处理器数量 N。

简单说,流水线适合量大管饱的宴席,工坊适合精雕细琢的手艺——架构没有绝对优劣,只有合适与否。

S(N)=1(1−p)+pN\displaystyle S(N) = \frac{1}{(1 - p) + \dfrac{p}{N}}
这个公式告诉我们:就算处理器无限多,串行部分的占比(1-p)最终会锁死加速上限。这也是为什么 PhysX 的 GPU 加速在物体越多时越划算。
  1. 并行比例 p代码中能被 GPU 或多核并行加速的部分占比,p 越大,加速潜力越高。
    pp
  2. 处理器数量 N参与并行计算的处理器核心数或线程数,对应雇了多少位师傅。
    pN\frac{p}{N}
  3. 串行瓶颈 1-p不可并行的部分(如结果汇总、控制流)决定了加速的最终天花板。
    1−p1 - p

碰撞检测:如何避免箱子相撞

搬运箱子最怕什么?当然是两件箱子在通道里撞上。搬家公司不会每时每刻盯着所有箱子,而是先用“分区分拣”框定风险,再逐个确认。物理引擎的碰撞检测同样分成两阶段:宽相与窄相。

宽相(Broad Phase)用 AABB 包围盒与空间网格快速排除掉“绝对不可能相撞”的物体对,把候选对象从几百对压缩到几对;窄相(Narrow Phase)再用 GJK、SAT 等算法精确计算出接触点与穿透深度。这正对应“先按货架分区,再近距确认”。碰撞发生后的反应由物理材质控制,两个关键参数是摩擦系数 μ 与恢复系数 e;此外还有触发器(Trigger),它只发出“进入/离开”事件而不产生物理推力,像仓库门口的红外感应器,用于打开机关、记录得分。

e 是“反弹保留多少速度”的度量:e=1 是完美弹跳,e=0 是撞上就粘住。

宽相筛、窄相算、材质定反应、触发器发信号——四步配合,展厅里几千个箱子才能安然无恙地各就各位。

e=−v2′−v1′v2−v1\displaystyle e = -\frac{v_{2}' - v_{1}'}{v_{2} - v_{1}}
恢复系数等于碰撞后两物体相对速度与碰撞前相对速度之比的负值。游戏里常见的弹球、果冻质感,都是调 e 调出来的。
  1. 碰撞前速度 v1、v2两个物体接触瞬间之前的运动速度,相当于箱子撞上前的行驶速度。
    v2−v1v_{2} - v_{1}
  2. 碰撞后速度 v1'、v2'碰撞瞬间之后的速度,反映碰撞对运动的改变。
    v2′−v1′v_{2}' - v_{1}'
  3. 负号与比值 ee 越大越“弹”,e 越小越“黏”,它是调手感最常用的旋钮之一。
    e=−v2′−v1′v2−v1e = -\frac{v_{2}' - v_{1}'}{v_{2} - v_{1}}

模拟能力:从整箱到碎屑的十八般武艺

宴会不只搬整箱雕像,还有桌布、汤水和碎掉的瓷片。两家公司都需要十八般武艺:刚体、软体、布料、流体。这就像搬家车队既要搬保险柜,也要打包丝绸窗帘,还得防止鱼缸里的水洒出来。

刚体(Rigid Body)形状不变,适合门板、箱体等硬物;软体(Soft Body)会形变回弹,模拟果冻、肌肉;布料(Cloth)用弹簧网格模拟裙摆、旗帜;流体(Fluid)则用 SPH(光滑粒子流体动力学)模拟水与烟雾。PhysX 的布料与流体大量跑在 GPU 上,粒子规模可达十万级;Havok 的布料更强调与角色动画系统(Havok Animation)联动,在主机上保持稳定帧率。

布料与软体的地基,是物理课上最著名的胡克定律:弹簧的回复力与形变量成正比。

弹簧模型是布料、软体的地基——就像老师傅手中的橡皮筋,形变越大,回拉的力量越强,世界也因此有了“弹性”。

F=−k(x−x0)\displaystyle F = -k (x - x_0)
弹簧被拉得越长,往回拽的力越大。把无数根这样的弹簧编织成网格,就有了会飘动的桌布和会晃动的果冻。
  1. 刚度系数 k弹簧的“硬度”,k 越大越难拉变形,对应布料的挺括程度。
    kk
  2. 形变量 x - x0当前长度与自然长度之差,差得越多,弹簧被拉得越狠。
    x−x0x - x_0
  3. 负号的方向回复力永远指向“回到原长”的方向,所以带负号。
    −k(x−x0)-k (x - x_0)

性能对比:快与稳的取舍

搬家竞标时,客户最关心“快不快、稳不稳”。PhysX 的卖点是吞吐:在 NVIDIA 显卡上能以每秒数十万粒子的规模,撑起开放世界中的爆炸碎片、沙尘与流水。Havok 的卖点是可控:固定时间步长加上高确定性,让每一帧的物理结果可复现,这在格斗游戏联机帧同步中是生死攸关的指标。

实际项目中,物理不会独占整台机器。帧预算通常先划给渲染和游戏逻辑,剩下的时间才轮到物理引擎“出菜”。假设目标 60 FPS,每帧总预算 16.7ms,渲染吃掉 9ms、逻辑吃掉 5ms,物理只剩 2.7ms 的窗口。因此选型要同时看三个数字:目标物体数量、可用 CPU/GPU 预算、对确定性的要求。

快与稳就像搬家公司报价单上的“速度”与“保险”——没有免费午餐,省下的时间总要在别处加倍付出。

Pphysics=1FPS−Trender−Tlogic\displaystyle P_{physics} = \frac{1}{FPS} - T_{render} - T_{logic}
物理模拟的时间预算 = 每帧总时长 − 渲染耗时 − 逻辑耗时。超了预算就会掉帧,物理引擎必须在这个窗口内“干完活”。
  1. 帧预算 1/FPS目标帧率下每帧的总时长,60FPS 就是 1/60 ≈ 16.7ms。
    1FPS\frac{1}{FPS}
  2. 渲染与逻辑耗时T_render 负责画画面,T_logic 负责游戏规则,两者先分走大块时间。
    Trender+TlogicT_{render} + T_{logic}
  3. 物理预算 P剩下给刚体积分、碰撞检测和布料模拟的“出菜窗口”。
    PphysicsP_{physics}

平台与授权:能去哪、要花多少

搬家公司的报价单上有两行:车能开到哪些城市,以及怎么收费。PhysX 出身 NVIDIA 生态,在 PC 与 PlayStation 上覆盖最广,4.0 版本起以 BSD-3 协议开源免费;Havok 深耕主机多年,被微软收购后与 Xbox 体系深度整合,但商业授权价格昂贵。

授权之外还有工具链。PhysX 提供 Visual Debugger(PVD)可视化调试,能透视每一帧的碰撞体;Havok 则打包了 Animation(动画)、Destruction(破坏)、Cloth(布料)等一整套中间件,内容团队可以“一站式”采购。采购决策要算“总拥有成本”:授权费 + 工程师集成工时 + 后续维护,开源省了授权费,但学习成本和自研工程量可能更高。

就像请搬家公司,别只看起步价——开进老城窄巷的加价、易碎品的保险,都会出现在最终账单上。

Ctotal=Clicense+Cengineer×Tintegration\displaystyle C_{total} = C_{license} + C_{engineer} \times T_{integration}
总成本 = 引擎授权费 + 工程师单价 × 集成耗时。谈授权时只盯着 License 价格,就像搬家只看起步价,容易忽略后面的加价项。
  1. 授权费 C_license商业引擎的年费或开源协议下的合规成本。
    ClicenseC_{license}
  2. 人力成本 C_engineer团队工程师的单位时间价格,是隐性的大头。
    CengineerC_{engineer}
  3. 集成工期 T_integration接入 SDK、迁移场景、调参验证的总天数。
    TintegrationT_{integration}

选型指南:竞标决策模型

终于到了竞标拍板时刻。项目组围坐一桌,对着两家公司的方案打分。没有绝对答案,只有基于权重的取舍。游戏类型是最大的权重项:开放世界、大逃杀类游戏海量建筑碎片与载具场景,更适合 PhysX(虚幻引擎与 Unity 均内置 PhysX,开箱即用);格斗、动作、平台跳跃类游戏强调手感精确与帧同步确定性,Havok 在主机 3A 中屡立战功,如《塞尔达传说》系列就采用 Havok 系物理。

集成流程也决定成本:初始化物理世界 → 创建 Actor 并挂碰撞体 → 设置物理材质 → 每帧调用 step 推进固定时间步 → 读取结果驱动表现层。两支团队都按这个范式工作,差异在 API、坐标系与工具链细节。最终打分,可以用一个加权评分模型:把每个决策维度打分,再乘上它的权重并求和。

打分表填完,也许 PhysX 以微弱优势中标,也许 Havok 因确定性翻盘——但无论选谁,这笔账都要回到“物体数量、精度需求、平台预算、团队技能”四个维度来算,这就是本篇文章教给你的决策模型。

S=∑i=1nwisi\displaystyle S = \sum_{i=1}^{n} w_i s_i
总分 S = 各维度得分 s_i 乘上权重 w_i 后加总。权重怎么定,取决于你的游戏类型、平台和目标帧率,没有标准答案。
  1. 单项得分 s_i对“性能、平台、成本、团队熟悉度”等维度分别打分,比如性能 8 分、成本 6 分。
    sis_i
  2. 权重 w_i每个维度的重要性比例,所有 w_i 相加等于 1,格斗游戏会把“确定性”权重调得很高。
    wiw_i
  3. 加权求和把每项“得分 × 权重”累加起来,总分最高的引擎就是当下最合适的选择。
    ∑i=1nwisi\sum_{i=1}^{n} w_i s_i

AI 应用场景

游戏 AI 的物理预判闪避

阶段:感知与决策

解决的问题:传统 NPC 躲避玩家攻击靠硬编码规则,遇到爆炸产生的碎片、被击飞的载具就“假装看不见”;借助物理引擎查询碰撞体位置与刚体速度,AI 可以动态预判危险区域,提前做出闪避动作。

具体案例:一款 3D 动作游戏中,敌方 BOSS 在玩家投掷炸弹后,利用物理引擎读取炸弹的抛物线轨迹与地面弹跳参数,计算出落点并走位,玩家会明显感到 BOSS“会躲了”,战斗沉浸感大幅提升。

自动驾驶仿真中的碰撞测试

阶段:训练与仿真验证

解决的问题:真实路测成本高、场景不可控;用 PhysX/Havok 风格的物理引擎在虚幻引擎中搭建仿真环境,模拟车辆与行人、护栏的碰撞动力学,AI 模型可以在虚拟世界中快速积累稀有事故数据。

具体案例:自动驾驶仿真平台(如 CARLA)借助物理引擎模拟传感器探测与碰撞反馈,每天在虚拟城市中跑上万公里,覆盖真实道路难以复现的极端场景,再把训练好的模型部署到实车。

数字孪生仓库的搬运规划

阶段:方案规划与验证

解决的问题:电商仓库要验证“十万个货箱如何堆叠不倒塌、AGV 小车走哪条路线不碰撞”,在真实仓库实验代价极高;用物理引擎做数字孪生,批量模拟箱体堆叠稳定性与小车避障,先仿真再落地。

具体案例:某物流企业用 GPU 加速的 PhysX 同时模拟数万个货箱的堆叠与下落,AI 规划算法在仿真中迭代搬运策略,最终把仓库空间利用率提升了 15%,完美对应“搬家公司”的比喻。

Python 演示

python71 行
import randomimport time  class Box:    def __init__(self, x, y, radius, vx=0.0, vy=0.0):        self.x = x        self.y = y        self.r = radius        self.vx = vx        self.vy = vy  class PhysicsWorld:    """迷你 2D 物理世界: 负责积分推进(搬运)与宽相筛选(防撞)."""     def __init__(self, gravity=9.8, dt=1.0/60.0, ground=100.0):        self.gravity = gravity        self.dt = dt        self.ground = ground        self.boxes = []     def add(self, box):        self.boxes.append(box)     def step(self):        """前向欧拉积分 + 地面碰撞响应, 模拟固定时间步."""        for b in self.boxes:            b.vy += self.gravity * self.dt            if b.vy > 50.0:                b.vy = 50.0            b.x += b.vx * self.dt            b.y += b.vy * self.dt            if b.y + b.r > self.ground:                b.y = self.ground - b.r                b.vy = -b.vy * 0.65     def grid_pairs(self, cell=12.0):        """空间哈希实现宽相: 把箱子分进格子, 统计候选对数量."""        grid = {}        for b in self.boxes:            key = (int(b.x // cell), int(b.y // cell))            grid.setdefault(key, []).append(b)        pairs = 0        for boxes in grid.values():            n = len(boxes)            pairs += n * (n - 1) // 2        return len(grid), pairs  def main():    world = PhysicsWorld()    for _ in range(800):        world.add(Box(random.uniform(0, 200), random.uniform(0, 80),                      random.uniform(0.4, 1.4),                      random.uniform(-1.0, 1.0), 0.0))    n = len(world.boxes)    naive = n * (n - 1) // 2    t0 = time.perf_counter()    for _ in range(120):        world.step()    ms = (time.perf_counter() - t0) * 1000.0    cells, grid_pairs = world.grid_pairs()    print("箱子数量: {}".format(n))    print("朴素两两检查候选对: {}".format(naive))    print("空间哈希后候选对: {} (共 {} 个格子)".format(grid_pairs, cells))    print("120 帧物理积分耗时: {:.2f} ms".format(ms))  if __name__ == "__main__":    main()
目的:用 800 个箱子的下落模拟,演示物理引擎“积分推进 + 宽相空间哈希”如何把候选碰撞对从 32 万级降到几百级,这正是 PhysX/Havok 高性能的幕后功臣。
  1. for _ in range(800):投放 800 个箱子,模拟大规模刚体场景,对应“量大管饱”的搬运任务。
  2. b.vy += self.gravity * self.dt积分:重力改变速度,速度改变位置,是《引擎概述》公式的直接实现。
  3. if b.y + b.r > self.ground:地面碰撞检测,防止箱子穿地,并乘以 0.65 模拟恢复系数损耗。
  4. grid.setdefault(key, []).append(b)宽相:把箱子按空间格子归类,这就是“按货架分区”的代码形态。
  5. pairs += n * (n - 1) // 2统计每个格子内的候选碰撞对数量,避免 O(n²) 朴素检查。

常见误区

误区“PhysX 能用显卡加速,所以任何场景都比 Havok 快,闭眼选它准没错。”

正解显卡加速只在物体数量巨大(如数万粒子)且 GPU 有余力时占优;小而精的场景、低端显卡或 CPU 紧张的项目里,Havok 的多核 CPU 调度反而更稳定。就像流水线车队在空旷平原跑得快,进了老城窄巷还是老师傅灵活。

为何常见:厂商宣传和极端基准测试很容易让人忽略硬件瓶颈和场景差异,误把“特定场景的更快”当成“永远更快”。

误区“物理引擎嘛,就是让两个物体撞在一起时候有反应,其他它就不管了。”

正解碰撞检测只是宽相/窄相的一部分,引擎还包含刚体动力学积分、约束求解(关节、弹簧)、布料、软体、流体和触发器事件。PhysX 和 Havok 都是完整的“世界模拟器”,碰撞只是它们工作清单里的第一行。

为何常见:多数入门教程从碰撞体讲起,让初学者误以为碰撞检测就是物理引擎的全部。

误区“PhysX 开源又免费,Havok 还要花大钱买授权,当然是选 PhysX,成本为零。”

正解PhysX 4.0 才以 BSD-3 协议开源,早期版本闭源且 GPU 加速绑定 NVIDIA 显卡;Havok 虽收费,但提供动画、破坏、布料等完整中间件和主机平台深度支持。选型要算总拥有成本(授权 + 集成 + 团队学习),开源只省了第一项。

为何常见:只盯着 License 的标价,忽略了集成工期和平台适配这些更贵的隐性账单。

误区“引擎物理那么真实,游戏里手感不好一定是引擎的锅,换引擎就能解决。”

正解手感由物理材质的摩擦系数、恢复系数、碰撞体形状(凸包代理)、质量与重力缩放共同决定,需要技术美术反复调参。同一个引擎可以调出“飘”和“沉”两种截然不同的手感,换引擎往往解决不了调参问题,反而引入迁移成本。

为何常见:引擎“模拟真实世界”的营销话术让玩家误以为参数无需干预,而游戏制作里“真实”常常要为“好玩”让路。

面试题

Q1. 下列哪项是 PhysX 区别于 Havok 的核心特色?

单选题 · easy

  • A.支持 GPU 并行加速模拟← 正确答案
  • B.只运行在 CPU 单核上
  • C.不提供碰撞检测模块
  • D.只支持 2D 物理应用

答案:A。PhysX 被 NVIDIA 收购后深度绑定 CUDA,能以 GPU 大规模并行处理粒子与刚体;Havok 更强调 CPU 多线程调度。B、C、D 都是与事实不符的错误特征。

Q2. 物理引擎的宽相(Broad Phase)阶段主要完成什么任务?

单选题 · easy

  • A.精确计算碰撞接触点
  • B.快速排除不可能碰撞对← 正确答案
  • C.求解刚体的旋转矩阵
  • D.渲染碰撞表面的纹理

答案:B。宽相用 AABB 包围盒和空间网格等低成本手段先剔除距离远的物体,剩下少量候选对交给窄相精确计算。这就像搬家公司先按货架分区,再逐个确认箱子会不会相撞。

Q3. 恢复系数 e 为 0.8 的球落地反弹后,其反弹速度约为落地前的多少倍?

单选题 · mid

  • A.0.2 倍
  • B.0.8 倍← 正确答案
  • C.1.0 倍
  • D.1.8 倍

答案:B。恢复系数定义为碰撞后相对速度与碰撞前相对速度之比的负值,e=0.8 表示反弹速度保留 80%,能量则损耗了约 36%(e²=0.64)。e=1 是完美弹跳,e=0 是撞上就停。

Q4. Havok 在性能优化上最典型的策略是什么?

单选题 · mid

  • A.多核 CPU 并行任务调度← 正确答案
  • B.GPU 流体粒子加速模拟
  • C.关闭布料模拟节省内存
  • D.降低全部物体摩擦系数

答案:A。Havok 以多线程 Job System 著称,擅长在主机多核 CPU 上调度物理任务;GPU 加速粒子是 PhysX 的招牌。C 和 D 属于功能取舍而非性能策略。

Q5. 关于 PhysX 的授权与开源情况,下列说法正确的是?

单选题 · mid

  • A.4.0 起以 BSD-3 协议开源← 正确答案
  • B.所有版本都需支付高额年费
  • C.源码不允许用于游戏开发
  • D.商业游戏禁止使用 PhysX

答案:A。PhysX 早期闭源,4.0 起以 BSD-3 协议开源可免费商用;Havok 则需要商业授权。B、C、D 均与事实不符,开源不等于“随便用”,仍需遵守协议条款。

Q6. 目标 60 FPS 时,若每帧渲染耗时 9ms、游戏逻辑耗时 5ms,留给物理模拟的预算约为多少?

单选题 · hard

  • A.16.7 毫秒
  • B.14.0 毫秒
  • C.2.7 毫秒← 正确答案
  • D.30.0 毫秒

答案:C。1/60 秒约等于 16.7ms,减去渲染 9ms 和逻辑 5ms,物理预算只剩约 2.7ms。物理引擎必须在这窗口内完成积分与碰撞检测,否则会掉帧,这就是“出菜窗口”的残酷现实。

Q7. 宽相阶段使用空间网格(Spatial Grid)的主要目的是什么?

单选题 · hard

  • A.减少需要精确检测的候选对← 正确答案
  • B.把物体渲染为网格纹理
  • C.增加物理子步的迭代次数
  • D.将刚体拆分为多个碰撞体

答案:A。空间网格把场景切成格子,只有同一格或相邻格的物体才进入窄相检测,把 O(n²) 降为近 O(n)。这就像仓库按货架分区,只在同一货架内检查箱子是否相撞。

Q8. 物理引擎通常包含以下哪些模拟能力?

多选题 · mid

  • A.刚体动力学模拟← 正确答案
  • B.布料与软体模拟← 正确答案
  • C.粒子流体模拟← 正确答案
  • D.游戏存档压缩

答案:ABC。刚体、布料、软体、流体(SPH)都是物理引擎的组成模块,分别对应“保险柜、窗帘、鱼缸水”;存档压缩属于数据管理,不属于物理模拟范畴。

Q9. 进行物理引擎选型时,应当考虑哪些因素?

多选题 · mid

  • A.目标平台的硬件预算← 正确答案
  • B.团队熟悉度与学习成本← 正确答案
  • C.授权费用与开源情况← 正确答案
  • D.游戏美术风格的色调

答案:ABC。选型要综合性能、平台覆盖、授权成本与团队技术栈,用加权评分模型量化;美术色调与物理引擎没有直接关系,属于干扰项。

Q10. 关于物理引擎的确定性(Determinism),下列说法正确的有哪些?

多选题 · hard

  • A.Havok 多线程确定性更优← 正确答案
  • B.帧同步联机依赖物理确定性← 正确答案
  • C.GPU 并行必然保证逐位确定
  • D.物理引擎应避免逻辑随机数干扰← 正确答案

答案:ABD。Havok 在 CPU 多线程调度上确定性较好,适合格斗游戏的帧同步联机;GPU 并行(PhysX)因浮点合并顺序不确定,难以保证逐位一致;任何随机数都会破坏可复现的物理回放,所以 D 正确。