Ghost Collision 是什么？为什么 Unity / Unreal 总会撞到“空气墙”？

你在 Unity 或 Unreal 里按下 Play，地板看起来是平的，门洞看起来是开的，走廊也对齐了，但角色跑过去时却突然卡一下、弹一下，或者像撞到一堵根本不存在的墙。

这类问题最烦的地方就在这里：画面看起来没问题，手感却完全不对。

它通常不是单一参数没勾上，而是更底层的一类问题：视觉网格（Render Mesh）和物理边界（Collider / Collision Mesh）没有对齐。行业里常把这种现象叫做 Ghost Collision。

直接答案是：Ghost Collision 本质上不是“引擎发疯”，而是资产结构、碰撞近似、拓扑质量、缩放层级和导入链路之间出现了错位。你看到的是一套表面，物理系统感受到的却是另一套边界，于是玩家就会觉得自己撞上了“空气墙”。

如果你还没看过 Physics-Ready 3D 的基础概念，建议先读这篇：

• 什么是 Physics-Ready 3D？为什么 AI 生成模型总卡在“最后一公里”

如果你已经在 Unity 里遇到穿模、碰撞异常或重心问题，也可以继续看这篇更聚焦的排查文章：

• Unity AI 3D 模型穿模怎么修？一篇讲清 Collider、重心与 Physics-Ready 工作流

30 秒快速结论：Ghost Collision 到底是什么

一句话理解：

Ghost Collision = 玩家看到的可通行区域，和引擎实际判定的可通行区域，不是同一套东西。

你可以先用这张表快速判断：

对独立开发者和小团队来说，Ghost Collision 最贵的地方不只是修一次，而是它会让 QA、关卡调试和每次资产迭代都变慢。

如果你正处在“问题不大但总在吞时间”的阶段，可以再看 独立开发者的隐形时间杀手：为什么 3D 资产后处理会吞掉 70% 开发时间？，两篇一起看会更容易判断这到底是单个 bug，还是工作流问题。

什么叫 Ghost Collision？先把概念讲人话

很多人第一次碰到这个问题时，会以为是角色控制器、轮子组件或者某个物理参数有 bug。

但 Ghost Collision 其实更像一种“感知错位”：

• 人眼看到的是渲染后的表面
• 引擎计算的是碰撞边界
• 这两套结果一旦不一致，手感问题就立刻出现

所以它不是必须“真的有一面隐藏的墙”，才叫 Ghost Collision。

只要下面这些情况出现，本质上都算同一类问题：

• 明明是平地，角色却像被小凸起绊住
• 明明门洞开着，玩家却进不去
• 道具看起来落在桌面上，实际却悬在一层看不见的碰撞上
• 物体滑行时在某一个点总会抖动或弹起
• 某些位置的 traversal 手感明显发黏、发涩，但画面里看不出原因

为什么它比普通碰撞 bug 更麻烦

普通碰撞 bug 至少还是“看得见原因”的：墙挡住你，是因为墙就在那里。

Ghost Collision 更糟，是因为它会破坏玩家和开发者对场景的信任。

玩家会觉得：

• 这个关卡不顺
• 移动手感发假
• 物理表现不稳定

开发者会觉得：

• 很难复现
• 很难定位到底是哪一层出错
• 改了一处，别处又冒问题
• QA 会花大量时间在“明明看着没问题”的区域来回试

从工作流角度看，它通常不是单一 bug，而是一条资产链路的问题：生成、清理、碰撞近似、导出、导入、引擎验证，任何一环没处理好，最后都可能表现成“空气墙”。

Ghost Collision 为什么会发生？最常见就是这 5 类原因

1. 多个相邻 Collider 之间有缝、重叠或边界噪声

这是最经典的一种。

场景看起来像一整块连续地板，实际上底层是很多相邻的 collider 拼出来的。只要这些边界之间有轻微错位、重叠、法线不一致，角色控制器、刚体或者轮子就可能在接缝处被卡住。

最常见来源：

• 模块化地板或墙面
• kitbash 场景拼装
• 分块地形
• Auto Convex 之后得到的一串相邻 hull

