-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Algorithm fails to generate correct Delaunay triangulation #10
Comments
This seems to be quite an old issue... Has this been fixed yet? I believe this is one of the most downloaded delaunay triangulation crate (just after |
@timothee-haudebourg it's not a trivial issue to fix. You're welcome to submit a PR if you have time to spend on this — it would involve switching to Shewchuk's robust version of the Also this kind of bug (caused by floating point errors) is present in a lot of computational geometry software, and usually has workarounds (such as scaling/rounding the input coordinates), so I wouldn't call it unusable because of it. |
I see, so it is just a precision problem. Although it can be deduced by the precision of the floats values used in the example, that wasn't quite clear. Sorry if I sounded a bit harsh, I know it can be difficult to find time working on such projects, but it would not be the first time I come across a buggy dead crate without any such indication for the users. Your response gives just the information I needed, it would have been nice to give it earlier to help users navigate the sea of Rust crates. Apart from that, thanks for your work! |
@timothee-haudebourg this crate definitely needs more love — I wrote it as a small Rust-learning project (porting my own JS library), but can't devote much free time to maintain it. New contributors are very welcome though. |
@JackStade , @timothee-haudebourg - it would be super helpful if you could try this scenario against the branch from #19 - I was not able to repro the issue on current master on my box; but if this is related to the missing robustness checks, it should help. I am wondering if there is some other factor in play here (compiler version maybe?). Here is the triangulation I am getting right now (does not include [10, 0, 3]): EDIT: so I noticed that the triangulation being generated is putting some of the points that visually we would expect to be on the hull inside of the hull. For example, 19 is inside of the hull (black dot) and 0 is on the hull (red dot). Then degenerated triangle [19, 0, 14] is being formed. |
So I was learning WASM and decided to build an inspector on the browser to compare the rust library running in WASM with the JS library. This is this data set running against the master branch And this is the data set for the robust branch I still have no clue why when I compile rust to native, it cannot repro the issue on master. I can only imagine that the instructions that WASM compiles to may be slightly different than the ones for the native target. I wonder if the compiler, when it targets native, it is able to identify some float error accumulation patterns and replace with ones that accumulates less errors. Frankly I do not know enough about floats! |
* Robust orient2d checks * Add example to display triangulation in SVG * Clean up svg.rs example * Split fixture tests into separate test cases * Add test case for #10 * Copy remaining robustness tests from js repo * Add point label to svg example to easy investigations * Add grid test fixture * Add hull convex check to tests Based on mapbox/delaunator#51 Along with the last missing test case "issue44". * Remove invalid test code for connectivity
Closed by #19 |
I was using this library for a project of mine, and I came across a bug caused by the algorithm generating a triangulation that badly fails to meet the Delaunay condition.
Here is code that demonstrates the bug:
The output is:
Which contains the triangle
[10, 0, 3]
. By plotting these points we can see that this triangle definitely shouldn't be part of the Delaunay triangulation, as the circumcircle of these points contains most of the other points:It looks like there are other triangles in this triangulation that fail the condition. I have idea why this specific set of points causes a problem.
The text was updated successfully, but these errors were encountered: