企业官网建设流程全解析

“空气墙”这个词，玩家不陌生：一面看不见的墙，明明前面是空旷场景，角色就是走不过去；反过来，有些模型看起来有一堵墙，角色却能从中间直接穿过去。这类“视觉与物理不一致”的问题，很大一部分不是策划故意恶心人，而是碰撞体没有生成好。今天我们做一次反向科普：不讨论怎么找空气墙、穿空气墙，而是讲怎么用工程手段“封堵空气墙”——把一个只有视觉 Mesh 的 3D 模型，自动拆成物理引擎能用的凸碰撞体集合，让该挡人的地方真正挡人。

文章会围绕开源凸分解工具 V-HACD 展开，给出一套“模型清理 -> 凸分解 -> 批量处理 -> 引擎验证”的完整流程，并附带命令行、Python 与 C++ 接口调用示例。如果你在做游戏关卡、数字孪生、机器人仿真或任意需要物理碰撞的 3D 项目，这篇文章可以直接收藏。整个方案的特点是：不依赖高端显卡，CPU 就能跑；支持批量处理；既可以用命令行一个个跑，也可以通过库接口集成到自己的工具链。

先从核心能力看起。

1. 核心能力速览

下面这张表把“封堵空气墙”这套碰撞体生成方案的关键能力梳理清楚。表中内容是基于通用实践整理的，不同版本的 V-HACD 工具、不同引擎的碰撞体导入方式会有差异，实际以你本地环境为准。

从上面这张表能看出，这个方案的门槛很低：不需要一张高性能显卡，普通多核 CPU 就能承担大部分凸分解计算。真正要花时间的地方不在运行环境，而在输入模型的清理和参数调优上。

2. 空气墙是怎么产生的，为什么要“封堵”

2.1 空气墙的三种常见来源

空气墙不是某种固定的程序组件，它是碰撞体配置和视觉表现不一致时，玩家体感上出现的“隐形边界”。常见来源有三种。

第一种，模型只有视觉 Mesh，没有碰撞体。美术做了一个完整的房间模型，墙壁、地板、门窗都有，但导入引擎时没有给模型生成碰撞体。角色走进房间，墙面看起来是实的，身体却直接穿过去，这是更严重的“穿模”，比空气墙更像空气。

第二种，碰撞体太粗糙。为了节省性能，开发人员用很粗的盒子碰撞体去近似复杂墙面。于是视觉上墙角有个窗洞，但碰撞体是一整面方盒子，角色走到窗前被一堵“看不见的墙”挡住。玩家看不到任何障碍物，却死活过不去，这就是最典型的空气墙。

第三种是碰撞体层级和 Transform 配置错误。碰撞体生成在相邻节点下，或者旋转、缩放和视觉 Mesh 对不上，导致一部分区域能穿模，另一部分区域被误挡。这种问题在手工摆放碰撞体的项目里非常常见。

2.2 为什么物理引擎不喜欢凹碰撞体

要理解“封堵空气墙”为什么要用凸分解，先要明白物理引擎的工作方式。大部分实时物理引擎处理碰撞检测时，对凸体的计算效率远高于凹体。凸体是指任意两点连线都落在物体内部的几何体，比如球体、盒子、圆柱体；凹体则包含内凹区域，比如 L 形墙体、带窗洞的室内空间。

对于凸体，物理引擎可以用比较成熟的算法做快速相交检测，稳定性也好。对于凹体，引擎要么退化成“把所有三角形都当独立碰撞面”，性能压力很大；要么用一个很大的包围盒近似，又会产生看不见的阻挡。更合理的做法是把一个凹的 Mesh 切割成若干个凸的 Mesh，让它们组合起来逼近原始模型。这个切割过程就是“凸分解”。

V-HACD 做的就是这件事：读入一个 OBJ 网格，通过体素化和递归拆分，得到一组凸包，然后把这些凸包组合起来作为碰撞体。这段逻辑如果靠人工在 DCC 软件里手动拆分，一个复杂建筑模型可能要拆几十上百块，非常低效；用工具批量生成，效率会高很多。

2.3 适用范围与边界

