关于加快边缘选择的建议答案

【问题标题】：Suggestions on speeding up edge selection关于加快边缘选择的建议
【发布时间】：2011-08-27 21:58:46
【问题描述】：

我正在用 C# 构建一个图形编辑器，用户可以在其中放置节点，然后将它们与有向或无向边连接。完成后，A* 寻路算法确定两个节点之间的最佳路径。

我所拥有的： 一个 Node 类，其中包含一个 x、y、连接节点列表以及 F、G 和 H 分数。具有 Start、Finish 以及是否定向的 Edge 类。包含节点和边列表以及 A* 算法的 Graph 类

现在，当用户想要选择一个节点或一条边时，鼠标位置会被记录下来，我会遍历每个节点和边以确定是否应该选择它。这显然很慢。我在想我可以为我的节点实现一个四叉树来加速它但是我能做些什么来加速边缘选择？

【问题讨论】：

标签： algorithm graph computational-geometry

【解决方案1】：

由于用户正在“绘制”这些图表，我假设它们包含许多人类可能能够生成的节点和边（比如最大 1-5k？）。只需将两者存储在同一个 QuadTree 中（假设您已经编写了一个）。

您可以轻松地将经典的 QuadTree 扩展到 a PMR QuadTree，它会根据穿过它们的线段的数量添加分割标准。我写了一个hybrid PR/PMR QuadTree，它支持对点和线进行分桶，实际上它可以为 10-50k 移动对象提供足够高的性能（重新平衡桶！）。

【讨论】：

我需要实现一个 PMR 矩形四叉树。你能给我推荐一个源代码吗，在 java 中首选，但 C、C#、C++ 也可能，用于基本实现。您是否根据四叉树伪代码描述（如 Book od Shamir 中的描述）实现了您的动力学项目，或者您是否有基础源代码？
@AlexWien：我自己写的。你可以使用我的混合动力车做一些小的修改来做 PMR。

【解决方案2】：

所以您的问题是该人已经绘制了一组节点和边，并且您希望进行测试以更快地确定点击了哪条边。

嗯，一条边是一条线段。为了过滤到少量可能的候选边缘，将边缘延伸成线并没有什么坏处。即使您有大量边，也只有一小部分会靠近给定点，因此迭代这些边也不错。

现在将边分成两组。垂直的，而不是垂直的。您可以将垂直边缘存储在排序的数据结构中，并轻松测试哪些垂直线靠近任何给定点。

非垂直的更棘手。对于他们，您可以在可以放置节点的区域的左侧和右侧绘制垂直边界，然后将每条线存储为线与这些线相交的高度对。您可以将这些对存储在 QuadTree 中。您可以添加到此 QuadTree 逻辑以获取一个点，并在 QuadTree 中搜索在该点一定距离内经过的所有线。（这个想法是，在 QuadTree 中的任何点，您都可以为该点下方的所有线构造一对边界线。如果您的点不在这些线之间或靠近它们，则可以跳过树的该部分.)

【讨论】：

@epitaph：另一种解决方案通过边界框索引线段。我通过延长线与其他线相交的位置对它们进行索引。这些是非常不同的方法。

【解决方案3】：

我想你已经拥有了所有的成分。这是一个建议：

索引空间数据结构中的所有边（可以是QuadTree、R-Tree 等）。每条边都应使用其边界框进行索引。
记录鼠标位置。
搜索包含鼠标位置的最具体的矩形。
这个矩形应该有一个或多个边/节点；根据需要的模式遍历它们。
（棘手的部分）：如果用户没有从最具体的矩形中指出任何边缘，您应该上一层并遍历该层中包含的边缘。也许你可以不用这个。

这应该更快。

【讨论】：

如果使用边界框对边进行索引，那么长的对角边最终会在许多无用的鼠标位置进行测试。所以你会提高性能，但不如我的解决方案那么多。此外，我不知道如何使您的算法与 QuadTree 一起使用，尽管 R-Tree 肯定会起作用。最后，如果你用一个稍微放大的边界框来存储每条边（刚好足以使线中任意点附近的所有点都在框内），那么步骤 5 绝对可以省略。
您可以使用 PMR QuadTree，我在 Java 中做过一个（响应动态更新），它在 10-50k 对象范围内表现出色。但是，+1 R-Tree。