# Navisworks 插件 GPU 加速可行性研究

## 1. 研究背景与目标

### 1.1 背景

NavisworksTransport 插件当前实现了基于 A* 算法的路径规划和碰撞检测功能。随着模型规模的增长和实时性要求的提高，需要评估 GPU 加速技术在本项目中的可行性和必要性。

### 1.2 研究目标

- 调研 Navisworks API 是否提供 GPU 加速能力
- 评估第三方 .NET GPU 计算库的适用性
- 分析项目中哪些模块可以从 GPU 加速中受益
- 给出实施建议和优先级排序

### 1.3 当前性能瓶颈

根据现有代码分析，主要性能瓶颈包括：

1. **网格地图生成**（GridMapGenerator）
   - BIM 模型几何扫描
   - 障碍物边界膨胀算法
   - 高度层识别和合并

2. **A* 路径规划**（AutoPathFinder）
   - 3D 图构建（多层网格连接）
   - A* 搜索算法执行
   - 路径后处理优化

3. **碰撞检测**（ClashDetectiveIntegration）
   - 动画过程中的实时碰撞检测
   - 多对象间的碰撞测试

## 2. Navisworks API GPU 能力调研

### 2.1 调研方法

- 网络搜索：Navisworks API 官方文档、开发者社区
- 本地文档：检索 Navisworks 2026 .NET API 文档
- 关键词：GPU、hardware acceleration、parallel、multi-thread、compute shader

### 2.2 调研结果

#### 2.2.1 Navisworks API 线程模型

根据 Autodesk 官方论坛的讨论：

> "Navisworks C# API is basically, as far as I understand, single-threaded/not thread safe"

**结论**：Navisworks .NET API 是**单线程的**，不支持多线程并发访问。

#### 2.2.2 硬件加速支持情况

Navisworks 支持通过用户界面启用硬件加速：

- **位置**：Interface > Display > Hardware Acceleration
- **用途**：仅用于图形渲染加速
- **限制**：不是 API 层面的计算加速，插件无法直接调用

#### 2.2.3 GPU 系统要求

Navisworks 2026 的 GPU 要求：

- **基本要求**：2 GB GPU，29 GB/s 带宽，DirectX 11 兼容
- **推荐配置**：8 GB GPU，106 GB/s 带宽，DirectX 12 兼容

#### 2.2.4 API 文档搜索结果

在本地 Navisworks API 文档中搜索以下关键词：

```bash
GPU|hardware.*acceleration|parallel|multi.*thread|compute.*shader
```

**结果**：未找到任何相关 API 文档。

### 2.3 结论

**Navisworks API 本身不提供 GPU 加速接口**。所有 GPU 相关的功能仅限于内部渲染引擎，不对插件开发者开放。

## 3. 第三方 .NET GPU 计算库

### 3.1 可用方案概览

虽然 Navisworks API 不提供 GPU 接口，但可以通过集成第三方 .NET GPU 计算库来实现 GPU 加速。

### 3.2 ILGPU（推荐）

#### 基本信息

- **官网**：https://ilgpu.net/
- **许可证**：MIT License
- **支持平台**：.NET Framework 4.8, .NET Core, .NET 5+

#### 主要特点

1. **多厂商支持**
   - NVIDIA CUDA
   - AMD ROCm
   - Intel 集成显卡
   - CPU 回退模式（无 GPU 时自动使用 CPU）

2. **C# 原生编程**
   ```csharp
   // 示例：GPU 并行计算
   var accelerator = new CudaAccelerator(new CudaAcceleratorId(0));
   var kernel = accelerator.LoadAutoGroupedStreamKernel<Index1, ArrayView<int>>(MyKernel);

   static void MyKernel(Index1 index, ArrayView<int> data)
   {
       data[index] = index * 2; // GPU 上执行
   }
   ```

3. **高层抽象**
   - 无需编写 CUDA C++ 代码
   - 自动内存管理
   - 类型安全

4. **性能**
   - 接近手写 CUDA 的性能（90-95%）
   - 支持 Shared Memory、Atomic 操作
   - 内置性能分析工具

#### 适用场景

- ✅ 大规模并行计算（数组操作、矩阵运算）
- ✅ 需要跨 GPU 厂商支持的项目
- ✅ 希望纯 C# 开发的团队

### 3.3 ManagedCUDA

#### 基本信息

- **GitHub**：https://github.com/kunzmi/managedCuda
- **许可证**：LGPL / 商业许可
- **支持平台**：.NET Framework, .NET Core

#### 主要特点

1. **CUDA 工具包的 .NET 包装器**
   - 直接映射 CUDA C API
   - 完整的 CUDA 功能访问
   - 需要安装 NVIDIA CUDA Toolkit

2. **性能**
   - 接近原生 CUDA 性能（98-100%）
   - 直接控制内存分配和传输
   - 支持 CUDA Streams、Events

3. **限制**
   - **仅支持 NVIDIA GPU**
   - 学习曲线较陡（需要理解 CUDA 编程模型）
   - 需要手动管理内存和资源

#### 适用场景

- ✅ 仅面向 NVIDIA GPU 用户
- ✅ 需要最大化 GPU 性能
- ✅ 团队有 CUDA 编程经验

### 3.4 DirectCompute

#### 基本信息

- **提供商**：Microsoft
- **API**：DirectX 11/12 Compute Shader
- **支持平台**：Windows

#### 主要特点

1. **跨厂商支持**
   - 所有支持 DirectX 11+ 的 GPU
   - 与图形管线集成

2. **限制**
   - .NET 集成复杂（需要 P/Invoke 或 SharpDX）
   - 需要编写 HLSL Compute Shader
   - 文档和社区支持相对较少

#### 适用场景

- ⚠️ 需要与 DirectX 图形深度集成
- ⚠️ 不推荐作为首选方案（开发复杂度高）

### 3.5 方案对比

| 特性 | ILGPU | ManagedCUDA | DirectCompute |
|------|-------|-------------|---------------|
| **GPU 支持** | NVIDIA + AMD + Intel | 仅 NVIDIA | 所有 DX11+ GPU |
| **开发语言** | 纯 C# | C# + CUDA C | C# + HLSL |
| **学习曲线** | 低-中 | 中-高 | 高 |
| **性能** | 90-95% | 98-100% | 85-95% |
| **社区支持** | 活跃 | 中等 | 较少 |
| **推荐度** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |

**推荐**：对于 NavisworksTransport 项目，**ILGPU 是最佳选择**，原因：

1. 跨厂商支持（用户可能使用 AMD 或 Intel GPU）
2. 纯 C# 开发，与现有代码库一致
3. 降低技术门槛，易于团队掌握
4. CPU 回退模式，无 GPU 时仍可运行

## 4. 应用场景分析

### 4.1 方案 A：A* 路径规划 GPU 加速

#### 4.1.1 数据流设计

```
┌─────────────────────┐
│ Navisworks API      │
│ 提取 BIM 模型数据   │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ GridMapGenerator    │
│ 生成网格地图 (CPU)  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ 数据传输到 GPU      │
│ - 网格数据          │
│ - 障碍物信息        │
│ - 起终点列表        │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ GPU Kernel          │
│ 并行 A* 搜索        │
│ - 多起终点同时计算  │
│ - 共享网格数据      │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ 结果传回 CPU        │
│ - 路径点列表        │
│ - 路径成本          │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ PathOptimizer       │
│ 路径后处理 (CPU)    │
└─────────────────────┘
```

#### 4.1.2 关键技术点

1. **网格数据结构 GPU 化**
   ```csharp
   // CPU 端（当前）
   public class GridCell
   {
       public List<HeightLayer> HeightLayers { get; set; }
       public bool IsInChannel { get; set; }
       // ...
   }

   // GPU 端（需要转换为平面数组）
   struct GPUGridCell
   {
       public int LayerCount;
       public int LayerStartIndex; // 指向 HeightLayer 数组的索引
       public bool IsInChannel;
   }

   struct GPUHeightLayer
   {
       public float Z;
       public float MinPassableZ;
       public float MaxPassableZ;
       public bool IsWalkable;
       public float SpeedLimit;
   }
   ```

2. **并行 A* 算法实现**
   - 每个 GPU 线程处理一个起终点对
   - 使用 GPU Shared Memory 存储 Open/Close 集合
   - 需要处理原子操作（更新最优路径）

3. **数据传输优化**
   - 使用 Pinned Memory 减少传输延迟
   - 批量处理多个路径请求
   - 缓存不变的网格数据

#### 4.1.3 适用场景判断

**适合 GPU 加速的情况**：

- ✅ 网格规模 > 100m × 100m（> 40,000 单元格）
- ✅ 同时计算 10+ 条路径
- ✅ 实时路径重规划（动态障碍物）
- ✅ 多楼层复杂场景（3D 图节点数 > 100,000）

**不适合 GPU 加速的情况**：

- ❌ 小规模网格 < 50m × 50m（< 10,000 单元格）
- ❌ 单次路径计算
- ❌ 简单平面场景（2D A*）
- ❌ 数据传输时间 > 计算时间

#### 4.1.4 性能预估

假设场景：100m × 100m 网格，0.5m 单元格，3 层楼

| 指标 | CPU (RoyT.AStar) | GPU (ILGPU 估算) | 加速比 |
|------|------------------|------------------|--------|
| 单次路径 | 50-100 ms | 80-120 ms | **0.6-0.8×** ❌ |
| 10 条路径 | 500-1000 ms | 100-150 ms | **5-8×** ✅ |
| 100 条路径 | 5-10 秒 | 300-500 ms | **15-25×** ✅ |

**结论**：仅在批量路径计算时才有显著收益。

### 4.2 方案 B：碰撞检测 GPU 加速

#### 4.2.1 数据流设计

```
┌─────────────────────┐
│ Navisworks API      │
│ 提取模型几何        │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ GeometryExtractor   │
│ 获取 BoundingBox    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ 数据传输到 GPU      │
│ - 对象包围盒        │
│ - 对象位置/旋转     │
│ - 碰撞检测对列表    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ GPU Kernel          │
│ 并行碰撞检测        │
│ - AABB 相交测试     │
│ - OBB 相交测试      │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ 结果传回 CPU        │
│ - 碰撞对列表        │
│ - 碰撞时间戳        │
└─────────────────────┘
```

#### 4.2.2 关键技术点

1. **包围盒数据结构**
   ```csharp
   struct GPUAABB
   {
       public Vector3 Min;
       public Vector3 Max;
   }

   struct GPUCollisionPair
   {
       public int ObjectA;
       public int ObjectB;
       public bool IsColliding;
       public float PenetrationDepth;
   }
   ```

2. **并行碰撞检测算法**
   - 每个 GPU 线程处理一对对象
   - N 个对象 = N×(N-1)/2 个线程
   - 使用空间分区（Grid-based）减少检测对数

3. **动画过程集成**
   - 每帧更新对象位置到 GPU
   - 实时返回碰撞结果
   - 与 Navisworks TimeLiner 同步

#### 4.2.3 适用场景判断

**适合 GPU 加速的情况**：

- ✅ 对象数量 > 100
- ✅ 实时动画碰撞检测（30+ FPS）
- ✅ 动态场景（频繁更新位置）
- ✅ 全对全检测（N² 复杂度）

**不适合 GPU 加速的情况**：

- ❌ 对象数量 < 50
- ❌ 静态场景（预计算即可）
- ❌ 已有空间索引优化（如八叉树）

#### 4.2.4 性能预估

假设场景：200 个动态物体

| 指标 | CPU (Navisworks API) | GPU (ILGPU 估算) | 加速比 |
|------|----------------------|------------------|--------|
| 单帧碰撞检测 | 50-100 ms | 5-10 ms | **8-15×** ✅ |
| 30 FPS 动画 | 无法实时 | 实时 | **显著改善** ✅ |

**结论**：碰撞检测是最适合 GPU 加速的场景。

## 5. 实施评估

### 5.1 工作量估算

| 任务 | 工作量 | 复杂度 | 依赖 |
|------|--------|--------|------|
| ILGPU 库集成与环境搭建 | 1-2 天 | 低 | - |
| 网格数据结构 GPU 化 | 2-3 天 | 中 | GridMapGenerator |
| GPU A* 内核实现 | 5-7 天 | 高 | 并行算法设计 |
| GPU 碰撞检测内核实现 | 3-5 天 | 中-高 | GeometryExtractor |
| CPU-GPU 数据传输优化 | 2-3 天 | 中 | 内存管理 |
| 性能测试与调优 | 3-5 天 | 中 | 测试场景 |
| 错误处理与回退机制 | 2-3 天 | 中 | 异常处理 |
| **总计** | **18-28 天** | **高** | - |