这也是为什么很多“只在某一个 seam 出问题”的 bug，最后都不是角色逻辑的问题，而是碰撞边界拼接得不干净。

2. 自动生成的 Collider 过拟合或欠拟合

自动生成碰撞体很快，但不代表稳定。

如果它过于贴近原网格，就会把很多玩家看不见的小突起、小薄片、小尖角也保留下来，结果是：

• 走路时发涩
• 滚动物体在平面上轻微跳动
• 某些位置会产生奇怪摩擦感

如果它又太粗糙，超出了真实可见轮廓，就会变成另一种问题：

• 门框看起来开着，但实际被封窄
• 桌角明明没碰到，却撞上 invisible blocking
• 角色和道具“悬浮”在空气上

所以太精和太粗都不行。Ghost Collision 很多时候就是近似策略选错了。

3. 资产里存在隐藏、重复或历史遗留几何

导入资产时，场景里不一定只有你肉眼看到的那层表面。

很多模型会带进来这些东西：

• 隐藏支撑网格
• 重复 shell
• 旧版本残留 mesh
• 被复制出来但没清理掉的 collision node
• 嵌套层级中遗留的子物体

结果就是：美术视角看着没问题，但物理场景里其实多了一层会阻挡玩家的东西。

这类问题尤其常见于：

• 市场素材快速拼装
• 多工具链导入导出
• 团队里多人轮流改同一资产
• AI 生成结果被手动补过几轮之后再次导出

4. 拓扑质量差，碰撞建立在不稳定网格上

这类问题肉眼有时不明显，但对碰撞系统特别致命。

常见情况包括：

• 非流形边
• 自相交
• 法线翻转
• 断开的碎片岛
• 极薄三角面
• 裂缝、孔洞、悬空面

这些问题的危险在于：模型在截图里也许很好看，但 collision generation 建立在这种网格之上，就容易产生不可预测的边界。

也就是说，Ghost Collision 不是“碰撞系统单独坏了”，而是它接收到的源几何就不稳定。

如果你想更系统地理解 Marble 为什么强调结构与空间一致性，可以接着看这篇：

• Physics-Ready 3D 是怎么做出来的？Marble 空间一致性引擎详解

5. Transform、Scale、Pivot 或层级关系有偏移

有时候 mesh 本身没有明显问题，错的是导入后的空间关系。

典型表现：

• 本地空间里看 collider 对齐了，放进游戏里就偏
• prefab 父子层级一改，碰撞范围和视觉位置不再一致
• 不同 DCC 工具之间来回转一次后，scale 和 pivot 悄悄变了
• 同一模型在 Unity 和 Unreal 里的默认导入解释不同

这也是为什么很多“明明我已经加了 collider，为什么还是不对”的问题，最后追到的是缩放、pivot 或 transform 链路。

生产里最常见的 5 种 Ghost Collision 场景

场景 1：走廊地面看起来平，角色却总在某一点卡一下

这是 modular level kit 最常见的问题之一。

地板块视觉上是连续的，但底层 box collider 或 mesh collider 在边缘没有完全拼平。结果不是“完全走不过去”，而是每隔几米就顿一下，手感非常差。

这种问题尤其容易被低估，因为它在截图和录屏里看不明显，通常只有真正上手移动时才会暴露。

场景 2：球、车轮、箱子在看似平整的地面上轻微起跳

这类场景多见于：

• 车辆系统
• 球类或滚动物理
• 可推动箱体
• VR 中需要平滑滑动的物体

常见根因是碰撞表面里存在微小突起，或者 convex decomposition 之后形成了一连串不平滑的 hull 过渡。玩家看到的是平地，刚体感受到的却是一条坑坑洼洼的表面。

场景 3：门洞明明够宽，角色高速通过时总会蹭住一边

这通常不是角色 capsule 突然变胖了，而是门框 collider 比可见边框更宽，或者里面有多层重叠碰撞。

典型排查结果往往是：

• trim 看起来很薄，collider 实际很厚
• 某个隐藏 child mesh 还开着 collision
• 一侧 frame 和另一侧 frame 的边界不完全对称

