Improve stopping conditions in surface meshing (and throughout GC)
@MarkGillespie đang làm issue này rồi.
Từ ngày 21/1/2023.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
This issue addresses a small road bump with the remesh function, but is more generally something good to think about throughout the design of GC: how should stopping criteria be determined, and what control should be provided to the user?
Issue
Currently the stopping condition in remesh is
if ((nFlips == 0) && (flowDist < 0.01)) break;
Even though the quantity flowDist is normalized by the number of mesh vertices, the constant (0.01) is pretty arbitrary and often does not yield the desired/expected behavior.
Especially annoying is that one can't get more smoothing by increasing the maxIterations option, since the optimizer will quit as soon as flowDist is less than 0.01.
Proposed Solution
Three possibilities come to mind:
- Add an additional option
relativeStoppingTolerancewhich is used in place of the magic constant0.01. This is a no-brainer. - Measure the relative norm of the gradient. This requires us to assign a variational interpretation to the smoothing operations, but that seems reasonably straightforward: Laplacian smoothing is minimizing Dirichlet energy, restricted to tangential motions; circumcentric smoothing is likewise minimizing the optimal Delaunay energy among tangential motions. (I believe de Goes et al discuss how to think about ODT in terms of energy minimization in the non-flat case.)
- Add an additional option
minIterationsthat forces the optimizer to take at least this many iterations. In general, such a parameter is good to have: no matter how careful you are with designing stopping criteria, there tend to be cases where this automatic condition stopped to early—or at very least, the user would like to see what happens if you "just keep on going." For instance, in the remeshing case, it's clear just from looking at the output meshes that they are not always as smooth/regular as they could be.
- Ngôn ngữ chính
- C++
- Star
- 1.3k
- Fork
- 183
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của nmwsharp/geometry-central
-
warning: control reaches end of non-void function in VectorHeatMethodSolver::computeLogMapCó thể đã có người làm @dyollb đã nhận 66 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
nmwsharp/geometry-central#256 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
nmwsharp/geometry-central#258 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
nmwsharp/geometry-central#255 · 1 bình luận ·
-
FlipEdgeNetwork::iterativeShorten() hangs on a contractible closed loopCó thể đã có người làm @designbynumbers đã nhận 117 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
nmwsharp/geometry-central#253 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 57/100
nmwsharp/geometry-central#247 ·
Tất cả issue của nmwsharp/geometry-central
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
NVIDIA-RTX/NRI#277 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
os:Linux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 3 ngày