RVO不是补救穿模而是从速度空间源头防止重叠；NavMeshAgent避障因后验修正导致高密度下必穿模，RVO通过前馈协同求解最优速度向量实现工程级抗重叠。
直接说结论：RVO不是用来“补救”穿模的，而是从速度空间源头掐断重叠发生的可能性；用NavMeshAgent原生Obstacle Avoidance在高密度下必穿模，换RVO是唯一可工程落地的方案。
RVO为什么比NavMeshAgent的局部避障更抗重叠
Unity原生NavMeshAgent的Obstacle Avoidance本质是“后验修正”：先按目标方向移动一帧 → 检测到距离过近 → 把速度往法线方向硬推 → 下一帧又可能推过头 → 位置抖动+高频微碰撞。单位越密，这种滞后修正越容易形成连锁震荡，最终表现为视觉上的“叠罗汉”或“鬼畜穿模”。
RVO是“前馈协同”：每个单位在每帧开始时，就基于自身position、velocity、radius和邻居的这三要素，在速度空间里求解一个“不撞人的最优速度向量”。它天然规避了“先动再判”的时间差，所有单位的速度调整是同步协商出来的。
关键差异点：
-
NavMeshAgent避障只看距离阈值（obstacleAvoidanceType、avoidancePriority），不建模相对运动 - RVO必须输入每个单位的
prefVelocity（理想速度）、maxSpeed、radius、timeHorizon，缺一不可 - RVO的
timeHorizon参数直接决定“预测多久后的碰撞”，设太小（如0.1）→ 只防眼前，拐角仍穿模；设太大（如5.0）→ 过度保守，队伍发散
C++ RVO2库集成时最容易漏掉的三件事
你编译通过了libRVO2.a，把RVOSimulator实例化了，但NPC还是挤成一团？大概率栽在这三个地方：
- 没调
addAgent()后立即设置setAgentPosition()和setAgentPrefVelocity()——RVO2内部用索引查表，初始化位置为空会导致后续所有速度计算基于(0,0)，结果就是全体原地乱晃 - 忘了每帧调
RVOSimulator::doStep()前，必须用setAgentPosition()刷新所有单位当前位置——否则RVO2还在用上一帧的位置算“相对速度”，预测完全失准 -
agent.radius设的是世界单位，但Unity里NPC的Collider半径常是0.3，而RVO2默认单位是米，若场景1单位=10米，你就得把radius设成3.0，否则障碍锥太窄，根本拦不住
如何让RVO2和Unity NavMesh共存不打架
别试图用RVO2替代全局寻路。正确分工是：NavMeshAgent.CalculatePath()给粗略路径点序列 → 把下一个路径点转成prefVelocity喂给RVO2 → RVO2输出本帧实际velocity → 用transform.Translate(velocity * Time.deltaTime)驱动位移（关掉NavMeshAgent.updatePosition）。
这样做的好处：
- NavMesh负责“去哪”，RVO2负责“怎么去而不撞”，职责清晰
- 避免
NavMeshAgent的updateRotation和RVO2的朝向控制冲突（RVO2不处理朝向，旋转得自己算） - 当RVO2因密度太高被迫大幅降速时，NavMesh的
remainingDistance仍准确，可触发“绕远路”逻辑
注意：NavMeshAgent的isStopped会因RVO2压制速度而频繁变true，不要用它判断是否到达，改用距离阈值判断。
静止单位（如主角/守卫NPC）怎么参与RVO避障
把主角加进RVO2模拟器，但设maxSpeed = 0、radius按实际模型大小设、timeHorizon = 0.1（只防贴脸）。最关键的是设avoidanceWeight = 0.01（RVO2源码里叫weight）——这个值越小，其他单位越倾向于“全责避让”，主角就真能稳如泰山站在原地被绕行。
实测踩坑点：
- 如果主角
radius设得太小（比如0.05），周围单位会认为“他几乎不存在”，直接穿身而过 - 如果
avoidanceWeight设为0，RVO2会跳过该单位的障碍锥计算，等于没注册 - 主角移动时，必须实时调
setAgentPosition()和setAgentPrefVelocity()，否则RVO2仍按静止模型计算，导致队友突然转向“追尾”
RVO的难点从来不在公式推导，而在所有单位的状态必须严格对齐——位置、速度、半径、权重，四者只要一个脱节，群体行为就会从“人流”退化成“果冻”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
