当前位置：文江博客话题详情

.NET高级图形库

发布于 2024-10-15 09:42:16 字数 272 浏览 8 评论 0原文

我正在用 C#/.NET 编写各种模拟工具，

我正在寻找的是一个高级可视化库；使用带有一些标准控件的相机创建一个场景，并向其渲染数十万个球体或一些线框。那种事。如果初始化一个上下文需要多行代码，那就偏离了我的理想。

我看过 slimDX，但它的级别比我寻找的要低（至少是记录的部分，但我并不真正关心任何其他部分）。 WPF 视角看起来很酷，但它似乎针对静态 XAML 定义的场景，这也不太适合我。

基本上，我正在寻找像 blitzbasic 这样的语言用来提供的功能。这真的存在吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

Oo萌小芽oO 2024-10-22 09:42:16

我对此也很感兴趣（因为我也在开发模拟工具）并最终在 XNA 中组装了一些东西。然而，这肯定比您描述的要多得多。请注意，您可以通过 XAML 在 WPF 中执行的任何操作也可以通过代码完成，因为 XAML 只是对象层次结构及其关系的表示。我认为这可能是你最好的选择，尽管我没有任何指标来衡量你可以期望使用几十万个球体获得什么样的性能（在这种情况下你绝对需要一些剔除，而剔除本身可能是如果您不使用网格分区等优化，则价格昂贵。）

编辑：如果您确实需要支持 100K 实体并且它们都可以渲染为球体，我建议您完全绕过 3d 引擎，仅使用 XNA 进行数学计算。我想像下面这样的方法：

使用 XNA 设置相机（视图）和透视矩阵。它有一些方便的矩阵静态函数，使这一切变得容易。
计算投影矩阵并将所有“球体”原点投影到视锥体。这将为您提供 X、Y 屏幕坐标和截锥体中的 Z 深度。您可以将其表示为 100K 个单独的矩阵乘法或投影矩阵与单个 3 x 100K 元素矩阵的乘法。在前一种情况下，这是使用新的 .NET 4 并行功能实现并行性的绝佳候选者。
如果您发现 100K 矩阵乘法是一个问题，并且您知道在给定时间只有一小部分点可见，则可以通过在转换之前执行点剔除来显着减少这个问题。例如，您可以反转投影矩阵以找到原始空间中平截头体的边界，并为平截头体创建一个轴对齐的边界框。然后，您可以排除此框之外的所有点（在 X、Y 和 Z 中进行简单的比较测试。）您只需要在投影矩阵更改时重新计算此边界框，因此如果它不经常更改，这可能是一个合理的优化。
获得变换后的点后，剪掉截锥体外部的任何点（Z < 0、Z > maxDist、X < 0、Y < 0、X > 宽度、Y > 高度）。现在，您可以通过绘制一个实心圆来渲染每个点，其半径与 Z 成比例（Z=0 将具有最大半径，Z=maxDist 可能会淡入单个点。）如果您想提供阴影/深度感，您可以使用阴影画笔进行渲染，以非常宽松地模拟球体上的照明。这是可行的，因为场景中的所有东西都是球体，并且您可能不担心阴影之类的东西。所有这些在 WPF 中都相当容易完成（包括阴影画笔），但请务必使用 DrawingVisual 类而不是框架元素。另外，您需要确保以正确的 Z 顺序进行绘制，因此，如果您将变换后的点存储在按添加顺序排序的数据结构中，这会有所帮助。
如果您仍然遇到性能问题，您可以进行进一步的优化。例如，如果您知道只有一部分点在移动，则可以缓存不动点的变换位置。这实际上取决于数据集的性质及其演变方式。
由于您的数据集太大，您可能会考虑更改可视化方式。不要渲染 100K 点，而是将工作空间划分为体积网格并记录每个网格立方体内的点的数量（密度）。您可以仅投影网格的中心并将其渲染为“球体”，并带有一些附加反馈（如颜色、不透明度或画笔纹理）来指示点密度。您可以将此技术与传统渲染方法结合起来，通过将近点渲染为“球体”，将远点渲染为“簇”对象，并使用一些画笔图案来匹配密度。一种简单的算法是考虑相机周围的边界球；球体内的所有点都会正常变换；在球体之外，您将仅使用密度网格进行渲染。

I'm also interested in this (as I'm also developing simulation tools) and ended up hacking together some stuff in XNA. It's definitely a lot more work than you've described, however. Note that anything you can do in WPF via XAML can also be done via code, as XAML is merely a representation of an object hierarchy and its relationships. I think that may be your best bet, though I don't have any metrics on what kind of performance you could expect with a few hundred thousand spheres (you're absolutely going to need some culling in that case and the culling itself may be expensive if you don't use optimizations like grid partitioning.)

EDIT: If you really need to support 100K entities and they can all be rendered as spheres, I would recommend that you bypass the 3d engine entirely and only use XNA for math. I would imagine an approach like the following:

Use XNA to set up Camera (View) and Perspective matrices. It has some handy Matrix static functions that make this easy.
Compute the Projection matrix and project all of your 'sphere' origin points to the viewing frustrum. This will give you X,Y screen coordinates and Z depth in the frustrum. You can either express this as 100K individual matrix multiplications or multiplication of the Projection matrix by a single 3 x 100K element matrix. In the former case, this is a great candidate for parallelism using the new .NET 4 Parallel functionality.
If you find that the 100K matrix multplications are a problem, you can reduce this significantly by performing culling of points before transformation if you know that only a small subset of them will be visible at a given time. For instance, you can invert the Projection matrix to find the bounds of your frustrum in your original space and create an axis-aligned bounding box for the frustrum. You can then exclude all points outside this box (simple comparison tests in X, Y and Z.) You only need to recompute this bounding box when the Projection matrix changes, so if it changes infrequently, this can be a reasonable optimization.
Once you have your transformed points, clip any outside the frustum (Z < 0, Z > maxDist, X<0, Y<0, X>width, Y>height). You can now render each point by drawing a filled circle, with its radius proportional to Z (Z=0 would have largest radius and Z=maxDist would probably fade to a single point.) If you want to provide a sense of shading/depth, you can render with a shaded brush to very loosely emulate lighting on spheres. This works because everything in your scene is a sphere and you're presumably not worried about things like shadows. All of this would be fairly easy to do in WPF (including the Shaded Brush), but be sure to use DrawingVisual classes and not framework elements. Also, you'll need to make sure you draw in the correct Z order, so it helps if you store the transformed points in a data structure that sorts as you add.
If you're still having performance problems, there are further optimizations you can pursue. For instance, if you know that only a subset of your points are moving, you can cache the transformed locations for the immobile points. It really depends on the nature of your data set and how it evolves.
Since your data set is so large, you might consider changing the way you visualize it. Instead of rendering 100K points, partition your working space into a volumetric grid and record the number (density) of points inside each grid cube. You can Project only the center of the grid and render it as a 'sphere' with some additional feedback (like color, opacity or brush texture) to indicate the point density. You can combine this technique with the traditional rendering approach, by rendering near points as 'spheres' and far points as 'cluster' objects with some brush patterning to match the density. One simple algorithm is to consider a bounding sphere around the camera; all points inside the sphere will be transformed normally; beyond the sphere, you will only render using the density grid.

回复收藏 0 原文