### 5.2 技术风险

1. **GPU 内存限制**
   - 风险：大规模网格数据可能超出 GPU 显存
   - 缓解：分块处理、数据压缩

2. **用户硬件支持**
   - 风险：部分用户无独立 GPU
   - 缓解：ILGPU CPU 回退模式

3. **数据传输开销**
   - 风险：频繁传输抵消 GPU 加速收益
   - 缓解：数据缓存、批量处理

4. **Navisworks API 线程安全**
   - 风险：GPU 计算结果需要回 UI 线程
   - 缓解：使用 Dispatcher.Invoke

### 5.3 维护成本

- **代码复杂度增加**：需要维护 CPU 和 GPU 两套代码路径
- **测试覆盖**：需要覆盖不同 GPU 厂商和型号
- **用户支持**：增加 GPU 驱动相关的技术支持成本

## 6. 优化建议与优先级

### 6.1 当前项目性能分析

基于现有代码分析：

- **网格生成**：50-200 ms（取决于模型规模）
- **A* 搜索**：20-100 ms（单次路径）
- **路径优化**：10-30 ms
- **总耗时**：80-330 ms

**主要瓶颈**：网格生成（BIM 几何扫描），而非 A* 搜索。

### 6.2 优化优先级排序

#### 🔥 第一优先级：CPU 层面优化（高投入产出比）

**1. 网格生成优化**

```csharp
// 当前实现：逐个网格扫描
for (int x = 0; x < gridMap.Width; x++)
{
    for (int y = 0; y < gridMap.Height; y++)
    {
        // 扫描所有模型元素
        foreach (var item in allItems)
        {
            if (Intersects(x, y, item)) { ... }
        }
    }
}

// 优化方案：空间索引（八叉树/R-树）
var spatialIndex = BuildRTree(allItems); // 预处理一次
for (int x = 0; x < gridMap.Width; x++)
{
    for (int y = 0; y < gridMap.Height; y++)
    {
        var nearbyItems = spatialIndex.Query(gridCell); // O(log n)
        // 仅检查附近元素
    }
}
```

**预期收益**：网格生成速度提升 **5-10×**

**工作量**：3-5 天

---

**2. A* 启发式函数优化**

```csharp
// 当前：简单欧几里得距离
public float Heuristic(Position a, Position b)
{
    return Vector3.Distance(a, b);
}

// 优化：考虑高度变化成本
public float Heuristic(Position a, Position b)
{
    float horizontalDist = Vector2.Distance(a.XY, b.XY);
    float verticalDist = Math.Abs(a.Z - b.Z);
    // 垂直移动成本更高（楼梯/电梯）
    return horizontalDist + verticalDist * 2.0f;
}
```

**预期收益**：搜索节点数减少 **20-40%**

**工作量**：1-2 天

---

**3. 路径缓存机制**

```csharp
// 缓存常用路径
public class PathCache
{
    private Dictionary<(Point3D, Point3D), List<PathPoint>> cache;

    public List<PathPoint> GetPath(Point3D start, Point3D end)
    {
        var key = (start, end);
        if (cache.ContainsKey(key))
        {
            return cache[key]; // 命中缓存
        }

        var path = ComputePath(start, end);
        cache[key] = path;
        return path;
    }
}
```

**预期收益**：重复路径计算速度提升 **100×**

**工作量**：2-3 天

---

**4. CPU 多线程优化**

```csharp
// 网格生成并行化
Parallel.For(0, gridMap.Height, y =>
{
    for (int x = 0; x < gridMap.Width; x++)
    {
        ProcessGridCell(x, y);
    }
});

// 多路径并行计算
var paths = Parallel.ForEach(pathRequests, request =>
{
    return ComputePath(request.Start, request.End);
});
```

**预期收益**：网格生成和多路径计算速度提升 **2-4×**（取决于 CPU 核心数）

**工作量**：3-5 天

**注意**：需要处理 Navisworks API 线程安全问题（数据提取在主线程，计算在工作线程）

---

#### ⚠️ 第二优先级：数据结构与缓存优化（中投入产出比）

**1. 网格数据结构优化**