场景 4：VR 手部交互总提前碰到空气

VR 比普通第三人称/第一人称更容易把 Ghost Collision 放大，因为手部交互对边界感知特别敏感。

只要碰撞体位置不准确，玩家就会立刻感觉到：

• 还没摸到物体就被挡住
• 左右两侧反馈不一致
• 某些表面能穿，某些表面不能穿

这类问题不一定来自引擎，而常常来自“为了性能做了简化碰撞，但简化后的位置和体积不合理”。

场景 5：AI 生成资产截图很好看，放进关卡就开始出问题

这是近一年越来越常见的情况。

AI 生成的 3D 资产可以非常适合展示，但展示效果好，并不代表它适合直接承担 traversal、射线检测、刚体交互或 VR 拿取。

一旦这些资产的 collider、拓扑、scale、pivot 还需要团队逐个补，Ghost Collision 就会在真正接入生产时集中爆发。

这也是为什么很多团队最后不是被某一次大 bug 拖垮，而是被每个资产都要多做一点排查的节奏拖慢；如果你想从成本角度理解这件事，可以继续看 独立开发者的隐形时间杀手：为什么 3D 资产后处理会吞掉 70% 开发时间？。

Unity 和 Unreal 都会遇到，但表面症状不完全一样

Unity 里常见的表现

Unity 里你经常会在这些地方遇到 Ghost Collision：

• Character Controller 经过 seam 时轻微卡顿
• Mesh Collider + Rigidbody 组合表现不稳定
• Auto-generated collider 贴得太细，保留了噪声
• Prefab 层级、缩放和 collider 组件没有同步

Unity 的问题往往会很快体现在“手感”上：你一跑、一跳、一滚，立刻就知道哪里不对。

如果你正在做更细的 Unity 排查，可以直接接着看：

• Unity AI 3D 模型穿模怎么修？一篇讲清 Collider、重心与 Physics-Ready 工作流

Unreal 里常见的表现

Unreal 也会有同样的问题，只是它更常表现为：

• Collision complexity 选择不当
• Auto Convex 结果太碎
• Imported collision mesh 与 visible mesh 不一致
• 模块化资产之间的边缘过渡不稳定
• 车辆、射线、角色移动在局部区域产生异常反馈

说到底，Unity 和 Unreal 的“表面症状”不同，但根因都一样：玩家看到的和物理引擎计算的，不是同一套表面。

传统修法为什么很贵，而且越到后期越痛

Ghost Collision 当然能修，但传统修法的问题是：大多发生在“问题已经进场景之后”。

修法 1：手工调每一个 Collider

这是最直接的方法，也是最容易吞时间的方法。

你可以一个个调整 box、capsule、mesh collider，让角色刚好能过、门刚好能进、地面刚好不卡。

问题是：

• 每个资产都要重新做一次
• 改了模型版本后可能还得重来
• 关卡一变，新的 seam 又会出现

修法 2：把 Mesh Collider 改成更简单的 Primitive

这招有时有效，尤其适合快速验证。

但代价是你经常会在“过于精确”和“过于粗糙”之间来回摆：

• 太简单，挡住可见空间
• 太复杂，又把噪声带回来了

它能救急，不代表它能成为长期可扩展的流程。

修法 3：继续调引擎物理参数

比如 contact offset、collision tolerance、角色胶囊大小、车辆悬挂或摩擦参数。

这些参数当然重要，但它们更像“放大器”，不是源头修复器。

如果底层资产结构已经不稳定，你只靠调参数，通常只能把问题推迟，而不是消灭。

修法 4：回源头重做网格

这是最彻底，但也是最贵的办法。

一旦你确定问题来自：

• topology 太脏
• hidden geometry 太多
• scale / pivot 链路混乱
• 导出结构本身不稳定

最后还是得回 DCC 工具里清网格、补结构、重做碰撞近似，再重新导入验证。

修法 5：在玩法层写特殊逻辑绕过去

有些团队会临时做这些补丁：

• 某段地面禁用碰撞
• 某个门框区域强行放宽判定
• 给个别物体单独写移动/吸附/滑动逻辑