这套方案适合处理静态场景的物理阻挡：房间、走廊、地形、大型道具、扫描点云重建出的建筑外壳。只要模型是封闭或接近封闭的静态表面，都可以用它生成碰撞体。

但也要明确边界。碰撞体不等同于功能逻辑。门能不能打开、传送点能不能进入、NPC 能不能寻路，这些都需要额外的 Trigger、NavMesh、交互脚本来处理。V-HACD 只解决“物理上能不能穿过”这一件事。如果场景里有一个开着的门，凸分解可以保留门洞的通过空间，但门能不能被推开，不归碰撞体管。

另外，如果输入的是真实建筑扫描数据或未授权的第三方美术资产，要注意数据来源和版权。内部测试随便用，对外展示和商用之前，必须确认模型资产授权完整，涉及真实地点还要处理数据合规问题。

3. 环境准备与前置条件

3.1 工具清单

开始之前，先确认几条工具链。

V-HACD 的官方仓库通常提供源码，部分平台有预编译二进制。如果不确定当前版本支持哪些参数，优先看官方 README。

3.2 输入模型要求

输入模型建议使用 OBJ 格式，因为 V-HACD 最常见的输入格式就是 OBJ，且 OBJ 容易在 Blender 里清理和转换。

模型本身最好满足三个条件：

• 是封闭或接近封闭的表面，没有大面积破洞；
• 法线方向基本一致，不要内外面翻转混用；
• 单位统一，厘米还是米要提前定好，否则导入引擎后比例全乱。

如果模型面数特别高，比如超过了百万面，建议先用 Blender 的 Decimate 或 Quad Remesh 做减面。凸分解不需要高精度的视觉细节，只需要保留“能不能通过”的几何轮廓。面数越少，凸分解越快，生成的碰撞体越干净。

3.3 下载与编译 V-HACD

如果官方提供了预编译命令行工具，下载后直接使用即可。如果需要从源码编译，通用流程如下。

# 以源码方式构建 V-HACD，具体仓库地址和参数以官方 README 为准 git clone <官方仓库地址> cd v-hacd mkdir build cd build cmake .. cmake --build . --config Release

编译完成后，在 build 目录下通常能找到命令行程序。平台不同，可执行文件名可能不同，Windows 下可能是 TestVHACD.exe，Linux 下可能是 TestVHACD。下面所有命令都以这个程序名为例。

如果你不想从源码编译，也可以直接找已经编译好的二进制。但要注意版本差异：老版本和新版本命令行参数未必一样，拿到工具后先跑一次帮助命令，确认参数名再处理模型。

4. 安装部署与启动方式

4.1 命令行启动方式

拿到可执行文件后，先确认工具版本。

# 查看 V-HACD 命令行帮助，确认当前版本支持的参数 ./TestVHACD --help

然后就可以对单个模型做凸分解。下面是一个通用模板，实际参数名和输出方式请以当前版本帮助信息为准。

# 通用模板：把 scene.obj 转换成凸碰撞体集合 ./TestVHACD scene.obj --output ./convex_output --resolution 100000 --depth 20

这个命令的意图是：读取当前目录下的 scene.obj，用 100000 的体素分辨率、20 的递归深度做分解，把生成的凸包输出到 convex_output 目录。凸包数量、每个凸包的顶点数、精度受到这几个参数控制。

如果命令执行成功，输出目录里会看到多个 OBJ 文件，每个文件是一个凸包。理论上这些凸包合在一起，能近似原始模型的物理轮廓。

4.2 Python 批量启动

命令行工具一次只能处理一个模型。要做批量任务，写一个 Python 脚本遍历目录即可。下面这个脚本是一个典型的批量处理模板，请把 VHACD_CLI 换成你本地的可执行文件路径。

import subprocess from pathlib import Path # 按实际环境修改 VHACD_CLI = "./TestVHACD" input_dir = Path("./models") output_dir = Path("./convex_out") output_dir.mkdir(exist_ok=True) for obj_path in sorted(input_dir.glob("*.obj")): out_prefix = output_dir / obj_path.stem cmd = [VHACD_CLI, str(obj_path), "--output", str(out_prefix)] print(f"[INFO] processing {obj_path.name}") result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print(f"[ERROR] {obj_path.name}: {result.stderr}") else: print(f"[OK] {obj_path.name} -> {out_prefix}")

