tian/NavisworksTransport

Fork 0

tian dd991d38ce 增加体素网格和GPU加速2个可行性方案

2025-10-12 11:05:29 +08:00

24 KiB

Raw Blame History

Navisworks 插件 GPU 加速可行性研究

1. 研究背景与目标

1.1 背景

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

1.2 研究目标

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

1.3 当前性能瓶颈

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

网格地图生成（GridMapGenerator）
- BIM 模型几何扫描
- 障碍物边界膨胀算法
- 高度层识别和合并
A 路径规划*（AutoPathFinder）
- 3D 图构建（多层网格连接）
- A* 搜索算法执行
- 路径后处理优化
碰撞检测（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 文档中搜索以下关键词：

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+

主要特点

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

C# 原生编程

// 示例：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 上执行
}

高层抽象
- 无需编写 CUDA C++ 代码
- 自动内存管理
- 类型安全
性能
- 接近手写 CUDA 的性能（90-95%）
- 支持 Shared Memory、Atomic 操作
- 内置性能分析工具

适用场景

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

3.3 ManagedCUDA

基本信息

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

主要特点

CUDA 工具包的 .NET 包装器
- 直接映射 CUDA C API
- 完整的 CUDA 功能访问
- 需要安装 NVIDIA CUDA Toolkit
性能
- 接近原生 CUDA 性能（98-100%）
- 直接控制内存分配和传输
- 支持 CUDA Streams、Events
限制
- 仅支持 NVIDIA GPU
- 学习曲线较陡（需要理解 CUDA 编程模型）
- 需要手动管理内存和资源

适用场景

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

3.4 DirectCompute

基本信息

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

主要特点

跨厂商支持
- 所有支持 DirectX 11+ 的 GPU
- 与图形管线集成
限制
- .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 是最佳选择，原因：

跨厂商支持（用户可能使用 AMD 或 Intel GPU）
纯 C# 开发，与现有代码库一致
降低技术门槛，易于团队掌握
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 关键技术点

网格数据结构 GPU 化

// 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;
}

并行 A 算法实现*
- 每个 GPU 线程处理一个起终点对
- 使用 GPU Shared Memory 存储 Open/Close 集合
- 需要处理原子操作（更新最优路径）
数据传输优化
- 使用 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 关键技术点

包围盒数据结构

struct GPUAABB
{
    public Vector3 Min;
    public Vector3 Max;
}

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

并行碰撞检测算法
- 每个 GPU 线程处理一对对象
- N 个对象 = N×(N-1)/2 个线程
- 使用空间分区（Grid-based）减少检测对数
动画过程集成
- 每帧更新对象位置到 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 技术风险

GPU 内存限制
- 风险：大规模网格数据可能超出 GPU 显存
- 缓解：分块处理、数据压缩
用户硬件支持
- 风险：部分用户无独立 GPU
- 缓解：ILGPU CPU 回退模式
数据传输开销
- 风险：频繁传输抵消 GPU 加速收益
- 缓解：数据缓存、批量处理
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. 网格生成优化

// 当前实现：逐个网格扫描
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 启发式函数优化*

// 当前：简单欧几里得距离
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. 路径缓存机制

// 缓存常用路径
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 多线程优化

// 网格生成并行化
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. 网格数据结构优化

// 当前：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. 增量式网格更新

// 当前：每次全量重建网格
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 加速（高投入，场景受限）

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

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

推荐实施顺序：

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

工作量：18-28 天

6.3 综合建议

短期（1-2 周）

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

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

中期（1-2 月）

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

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

长期（3-6 月）

⚠️ 评估是否需要 GPU 加速
- 如果 CPU 优化后仍不满足需求 → 实施碰撞检测 GPU 加速
- 如果存在大批量路径计算需求 → 实施 A* GPU 加速
⚠️ 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）：

[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 周）：空间索引 + 路径缓存 + 启发式优化
✅ 第二阶段（2 周）：CPU 多线程优化
✅ 第三阶段（2-3 周）：数据结构优化 + 增量更新

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

8. 参考资料

8.1 技术文档

8.2 研究来源

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

8.3 相关设计文档

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

9. 结论

9.1 核心发现

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

9.2 最终建议

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

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

建议优化路线：

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

9.3 重新评估触发条件

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

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

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

24 KiB Raw Blame History Unescape Escape

Navisworks 插件 GPU 加速可行性研究

1. 研究背景与目标

1.1 背景

1.2 研究目标

1.3 当前性能瓶颈

2. Navisworks API GPU 能力调研

2.1 调研方法

2.2 调研结果

2.2.1 Navisworks API 线程模型

2.2.2 硬件加速支持情况

2.2.3 GPU 系统要求

2.2.4 API 文档搜索结果

2.3 结论

3. 第三方 .NET GPU 计算库

3.1 可用方案概览

3.2 ILGPU（推荐）

基本信息

主要特点

适用场景

3.3 ManagedCUDA

基本信息

主要特点

适用场景

3.4 DirectCompute

基本信息

主要特点

适用场景

3.5 方案对比

4. 应用场景分析

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

4.1.1 数据流设计

4.1.2 关键技术点

4.1.3 适用场景判断

4.1.4 性能预估

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

4.2.1 数据流设计

4.2.2 关键技术点

4.2.3 适用场景判断

4.2.4 性能预估

5. 实施评估

5.1 工作量估算

5.2 技术风险

5.3 维护成本

6. 优化建议与优先级

6.1 当前项目性能分析

6.2 优化优先级排序

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

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

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

6.3 综合建议

短期（1-2 周）

中期（1-2 月）

长期（3-6 月）

6.4 投入产出比对比

7. 技术选型建议

7.1 如果决定实施 GPU 加速

7.2 如果不实施 GPU 加速

8. 参考资料

8.1 技术文档

8.2 研究来源

8.3 相关设计文档

9. 结论

9.1 核心发现

9.2 最终建议

9.3 重新评估触发条件

24 KiB

Raw Blame History