短期看像是修好了，长期看其实是在把资产问题转嫁给代码层。

一旦项目规模变大，这种补丁会变成新的维护成本。

更好的方向：不要等空气墙出现了再补，而是尽量上游预防

真正更稳的做法，不是“接受 Ghost Collision 一定会发生”，而是尽量在资产进入引擎之前，把高风险问题前置处理掉。

这就是 Physics-Ready 工作流比传统“先生成再手修”更有价值的地方。

什么叫更接近 Physics-Ready

不是说模型从此绝不会出问题，而是说它在进入 Unity / Unreal 之前，已经更认真地处理这些方面：

• 结构完整性
• 拓扑稳定性
• 碰撞边界可用性
• 重心与空间一致性
• 导出与导入链路一致性

换句话说，它关注的不是“能不能生成一个像样的模型”，而是“这个模型是不是更适合直接进入真实生产流程”。

Marble 想减少的，不是截图问题，而是返工问题

Marble 的方向不是只追求 visual-ready，而是尽量把模型往 Physics-Ready 状态推进：

• 减少结构不稳定带来的后续返工
• 尽量把碰撞、空间和导入风险前置暴露
• 让资产更容易进入 Unity / Unreal 的实际验证流程
• 把团队从“每个模型都要手修一遍”的循环里拉出来

如果你更关注“后处理为什么会吞掉开发时间”，也可以继续看这篇：

• 独立开发者的隐形时间杀手：为什么 3D 资产后处理会吞掉 70% 开发时间？

团队实际可用的 4 条最佳实践

1. 对 traversal surface，优先追求稳定，不要盲目追求碰撞过细

地板、坡道、门洞、通道这些地方，优先级应该是“走起来稳”，不是“碰撞边界百分百贴图形”。

2. 对导入资产，先查隐藏几何、scale、pivot 和层级

很多空气墙问题最后都不是 collider 组件本身，而是资产结构在导入链路里悄悄偏掉了。

3. 对 AI 生成资产，不要把截图质量当成可用性证明

截图好看只证明它适合展示，不证明它已经适合互动、物理、导航和真实关卡。

4. 把 QA 放到“跑动、滚动、穿门、贴边”这些动作里，不要只看静态摆放

Ghost Collision 最怕的就是你只看场景截图，不真正进去跑一圈。

结论：空气墙通常不是一个点上的 bug，而是一条链路上的问题

如果你现在正在查 Ghost Collision，最重要的不是继续盲目调某一个参数，而是先接受一个现实：

Invisible wall 往往不是“引擎随机出错”，而是资产、碰撞、拓扑、导入和验证流程共同造成的结果。

也正因为如此，真正高杠杆的解法通常不是“多修一次”，而是把流程换成更接近 Physics-Ready 的资产工作流，让问题尽量不要进入生产场景再爆发。

如果你想自己试一个更接近真实工作流的模型，可以直接：

• 去生成入口试一个模型
• 如果你想先看方案与价格，可以看这里

Physics-Ready 3D 主题内矩阵

这篇文章属于同一组 Physics-Ready 3D 主题内容之一。这个主题簇围绕同一个核心问题展开：为什么 AI 生成的 3D 模型看起来已经完成，进入 Unity / Unreal 和真实生产流程后却还远远没到可用状态。你可以按自己当前卡住的环节继续往下读：

• 什么是 Physics-Ready 3D？为什么 AI 生成模型总卡在“最后一公里” — 如果你想先从总定义入手，先读这篇，建立“为什么好看不等于可用”的认知。
• Physics-Ready 3D 是怎么做出来的？Marble 空间一致性引擎详解 — 如果你想追到机制层，理解结构、空间一致性与碰撞验证为什么重要，接着读这篇。
• Unity AI 3D 模型穿模怎么修？一篇讲清 Collider、重心与 Physics-Ready 工作流 — 如果你现在主要卡在 Unity 的具体排查动作，回到这篇最直接。
• 独立开发者的隐形时间杀手：为什么 3D 资产后处理会吞掉 70% 开发时间？ — 如果你更关心返工成本、QA 时间和小团队效率，最后看这篇。