使用 GTS 的约束 Delaunay 三角剖分中的断言失败

发布于 11-15 17:21 字数 1203 浏览 2 评论 0原文

当使用 GNU 三角曲面库进行约束 Delaunay 三角剖分时,我遇到一些间歇性断言失败。我在不同时间看到过以下内容:

Gts:ERROR:cdt.c:974:remove_intersected_vertex: code should not bereached Gts:ERROR:cdt.c:896:remove_intersected_edge:断言失败:(下一个) Gts:ERROR:cdt.c:887:remove_intersected_edge: 断言失败: (o2 == 0.)

我查看了 cdt.c 但我所能弄清楚的是它们来自对 gts_delaunay_add_constraint 的调用。

有人可以解释一下约束可能存在什么问题,这会导致这些断言失败吗?

当我尝试对一组随机顶点进行三角测量时,会发生断言失败。不幸的是,这种情况只发生在大量顶点和约束的情况下,因此很难找出失败输入的模式。即使输入错误,使用 GTS 的代码也不会崩溃,因此最好能够防止这些断言失败,否则我将不得不禁用断言。

编辑:尝试删除所有相交约束(存储在边缘中):

int numPossEdges = gts_fifo_size(edges);
GtsEdge **possEdges = malloc(numPossEdges * sizeof(GtsEdge *));
for (int i = 0; i < numPossEdges; ++i)
    possEdges[i] = gts_fifo_pop(edges);
for (int i = 0; i < numPossEdges; ++i)
    for (int j = 0; j < i && possEdges[i] != NULL; ++j)
        if (possEdges[j] != NULL && GTS_IN == gts_segments_are_intersecting(&(possEdges[i]->segment), &(possEdges[j]->segment)))
            possEdges[i] = NULL;
for (int i = 0; i < numPossEdges; ++i)
    if (possEdges[i] != NULL)
        gts_fifo_push(edges, possEdges[i]);

仍然遇到相同的断言失败。

I'm getting some intermittent assertion failures when doing constrained Delaunay trianguation with the GNU Triangulated Surface Library. I've seen each of the following at different times:

Gts:ERROR:cdt.c:974:remove_intersected_vertex: code should not be reached
Gts:ERROR:cdt.c:896:remove_intersected_edge: assertion failed: (next)
Gts:ERROR:cdt.c:887:remove_intersected_edge: assertion failed: (o2 == 0.)

I've looked at cdt.c but all I've been able to figure out is that they're coming from calls to gts_delaunay_add_constraint.

Could someone explain what might be the problem with the constraints, that would cause these assertions to fail?

The assertion failures are happening when I try to do triangulation on a set of random vertices. It only happens, unfortunately, for large numbers of vertices and constraints, so it's hard to figure out a pattern for the failing inputs. The code that's using GTS needs to not crash even for bad input, so it would be nice to prevent these assertion failures, otherwise I'll have to disable the assertions.

Edit: Tried removing all intersecting constraints (stored in edges):

int numPossEdges = gts_fifo_size(edges);
GtsEdge **possEdges = malloc(numPossEdges * sizeof(GtsEdge *));
for (int i = 0; i < numPossEdges; ++i)
    possEdges[i] = gts_fifo_pop(edges);
for (int i = 0; i < numPossEdges; ++i)
    for (int j = 0; j < i && possEdges[i] != NULL; ++j)
        if (possEdges[j] != NULL && GTS_IN == gts_segments_are_intersecting(&(possEdges[i]->segment), &(possEdges[j]->segment)))
            possEdges[i] = NULL;
for (int i = 0; i < numPossEdges; ++i)
    if (possEdges[i] != NULL)
        gts_fifo_push(edges, possEdges[i]);

Still getting the same assertion failures.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

小鸟爱天空丶2024-11-22 17:21:05

如果您完全随机地创建顶点和约束,我想您可能会提供彼此相交的约束边。在这种情况下,我肯定会期望三角测量例程会抱怨。

If you're creating vertices and constraints completely randomly, I imagine you might be supplying constraint edges that intersect each other. In which case I would certainly expect the triangulation routines to complain.

哽咽笑2024-11-22 17:21:05

即使输入错误,使用 GTS 的代码也不会崩溃,因此它
防止这些断言失败会很好,否则我会
禁用断言。

我最终编写了一个补丁,使 GTS(基本上)在遇到断言失败时抛出异常而不是停止。补丁位于此处

The code that's using GTS needs to not crash even for bad input, so it
would be nice to prevent these assertion failures, otherwise I'll have
to disable the assertions.

I ended up writing a patch that causes GTS to (basically) throw an exception instead of halting when it hits an assertion failure. The patch is here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文