WPF，XNA，SlimDX ...建议使用类似CAD的桌面应用程序？ （C＃）

Question

这就是我要做的事情：

构建类似CAD的应用程序，从文件加载点云（即表示3D对象的数千个3D点），允许用户操纵点（即通过移动点来改变形状），做了很多计算点上的点（例如，找到线和曲面之间的交点，检测点在表面上方或下方等，测量点之间的距离，或点到表面等），然后保存修改后的点提交。

它还提供基本的类似CAD的UI功能，例如放大/缩小，平移视图，旋转相机等。

速度是主要问题。

我不想编写自己的函数进行矩阵运算并定义自己的点/线/曲面类，而是希望使用现有的库/ API来完成这项工作。

我知道WPF，XNA和SlimDX提供了进行3D几何计算的API，所有这些都最终调用了DirectX，但我只是对所有人都是新手。我想知道：

1. 哪一个（或其他一些建议）可以提高速度。

2. 我对DirectX 3D功能的理解是它主要处理游戏图形/屏幕输出，它还适用于数据级计算（即使用3D功能来操纵点数据，计算距离等）。 ，但不是在屏幕上输出）？合适的，我的意思是如果我创建数以千计的DirectX顶点并对它们进行mainpulate，它会比使用我自己的数据类型和结构慢得多吗？ 如果我的理解是错误的，请纠正我。

3. 如果我使用WPF，我是否也需要使用XNA？我有点混淆这两件事。

4. 该应用程序应该在研究实验室的PC中运行，该PC没有强大的游戏显示卡，所以它是否意味着XNA不是首选？

5. 有关这些技术的建议应该用于此应用程序吗？

谢谢！

======更新

为了更清楚，应用程序将在3D中加载~108,000个点，并且每个点将与其他相邻点形成表面，因此大致涉及相同数量的3D表面（我不会在同一时间生成它们）时间）。我将使用点和曲面进行大量的3D几何和矩阵计算，例如交点，插值，变换等，因此“计算”的速度是我主要关注的问题。大多数时候我只会将最终结果绘制到屏幕上，而绘图主要是线条和点，“绘图”的速度并不是一个大问题。所以它不是一个图形密集型应用程序，而是一个几何计算密集型应用程序。

在阅读答案和评论后，我想到了两个选择：

1. 商店＆amp;使用原始数据类型计算数据，并在屏幕上绘制数据时将数据转换为WPF / XNA / SlimDX数据结构，或

2. 使用这些API的数据结构来存储，计算和绘制所有这些点。

哪一个更好？

Answer 1

1. 老实说，如果表现是你的 主要关注我会去 使您最接近的API 硬件。 较少混淆=更多 速度。在那种情况下，来自 您提供的选择 SlimDX 是最好的选择，其次是XNA， 最后，WPF。
2. 不，DirectX必须使用高效的数据结构和算法。想一想 - 如果所有DirectX计算本身都很慢，那么利用DirectX的游戏能够以合适的帧速率运行吗？
3. 不，WPF和XNA是互斥的。 WPF是一个用于创建响应和直观的用户界面的框架。另一方面，XNA是一个创建游戏的框架。
4. 不一定。实际意味着WPF不是首选，因为WPF会将大量工作卸载到兼容的视频卡上。如果WPF无法找到合适的视频卡，CPU将采取相应的工作，导致性能下降。
5. 正如我之前所说，对于图形密集型应用程序（例如您所描述的应用程序），您越接近硬件就越好。 Native DirectX或SlimDX是不错的选择。

Answer 2

您是否考虑过将您的功能开发为现有CAD环境的插件？ 例如，AutoCAD有一个非常强大的c ++ sdk（ObjectARX），它还提供了一个托管的.NET API。您可以使用c＃和WPF来开发扩展。它具有您可以重用的现有几何库。 当然，AutoCAD有它的价格，但也有其他选择。例如BricsCAD。我不确定BricsCAD是否提供了.NET API。

从头开始开发应用程序需要数周甚至数月。 如果我将你的功能开发为AutoCAD插件，那我需要一天时间。

考虑一下你是否真的需要推出自己的“CAD”环境。

Answer 3

几周前，我检查了XNA的限制。我想知道引擎能够处理多少广告牌（GPU加速）。结果： 纯XNA：350k广告牌 XNA作为WPF中的渲染上下文：100k广告牌

我不知道为什么在渲染到WinFormHost控件时引擎会变慢。一些调试显示，GraphcisDevice.Present（）