脚本逻辑很简单：遍历 models 目录下所有 OBJ，逐个调用命令行工具，成功打印 OK，失败打印错误信息。实际使用时，可以把输出参数改成你的 V-HACD 版本支持的格式。

这里有个重要提醒：不同版本 V-HACD 生成凸包的方式不一样，有的版本会输出多个文件，有的版本只返回一个组合结果。建议先用命令行处理一个模型，确认输出结构，再写批量脚本，避免日志里全是路径错误。

4.3 通过 Blender 做人工检查和清理

批量处理之前，最值得做的一步是在 Blender 里人工检查模型。因为凸分解对脏模型很不友好，一个内部有重叠面、法线混乱的 OBJ，生成出来的凸包可能把门洞封死，也可能把走廊压扁。

在 Blender 里可以快速做三件事：

• 开启“Face Orientation”显示，观察法线方向；
• 用“Select -> Select All by Trait -> Non Manifold”找出非流形边；
• 用 Decimate 修改器降低面数，保留大体轮廓。

清理完成后，再重新导出 OBJ 给 V-HACD 处理。这样能省掉后面大量排错时间。

4.4 导入 Unity 和 UE

凸分解生成的 OBJ 不是直接放在场景里当碰撞体，而是作为碰撞体数据导入引擎。

以 Unity 为例，可以把凸包 OBJ 导入工程，然后在原始视觉 Mesh 节点下挂空物体，把凸包 Mesh 作为 MeshCollider 并勾选 Convex。这样就不会在视觉 Mesh 上再创建默认碰撞体，避免一个物体挂两层碰撞。

以 UE 为例，可以在导入 FBX 或静态网格时设置碰撞体生成方式，选择 Convex Collision，或者把 V-HACD 生成的凸包合并进 Static Mesh 的 Collision 数据里。UE 的凸包数量会影响性能，导入后最好检查一下凸包数量，如果过多就重新调整分解参数。

5. 功能测试与效果验证

5.1 测试用例设计

部署完成之后，不要直接拿一个大场景测试。建议先准备四个标准化测试用例。

其中“带门洞的室内模型”是最能检验空气墙封堵效果的用例。如果凸分解把门洞也封住了，说明原始模型的拓扑或者分解精度有问题；如果角色还是能穿墙，说明碰撞体没有正确接入。

5.2 操作步骤：Unity 下验证

下面以 Unity 为例，给出一套验证步骤，其他引擎可对应照搬。

第一步，用 V-HACD 处理一个带门洞的 OBJ 房间，得到凸包集合。

第二步，把凸包 OBJ 导入 Unity，材质可以随便给一个半透明材质，方便观察碰撞体位置。

第三步，把凸包物体全部设为原始房间模型的子物体，并确保它们使用 MeshCollider 且勾选 Convex。

第四步，创建一个最简单的角色控制器或者胶囊体，在 Play Mode 下控制它走向墙壁和门洞。

第五步，观察行为：走近墙壁会被阻挡，走近门洞能正常通过，角色不会卡在门框边缘剧烈抖动。

这个流程看起来很直接，但实际操作中，大多数人失败在第三步：凸包物体没有对齐原始 Mesh 的坐标。因为 V-HACD 输入的 OBJ 是否经过单位转换、原点重置，直接影响导入后的位置。建议生成凸包前，先在 Blender 里把模型原点重置到世界原点，再导出。

5.3 判断成功与失败的标准

一个“封堵空气墙”的结果是否合格，可以从三个维度判断。

第一个维度是物理正确性：不该通过的地方全部阻挡，该通过的地方不被误挡。这是最核心的指标。

第二个维度是稳定性：角色贴着碰撞体移动时，不会被弹飞、穿模或卡进凸包缝隙。如果出现抖动，往往是凸包之间的缝隙过大，需要提高分辨率或者增加凸包数量。

第三个维度是性能友好：碰撞体总数不能爆炸。一个复杂建筑拆出 200 个凸包可以接受，一个简单椅子拆出 200 个凸包就不合理。此时应调低递归深度或限制最大凸包数。

