概念页
碰撞查询
Collision Queries
碰撞系统除了检测真实物体的接触,还要回答假设性问题:子弹从枪口朝某方向飞,先打中什么?车能否从 A 开到 B 不碰到东西?某半径内有哪些敌人?这类操作称为碰撞查询。最常见的是投射 (cast),也叫 trace 或 probe:沿射线或线段移动一个假想物体,看它会碰到什么;被投射的东西并不真正进入碰撞世界,不会影响其他物体(GEA4 卷 II 14.3.7)。
射线投射
- "射线"其实是有向线段,起点 、增量 ,终点 :。接触点可以用唯一的 值描述,多数 API 返回 值或提供换算函数(卷 II 14.3.7.1)。
- 多数系统能返回最早接触( 最小),有的能返回线段穿过的所有 collidable。每个接触通常包含 、被击中 collidable 的唯一 id,可能还有接触点法线等表面属性:
struct RayCastContact {
F32 m_t; // 该接触的 t 值
U32 m_collidableId; // 打中了哪个 collidable
Vector m_normal; // 接触点表面法线
// 其他信息...
};
- 用途:视线检测(从 A 的眼睛投到 B 的胸口,先打到别的物体就是被挡住)、武器弹着、玩家机制(脚下是否有地面)、AI(视线、瞄准、移动查询)、载具(找到地形并把轮胎贴上去)。射线与各种图元的求交算法见 光线求交测试。
形状投射
- 问:一个假想的凸形状沿有向线段能走多远才碰到实心物体。投射球体叫球形投射 (sphere cast),一般叫形状投射 (shape cast),Havok 称 linear cast。描述包括起点、距离 、形状类型、尺寸和朝向(卷 II 14.3.7.2)。
- 两种情况:
- 起点就已穿插或接触其他 collidable,无法移动:报告与所有初始穿插对象的接触,接触点可能在形状内部或表面。
- 起点不相交,可以移动非零距离:通常只碰到一个 collidable,但轨迹恰好时可能同时碰到多个,碰到非凸 poly soup 时也可能多点接触;此时接触点总在形状表面,不会在内部。
- 返回信息比射线复杂: 只描述形状中心沿路径的位置,不说明接触发生在形状哪里,所以要同时返回 和实际接触点。由于可能多点接触,形状投射 API 必须能报告多个接触:
struct ShapeCastContact {
F32 m_t;
U32 m_collidableId;
Point m_contactPoint; // 实际接触位置
Vector m_normal;
};
- 同一 值的一组接触点共同描述一次接触,最早接触就是所有 最小的点。系统未必按 排序返回,最好自己排序,保证列表第一个总属于最早接触。
- 用途:用球形投射检测相机是否与世界碰撞;用球或胶囊投射实现角色移动:在双脚之间沿运动方向投射,再用第二次投射上下调整以贴地;碰到路沿这样很矮的障碍就"弹上去",碰到墙这样太高的障碍就沿墙水平滑动;投射最终停下的位置就是下一帧角色的位置。
幻影
- 找出某体积内有哪些 collidable(如玩家周围某半径内的所有敌人),Havok 提供一种特殊 collidable:幻影 (phantom)(卷 II 14.3.7.3)。
- 它像位移 的形状投射,随时可以询问其接触列表,格式与零距离形状投射基本相同。
- 区别是幻影持久存在于碰撞世界中,因此能充分利用引擎的时间相干性优化。它和普通 collidable 唯一的不同是对其他所有 collidable"不可见"(包括其他幻影),也不参与动力学,所以只回答假设问题而不影响任何对象。
其他查询
有的引擎还支持别的查询,例如 Havok 的最近点查询:在碰撞世界中找出其他 collidable 上离给定 collidable 最近的点集(卷 II 14.3.7.4)。
查询的时机
物理步通常在帧末执行,查询要拿到最新信息就得在物理步之后跑。GEA 给出的选项(多数游戏会混用):基于上一帧的状态做决策(例如上一帧是否站在东西上,决定这一帧是否开始下落);接受一帧延迟(物体不太快时察觉不到);把能推迟的决策放到物理步之后再查询(卷 II 14.5.2.1)。详见 物理引擎与游戏的集成。
与 UE5 的对照
UE5 的射线检测按追踪通道 (Trace Channel)(默认 Visibility、Camera)决定被阻挡还是忽略;Collision Enabled 设为 Query Only 的组件只参与射线、扫掠和重叠查询,不参与模拟,官方举例适合角色移动(Collision Response Reference)。这对应 GEA 的"投射 + 幻影"组合:扫掠 (sweep) 对应形状投射,重叠查询对应零位移的形状投射或幻影(这一对应是归纳)。UE5 中的角色移动和相机见 角色移动组件与 Mover、相机系统。
出处
- Game_Engine_Architecture_4th_Edtion_Volume_2_-_Jason_Gregory.pdf
- Jason Gregory《Game Engine Architecture》第 4 版(2026)卷 II 第 14 章 14.3.7 节
- Collision Response Reference
相关页面
游戏开发碰撞检测系统Collision Detection System碰撞检测系统判断游戏世界里的物体是否接触,本质上是一个"高级几何相交测试器",同时返回接触的详细信息。每个可碰撞对象由形状 + 变换描述,全部存放在独立的碰撞世界里;形状尽量用球、胶囊、盒、凸体等简单图元。为了在大量物体中快速找到真正相交的对,引擎使用时间相干性、空间划分,以及宽相、中相、窄相三级筛选(GEA4 卷 II 14.3)。游戏数学光线求交测试Ray Intersection Tests光线求交用于拾取、光线追踪、地面高度查询等。本页给出四类经典测试:光线-球(代数解与带早期拒绝的几何优化解)、光线-盒(平板法与光线斜率法)、光线-三角形(Möller-Trumbore,直接从顶点求重心坐标与距离)、光线-多边形(先求平面交点,再投影到二维做交叉数测试)。共同思路是先做便宜的拒绝测试、推迟除法与开方、必要时降维。游戏开发物理引擎与游戏的集成Integrating a Physics Engine into a Game碰撞/物理世界里的刚体只是抽象的数学描述,要通过游戏对象这个中枢,间接连到屏幕上的视觉表现。刚体按谁驱动分三类:物理驱动、游戏驱动(Havok 称 key framed)、固定;Havok 用可在运行时切换的"运动类型"统一表示。每帧更新有固定顺序:先更新游戏驱动刚体、幻影、力、冲量和约束,再步进模拟,然后回读物理驱动对象、查询幻影、执行投射查询。物理宜用恒定的 1/30 或 1/60 秒时间步。GEA 还逐一讨论了子弹、手雷、爆炸、可破坏物、角色移动、相机碰撞和布娃娃的实际做法(GEA4 卷 II 14.5–14.6)。游戏开发 · UE5Chaos 物理与碰撞Chaos Physics & CollisionChaos 是 UE5 的物理与破碎系统。日常最常打交道的是碰撞模型:每个物理体有对象类型 (Object Type) 和对其他类型的 Block/Overlap/Ignore 响应,结果由双方共同决定;Hit 与 Overlap 事件都要显式开启。骨骼网格通过物理资产 (Physics Asset) 获得刚体与约束(布娃娃、物理动画);Chaos 破碎基于几何集合 (Geometry Collection) 的分级断裂、簇阈值、连接图与缓存回放,并能把事件交给 Niagara。物理体用盒/球/胶囊/凸包代理,原理对应游戏数学中的包围体与相交测试。游戏开发 · UE5角色移动组件与 MoverCharacter Movement Component & Mover角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。游戏开发 · UE5相机系统Camera System传统相机链路是:PlayerController 持有 PlayerCameraManager,后者维护一个视图目标 (view target),通过 CalcCamera 取得相机组件或 Actor 的位置朝向,并在不同目标之间混合。实验性的 Gameplay Camera System 把相机行为做成数据资产:一个 Camera Asset 包含多个由节点网络构成的 Camera Rig、进出转换,以及决定当前使用哪个 Rig 的 Camera Director。游戏开发 · UE5AI 感知、EQS 与导航AI Perception, EQS & NavigationAI 的感官层由三块组成:AI 感知 (AI Perception) 组件挂在 AIController 上监听视觉/听觉/伤害等刺激并更新黑板;环境查询系统 (EQS) 用生成器产生候选项、先过滤后打分,回答「哪里最好」;导航系统从碰撞几何生成分瓦片的导航网格 (NavMesh),按多边形代价寻路,并提供 RVO 与 Detour Crowd 避让。它们为行为树/StateTree 提供输入。游戏开发三维音频渲染3D Audio Rendering3D 音频渲染引擎要尽可能可信地重现"玩家若真在游戏世界里会听到什么"。它的输入是世界里大量的 3D 声音,输出是少数几路扬声器声道;主要任务是合成、空间化(距离衰减 + 声像定位)、声学建模(混响、遮挡、衍射)、多普勒和混音。GEA 给出了恒功率声像律、聚焦角、混响区域交叉混合、遮挡/阻挡/排除的分析方法,以及顽皮狗《最后生还者》的随机传播建模和声音门户(GEA4 卷 II 15.4)。游戏开发游戏对象引用与查询Game Object References & Queries游戏对象需要唯一 id 来区分、查找和充当通信目标;找到对象后还要能引用它,引用的寿命可以从一次函数调用到许多分钟。GEA 比较三种实现:裸指针最快最简单,但有孤儿对象、悬垂指针、非法指针三类问题,且不能配合内存重定位;智能指针可以检测对象已删除、做引用计数,但很难写对,GEA 个人建议远离它,非用不可就用 C++11 标准库或 Boost 的成熟实现;句柄是全局句柄表的整数索引,加上唯一 id 防止槽位复用后指向错误对象,简单而安全。对象查询则不追求通用数据库,而是为最常用的查询建专门的数据结构(GEA4 卷 II 17.5)。游戏策划角色度量与基础移动Character Metrics & MovementRogers 把角色 (Character)、镜头 (Camera)、操控 (Control) 称为"三个 C",必须在前期定下,中途改动会像涟漪一样波及整个游戏。角色的玩法核心是度量 (metrics):以主角的身高、速度、可达高度为尺子,度量全世界的通道宽度、跳跃距离与攻击距离,玩家会像击剑手一样"凭眼"判断这些距离。在此之上,本页整理抽象游戏的度量、行走、奔跑、冲刺、潜行、待机、跳跃、攀爬与边缘摇晃、坠落、影子、游泳的设计要点,以及如何用角色本身传达状态(Level Up! 第 3 版 Level 5 The Three Cs, Part 1: Character,第 103、112–1