```csharp
// 当前：List<HeightLayer>（动态分配）
public class GridCell
{
    public List<HeightLayer> HeightLayers { get; set; } // 堆分配
}

// 优化：固定大小数组或栈分配
public struct GridCell
{
    public const int MaxLayers = 8;
    public HeightLayer Layer0, Layer1, ..., Layer7; // 栈分配
    public int LayerCount;
}
```

**预期收益**：内存分配减少 **50-80%**，GC 压力降低

**工作量**：5-7 天（涉及大量代码修改）

---

**2. 增量式网格更新**

```csharp
// 当前：每次全量重建网格
public void UpdateGrid()
{
    gridMap = new GridMap(); // 全量重建
    GenerateFromBIM(...);
}

// 优化：仅更新变化区域
public void UpdateGrid(IEnumerable<ModelItem> changedItems)
{
    foreach (var item in changedItems)
    {
        var affectedCells = GetAffectedCells(item);
        foreach (var cell in affectedCells)
        {
            RegenerateCell(cell); // 局部更新
        }
    }
}
```

**预期收益**：动态场景更新速度提升 **10-50×**

**工作量**：4-6 天

---

#### 🚀 第三优先级：GPU 加速（高投入，场景受限）

**实施条件**（必须同时满足）：

1. ✅ 已完成 CPU 层面所有优化
2. ✅ CPU 优化后仍存在性能瓶颈
3. ✅ 存在批量计算需求（多路径/多碰撞）
4. ✅ 目标用户群体有独立 GPU
5. ✅ 团队有足够的开发和维护资源

**推荐实施顺序**：

1. **先实施**：碰撞检测 GPU 加速（收益最明显）
2. **后实施**：A* 路径规划 GPU 加速（仅在批量场景）

**工作量**：18-28 天

---

### 6.3 综合建议

#### 短期（1-2 周）

1. ✅ 实施空间索引优化（R-树/八叉树）
2. ✅ 实施路径缓存机制
3. ✅ 优化 A* 启发式函数

**预期效果**：整体性能提升 **3-5×**，工作量 **6-10 天**

#### 中期（1-2 月）

1. ✅ CPU 多线程优化（网格生成、多路径计算）
2. ✅ 数据结构优化（减少堆分配）
3. ✅ 增量式网格更新

**预期效果**：再提升 **2-3×**，工作量 **12-18 天**

#### 长期（3-6 月）

1. ⚠️ **评估是否需要 GPU 加速**
   - 如果 CPU 优化后仍不满足需求 → 实施碰撞检测 GPU 加速
   - 如果存在大批量路径计算需求 → 实施 A* GPU 加速

2. ⚠️ **GPU 加速实施**
   - 优先：碰撞检测（工作量 8-12 天）
   - 次要：A* 路径规划（工作量 10-16 天）

**预期效果**：特定场景下再提升 **5-15×**，工作量 **18-28 天**

---

### 6.4 投入产出比对比

| 优化方向 | 工作量 | 复杂度 | 性能提升 | 通用性 | 投入产出比 |
|---------|--------|--------|---------|--------|------------|
| 空间索引 | 3-5 天 | 中 | 5-10× | 高 | ⭐⭐⭐⭐⭐ |
| 路径缓存 | 2-3 天 | 低 | 100× (重复路径) | 高 | ⭐⭐⭐⭐⭐ |
| 启发式优化 | 1-2 天 | 低 | 1.2-1.5× | 高 | ⭐⭐⭐⭐ |
| CPU 多线程 | 3-5 天 | 中-高 | 2-4× | 中 | ⭐⭐⭐⭐ |
| 数据结构优化 | 5-7 天 | 高 | 1.2-1.5× | 高 | ⭐⭐⭐ |
| 增量更新 | 4-6 天 | 高 | 10-50× (动态场景) | 中 | ⭐⭐⭐ |
| GPU 碰撞检测 | 8-12 天 | 高 | 8-15× | 低 | ⭐⭐ |
| GPU A* | 10-16 天 | 极高 | 5-25× (批量) | 极低 | ⭐ |

---

## 7. 技术选型建议

### 7.1 如果决定实施 GPU 加速

**推荐技术栈**：

- **GPU 计算库**：ILGPU（跨厂商支持，纯 C# 开发）
- **首选场景**：碰撞检测（收益最明显）
- **次选场景**：A* 路径规划（仅在批量计算时）

