Delaunay refinement (#66) #68
Conversation
Stoeoef
force-pushed
the
delaunay_refinement
branch
2 times, most recently
from
dd6e033 to
7b7eef6
Compare
Stoeoef
force-pushed
the
delaunay_refinement
branch
from
b295511 to
fc344e1
Compare
|
This PR seems really interesting and useful. Is there something I could do to help you out here @Stoeoef ? |
|
@RobWalt Sorry for my long silence on this issue! Especially since the actual hard work - the implementation of the refinement algorithm - is already completed. I would appreciate support in bringing this over the finishing line! I plan on looking into this branch within the next week to see where I've left things back then. In the meantime, if you want to help, feel free to simply try this out. Getting some feedback from actual users (I myself don't need this feature) would be helpful! |
|
No rush, I didn't mean to stress you out with the message 😅 I have a good use case for it. We're working on some geometry and need to create tri-meshes from it. Unfortunately the software we're feeding the tri meshes into isn't happy about degenerate triangles. I think this feature here would make a lot of our own cleanup post processing unnecessary. It's also something I'd like to support with some new method on the newly integrated spade trait in the geo crate I've already started reading into the code a bit, but I'm really new to some of the ideas here. I'll try to focus on giving some support and feedback by:
From what I've seen, the triangulations are already looking really promising! In terms of quality I would already say that this is perfectly fine. Anything that is creating even just slightly friendlier triangulations is good enough and for the rest we can iterate on the initial solution 🔧 |
|
Just did a little testing and I'm in love. I still need to cleanup some parts but here is a sneak peek
|
|
Ohh, that does look lovely. |
I'm using OSM data here. I think the level of detail on the left side comes from a unnecessary subdivision of the leftmost line. This probably leads to very thin triangles. Since I refined with |
…r_faces` Various bug fixes & improvements to the refinement
Bugfix: Calling `add_constraint` with the same vertex handle would incorrectly increase the internal constraint counter. The correct behavior is to leave the constraint counter unchanged. New method: Adds `ConstrainedDelaunayTriangulation::add_constraint_edges`
Adds comments about `refine` internals.
The refinement will not refine triangles whose shortest edge spans between to input angle segments that adjoin a common vertex. This is described in more detail in: Miller, Gary; Pav, Steven; Walkington, Noel (2005). "When and why Delaunay refinement algorithms work"
…y fuzzing Delaunay refinement can work.
Also contains a bugfix: If a skinny face's circumcenter was lying _on_ a constraint edge, it would split that edge and _not_ update the `excluded_faces` buffer.
Stoeoef
force-pushed
the
delaunay_refinement
branch
from
fc344e1 to
fc46d61
Compare
It's now a simple `bool` that determines if faces should be excluded. Changes `RefinementResult::excluded_faces` from `HashSet` to `Vec` for better `no_std` interoperability.
Stoeoef
force-pushed
the
delaunay_refinement
branch
from
fc46d61 to
0fd0c8a
Compare
…tly more readable.
|
Alright, this is ready to go - merging in! |
See #66.
This is the initial implementation which works sufficiently well already.
To use this, create a CDT, insert some constraint edges and then call
my_cdt.refine(RefinementParameters::new().exclude_outer_faces())which will refine the cdt inplace. Note that, in order for
exclude_outer_facesto work, the constraint edges should form a loop somewhere - otherwise, all faces will be considered to be outer faces and won't be refined.Remaining TODOs (just mentioning for my own overview):
AngleLimitRefinementParametersfn refineTODOs for some follow-up PRs:
exclude_outer_facesworks