把 AI 生成的道路、坡道或桥梁模块导入 Unity、Unreal 后，车辆经过接缝时突然抬头、侧跳、短暂离地，甚至无故减速，并不一定是悬挂参数有问题。
更常见的原因是：相邻碰撞体之间存在缝隙或重叠，视觉网格与碰撞网格轮廓不一致，模块变换产生了边界误差，或者接缝两侧的碰撞几何与物理材质不连续。只有低速正常、高速异常时，才应把排查重点转向物理时间步和车轮检测方式。
最有效的做法不是先调车辆，而是固定路线和速度，找到车轮第一次出现异常接触的位置，再判断应该修道路、修碰撞，还是调整车辆检测。
路面看起来平，为什么车轮仍会被“绊一下”？
遇到车辆弹跳，很多人会先怀疑悬挂太硬、车轮半径不对，或者刚体质量不合理。但如果车辆每次都在同一个位置出问题，应优先检查道路模块。
常见现象可以分成三类：
- 固定位置弹跳：每次都发生在同一处接缝、桥头或坡道入口，优先检查碰撞体的缝隙、重叠和轮廓突变。
- 偶发弹跳：异常位置不完全固定，可能与穿透修正、时间步或动态物体之间的接触有关。
- 只有高速才弹跳：低速能够稳定通过，速度提高后才离地或侧跳，再检查物理子步、连续检测和车轮采样方式。
判断时要区分两个概念：视觉模型连续，不等于碰撞表面连续。前者只说明渲染出来的道路看起来接上了；后者才决定车轮能否获得稳定支撑。
图注：道路模块从白模到成品可以说明场景细化过程，但车辆能否平稳通过，仍要检查真实碰撞体和模块接缝。静态图不能证明路面碰撞连续、车辆物理正确、道路可驾驶或目标引擎性能达标。
第一处：相邻碰撞体之间有缝隙或重叠
这是最应该先检查的位置。
两个道路模块即使在画面中已经对齐，各自的碰撞体仍可能没有真正接上。一侧留下很窄的缝，会让车轮短暂失去支撑；两个碰撞体互相穿入，则可能形成一条看不见的凸边。
AI 生成模型通常优先保证整体形状和视觉效果，模块边缘未必按照可拼接资产的标准整理。自动生成碰撞体时，网格还可能被简化、收缩或重新分割，最终边界与可见路面产生细小偏差。
这类偏差未必能直接看见，却足以影响车辆。它就像两块看似铺平的地砖，其中一块边缘翘起几毫米：行人可能没有感觉，小轮径的购物车却会明显颠一下。
排查时可以这样做：
- 关闭复杂材质和后处理，打开引擎的碰撞可视化。
- 让车辆以低速沿固定轮迹通过接缝。
- 记录前轮第一次异常接触的位置、速度和接触方向。
- 分别隐藏接缝两侧的碰撞体，检查是否存在缝隙、重叠或凸边。
不要只看车身何时跳起来。车身产生明显反应时，前轮可能已经在几帧之前撞到了异常边界。
如果确认存在缝隙，可以重新整理碰撞网格，或给道路模块建立统一的拼接边界；如果问题来自重叠，应先修正模块位置和碰撞轮廓。单纯提高车辆离地间隙，只会暂时掩盖问题。
第二处：视觉网格与碰撞网格不是同一轮廓
用于显示的道路模型和用于物理计算的碰撞网格可以不同。为了降低运行成本，碰撞网格通常会更简单，但桥头、坡道入口和主路面等关键接触区域不能出现明显偏差。
常见问题包括：
- 视觉路面已经更新，碰撞体仍沿用旧版本；
- 自动凸包把平缓坡道简化成了短台阶；
- 桥面看起来连续，碰撞体却在连接处提前结束；
- 路缘或道路底部被错误纳入了可行驶碰撞面；
- 生成模型的高密度三角面直接用于碰撞，接缝附近产生了零碎小面。
可以用三步对照快速定位：
- 只显示视觉网格：确认路面本身没有明显台阶或破面。
- 只显示碰撞体：检查接触表面是否存在断层、尖角和额外凸起。
- 两者叠加显示：重点比较坡道起点、桥头、路缘和模块边界。
对于需要稳定驾驶的主路面，通常更适合使用专门整理过的低复杂度碰撞网格，而不是直接把生成模型的所有三角形都用于碰撞。目标不是让碰撞体与视觉网格逐点相同，而是让车辆真正接触的区域足够平顺、连续且成本可控。
第三处：缩放、父级变换与大坐标破坏了边界
有些道路模块在源文件中没有问题，放入大型场景后才出现异常。这时应检查对象变换和世界坐标。
未应用缩放、非均匀缩放以及多层父级变换，都会让碰撞网格的最终尺寸和位置更难判断。某些碰撞类型对非均匀缩放的支持也有限，导入或运行时重新生成物理数据后，结果可能与编辑器中的外观不完全一致。
如果场景距离世界原点很远，坐标数值变大，能够稳定表达的细小位置差异会减少。模块边界的微小误差因此更容易影响接触计算。长距离道路、超大城市和分区世界尤其需要注意这一点。
建议做一组原点对照：
- 把发生异常的两块道路复制到世界原点附近。
- 保持车辆、速度、碰撞和材质设置不变。
- 比较原位置与原点附近的通过结果。
- 记录模块的世界坐标、父级层级、旋转和缩放值。
如果原点附近稳定、原位置异常，应继续检查大坐标方案和父级变换；如果两处都在同一个接缝弹跳，问题更可能来自碰撞网格本身。
用于重复拼接的道路资产，最好在进入场景前就统一单位、尺寸、朝向、原点和缩放，避免依靠场景中的多层变换补偿模型问题。
第四处：碰撞几何与物理材质在边界突变
接缝位置已经对齐，车辆仍然突然改变方向、抓地力或回弹表现，就要继续检查接触方向和物理材质。
这里需要澄清一个容易混淆的点：画面平滑使用的渲染法线主要影响光照；车辆受到的支撑方向主要来自碰撞几何及物理系统计算出的接触法线。因此，道路看起来没有折线，不代表物理接触方向也一定平滑。
问题可能来自以下几种情况：
- 接缝两侧的碰撞三角形形成了细小折角；
- 某些三角形方向、退化面或狭长面导致接触方向不稳定；
- 两块道路使用不同的摩擦、弹性或组合规则；
- 一侧使用网格碰撞，另一侧使用盒体或凸包，边界形状不一致。
排查时，先让接缝两侧临时使用同一种物理材质，再分别进行低速和正常速度测试。如果异常明显减弱，应检查摩擦、弹性及其组合方式；如果结果没有变化，再查看碰撞三角形和接触点调试信息。
不要用提高摩擦力来解决几何凸边。摩擦参数只能改变接触后的运动结果，不能消除道路中真实存在的台阶。
第五处：高速、物理时间步与车轮检测不匹配
前四项没有发现明显异常，而且车辆只有在高速下才弹跳时，再检查物理更新频率和车轮检测。
车辆在相邻两个物理计算时刻之间移动过远，可能跨过很窄的接触区域。固定时间步过大、物理子步不足或高速碰撞检测设置不合适，也会放大问题。不同车辆方案使用的检测方式不同：有的通过射线估算车轮接地，有的使用形状投射或真实碰撞体，因此不能照搬同一组参数。
可以使用三档速度复测：
- 10 千米/小时：确认基础接触是否连续；
- 30 千米/小时：观察正常驾驶状态；
- 60 千米/小时：检查高速下是否出现漏检或穿透修正。
每档都记录首次离地帧、接触点、车轮状态和速度变化。如果更改时间步后，异常仍固定发生在同一位置，道路接缝依然是主要嫌疑；如果异常位置随速度、帧率或物理步长明显变化，才更值得检查车辆检测和物理更新频率。
需要注意的是，开启连续碰撞并不一定能解决所有车轮问题。它是否有效取决于车辆控制器和车轮接地的具体实现，因此必须以当前项目的实测结果为准。
最小复测：两块直路、一处坡道和一次导出回读
复杂城市场景包含大量模块、灯光和动态对象，不适合直接定位。可以先建立一个最小测试场景，只保留两块直路、一块坡道和一辆测试车。
按以下顺序执行：
- 低速通过两块直路的接缝。
- 以正常速度重复同一路线。
- 提高速度，再次经过同一接缝。
- 通过坡道入口，记录第一次异常接触。
- 每次只修改一个变量，然后重复三档速度测试。
- 导出道路资产，再导入一个干净场景进行回读测试。
建议记录这些字段：
build_version | road_module | world_position | scale collider_type | vehicle_speed | first_error_position contact_normal | physics_material | fixed_timestep | result
如果资产需要在 DCC 工具和引擎之间往返，可以使用 DCC 桥衔接资产流转。但它解决的是文件传递和制作流程，不会自动完成碰撞重建、接缝检查或车辆驾驶验收。
发布前检查这5项
车辆经过道路模块时弹跳，可以按下面的顺序排查：
- 碰撞体是否存在缝隙、重叠或凸边？
- 视觉网格与碰撞网格的关键接触轮廓是否一致？
- 模块是否存在未应用缩放、复杂父级变换或大坐标误差？
- 接缝两侧的碰撞几何和物理材质是否发生突变？
- 只有高速异常时，时间步、物理子步和车轮检测是否匹配？
AI 生成的道路、桥梁和城市模块可以快速提供场景基础，但“看起来已经接上”只是视觉结论。进入 Unity、Unreal 或其他实时环境后，碰撞轮廓、物理材质、对象变换和高速接地仍然需要单独验证。
先定位车轮第一次异常接触的位置，再做针对性修复，通常比反复调整悬挂、质量和车轮半径更快。
你的车辆更常在桥头、坡道入口，还是直路模块接缝处弹跳？