失败时先别怀疑物理引擎，优先检查输入模型。超过一半的凸分解失败案例，根源都是 OBJ 模型存在非流形边、反向法线或内部重叠面。

6. 接口 API 与批量任务

6.1 C++ 库接口调用

除了命令行工具，V-HACD 本身以库的形式提供 C++ 接口。如果你要把凸分解集成到自研工具、资产管道或编辑器插件里，可以直接用库接口，避免频繁启动外部进程。

下面是一个通用调用示例，实际类型和函数名以你的版本头文件为准。

#include "VHACD.h" // 准备三角网格数据 VHACD::IVHACD::ConvexHull verticesData; // 这里的 points 和 triangles 需要从 OBJ 或其他 Mesh 格式中解析出来 // 创建 V-HACD 实例 VHACD::IVHACD* vhacd = VHACD::CreateVHACD(); VHACD::IVHACD::Parameters params; params.m_resolution = 100000; params.m_depth = 20; bool ok = vhacd->Compute(points.data(), points.size(), triangles.data(), triangles.size(), params); if (ok) { size_t nHulls = vhacd->GetNConvexHulls(); // 遍历 nHulls，读取每个凸包的点、面数据 } vhacd->Clean(); vhacd->Release();

这段代码的核心思路是：把 Mesh 的点数组和三角形索引数组传给 Compute 接口，计算完成后再从实例里取出凸包数据。如果你的项目已经在读取 OBJ 或者 glTF，可以很自然地把这段逻辑嵌入现有工具链。

有一点要注意：库接口的参数非常多，常见的有分辨率、递归深度、最大凸包顶点数、最小处理体积、凹度阈值等。不要一上来就调满精度，先用默认参数跑通流程，再根据结果做针对性调整。

6.2 批量任务与日志设计

批量处理不是简单地把脚本循环跑一遍。面对几百个模型时，最关键的是日志和断点续跑。

建议每次批量任务生成一份 manifest 记录文件。

{ "model_file": "./models/room_01.obj", "status": "ok", "convex_hulls": 12, "elapsed_seconds": 4.2, "error": "" }

脚本每处理完一个模型，就把这条记录追加写入一个 JSON 文件。处理失败时，status 字段写 failed，error 字段记录错误信息。下一轮批量任务开始前，先读取 manifest，过滤掉已经成功的模型，只处理失败列表。

这套设计成本很低，但在模型数量和参数迭代多了以后非常有用。否则每个模型重新跑一遍，浪费的时间会非常可观。

6.3 接入自动化资产管线

更进阶的做法是把凸分解放进资产导入流程。项目经理或美术提交一个新的 OBJ 到指定目录，CI 任务检测到文件变化后，自动执行“OBJ 清理 -> V-HACD 凸分解 -> 导出碰撞体 -> 导入引擎预览”这一串流程。

这个思路对游戏关卡和数字孪生尤其合适。因为这类项目里的模型经常更新，每次更新都手工生成碰撞体，很容易遗漏。把 V-HACD 接到 CI/CD 里以后，碰撞体会跟着模型版本自动更新，空气墙问题会少很多。

需要注意，自动化管线里要保留人去复核的空间。凸分解是几何近似，不是语义理解，它不会知道哪个洞是门、哪个洞设计上就不允许通过。

7. 资源占用与性能观察

7.1 CPU 与内存观察

V-HACD 的凸分解是计算密集任务。模型面数不高时，单个模型可能几秒内就完成；面数达到百万级别时，耗时可能上涨到几分钟甚至更久。主要消耗在体素化、递归拆解和凸包拟合三个阶段。

批处理时，建议打开系统任务管理器或资源监视器观察两个指标：CPU 使用率是否打满，内存占用是否持续上涨。如果同时并行处理多个模型，内存会叠加，容易在大型场景上把机器拖垮。更稳妥的做法是串行处理，或者限制同时运行的进程数量。

7.2 显存占用

这个方案的主要流程在 CPU 上完成，不依赖显卡运算，所以 CPU 模式下没有显存占用。如果你使用的是 GPU 加速的 V-HACD 变体，显存占用会取决于模型复杂度和体素分辨率，这一点需要按实际版本测试，不要盲目相信网上的某个数值。