**架构设计**：

```
┌─────────────────────────────────────────┐
│ NavisworksTransport 插件                │
├─────────────────────────────────────────┤
│ ┌─────────────┐     ┌─────────────┐    │
│ │ CPU Path    │     │ GPU Path    │    │
│ │ (默认)      │ ←→  │ (可选)      │    │
│ └─────────────┘     └─────────────┘    │
│         ↑                   ↑           │
│         └───────┬───────────┘           │
│                 ↓                       │
│         ┌─────────────┐                 │
│         │ Accelerator │                 │
│         │  Selector   │                 │
│         └─────────────┘                 │
│                 ↓                       │
│         检测 GPU 可用性                 │
│         - 有 GPU → GPU Path             │
│         - 无 GPU → CPU Path (回退)      │
└─────────────────────────────────────────┘
```

**配置选项**（添加到 `config.toml`）：

```toml
[performance]
# 性能优化选项
enable_gpu_acceleration = true  # 是否启用 GPU 加速
gpu_fallback_to_cpu = true      # GPU 不可用时回退到 CPU
spatial_index_type = "rtree"    # 空间索引类型：rtree, octree, none
enable_path_cache = true        # 是否启用路径缓存
max_cached_paths = 1000         # 最大缓存路径数
```

---

### 7.2 如果不实施 GPU 加速

**推荐优化路线**（按优先级）：

1. ✅ **第一阶段**（1 周）：空间索引 + 路径缓存 + 启发式优化
2. ✅ **第二阶段**（2 周）：CPU 多线程优化
3. ✅ **第三阶段**（2-3 周）：数据结构优化 + 增量更新

**预期效果**：整体性能提升 **5-15×**，无需 GPU 硬件要求。

---

## 8. 参考资料

### 8.1 技术文档

- [ILGPU 官方文档](https://ilgpu.net/)
- [ManagedCUDA GitHub](https://github.com/kunzmi/managedCuda)
- [Navisworks .NET API 开发者指南](doc/navisworks_api/NET/documentation/)

### 8.2 研究来源

- Autodesk Navisworks 开发者社区
- Navisworks API 2026 本地文档
- NVIDIA CUDA 编程指南
- Microsoft DirectCompute 文档

### 8.3 相关设计文档

- [A* 寻路优化方案](C# A_ 寻路优化_.md)
- [自动路径规划设计方案](PATHFINDING_DESIGN.md)
- [A* 库的使用方法](AStar库的使用方法.md)

---

## 9. 结论

### 9.1 核心发现

1. **Navisworks API 不提供 GPU 加速接口**，但可通过第三方库实现。
2. **当前项目的主要瓶颈在网格生成，而非 A* 搜索**。
3. **CPU 层面优化的投入产出比远高于 GPU 加速**。
4. **GPU 加速仅在特定场景（批量计算、大规模数据）下有显著收益**。

### 9.2 最终建议

**不建议立即实施 GPU 加速**，理由：

1. ✅ CPU 层面有大量优化空间未开发
2. ✅ 投入产出比更高的优化方案可优先实施
3. ✅ GPU 加速适用场景有限（批量计算）
4. ✅ 增加维护成本和技术复杂度

**建议优化路线**：

```
短期 (1-2周)  → 空间索引 + 路径缓存 + 启发式优化
              ↓ (性能提升 3-5×)
中期 (1-2月)  → CPU 多线程 + 数据结构优化
              ↓ (再提升 2-3×)
长期 (3-6月)  → 评估是否需要 GPU 加速
              ↓ (如需要)
              → 优先碰撞检测 GPU 加速
              → 次要 A* GPU 加速
```

### 9.3 重新评估触发条件

建议在以下情况下重新评估 GPU 加速方案：

1. ✅ CPU 层面所有优化已完成
2. ✅ 性能仍不满足需求（如单次路径计算 > 500ms）
3. ✅ 出现批量路径计算需求（10+ 条同时计算）
4. ✅ 用户群体确认有独立 GPU 硬件
5. ✅ 团队有足够资源进行开发和维护

---

**文档版本**：v1.0
**创建日期**：2025-10-12
**最后更新**：2025-10-12
**作者**：NavisworksTransport 开发团队