7.3 参数对性能的影响

V-HACD 里有几组参数对性能影响最大，值得单独说明。

分辨率（resolution）控制体素化的精细程度。分辨率越高，凸包越贴合模型，但计算量也越大。递归深度（depth）控制拆分的层数，深度越大，凸包数量可能越多，每个凸包更小更贴合。最大凸包顶点数（maxNumVerticesPerCH）控制单个凸包的复杂度，越小越利于物理引擎处理，但数量会增多。

如果发现处理时间太长，优先降低分辨率，而不是降低深度。大多数场景下，50 万体素已经能提供不错的碰撞体轮廓。如果发现碰撞体缝隙太大，再逐步提高分辨率。

7.4 降低运行成本的实践

实际项目中没有必要对每个模型都用同样参数凸分解。简单物体用低分辨率快速跑，复杂建筑用高分辨率慢慢跑。也可以把大场景拆成若干区块，分块生成碰撞体，最后在引擎里组合。这样既能控制单次处理时间，也方便定位哪个区块的空气墙问题。

8. 常见问题与排查方法

下面是这套碰撞体生成方案里出现频率较高的八类问题，以及对应的排查方向。

如果你在生成结果里发现“某些地方看起来很空，角色却走不过去”，先怀疑碰撞体太粗糙；如果你发现“某个地方有墙，角色却能穿过去”，先怀疑碰撞体漏挂或者 Transform 没有对齐。这两种方向完全不同，排查路径也不一样。

9. 最佳实践与使用建议

9.1 视觉 Mesh 和碰撞 Mesh 分开管理

不要为了省事把凸包直接用来做渲染。凸包是近似形状，渲染它会降低视觉效果。在引擎里，建议把视觉 Mesh 和碰撞 Mesh 分开保存，视觉层负责观感，碰撞层负责物理阻挡。这样后续迭代时，美术改视觉模型，碰撞体可以按需重新生成。

9.2 建立三套参数模板

同一个项目的不同模型，物理精度需求差异很大。你可以把参数分成三档。

每次批量处理前先按模型类型套用对应参数模板，而不是所有模型共用一组参数。

9.3 批量任务要留下错误现场

批量任务跑完，除了记录成功结果，更要保留失败现场。建议把失败模型单独复制到 failed 目录，连同原始 OBJ、日志、脚本参数一起保存。这样排查问题时，不需要再找美术或资产库重新导出一份文件。

9.4 接口服务与资源限制

如果你把 V-HACD 封装成了内部接口服务，一定要设置并发限制。凸分解是 CPU 密集型任务，一个并发请求就能吃满一个核心，并发拉满会拖垮同一台机器上的其他服务。建议用简单的任务队列串行或者限制并发数，同时为每个请求设置超时时间。

9.5 数据合规与安全边界

如果处理的模型来自真实场地扫描、建筑图纸或第三方内容，要确认获取渠道合法。扫描真实环境时，注意规避敏感区域和个人隐私。在做数字孪生或 VR 安全场景时，碰撞体生成结果不能代替真实世界的安全检查，涉及人身安全的边界判断必须有人工复核和真实环境验证。

10. 总结与下一步

这套“封堵空气墙”方案最值得尝试的地方是：它把原本需要手动拆分碰撞体的工作变成了自动批量处理，而且不挑显卡，普通 CPU 机器就能跑。先别管多复杂的场景，拿一个带门洞的室内模型走一遍全流程，你会很快理解凸分解的价值。

最容易踩的坑是原始模型太脏。模型不封闭、法线混乱、单位不统一，后面所有步骤都会跟着出问题。所以第一次试验时，务必在 Blender 里做一遍清理，再交给 V-HACD。

下一步可以考虑三件事：把凸分解接入资产导入流程，形成“模型更新 -> 碰撞体重生”的自动化链路；对比不同分辨率参数下的凸包数量和贴合度，建立项目自己的参数模板；如果你的场景足够大，再评估 GPU 加速版本提升批量处理效率。先把第一条链路跑通，空气墙问题基本就能从项目里根治了。建议收藏备用，下次处理碰撞体问题时直接按这篇流程走。