How would we define an edge flip for edges connected to a boundary surface?
keenan
@rlpo Typically you just don't allow boundary edges to be flipped.
A really wild idea, which you can find in this paper is to make two copies of the surface, and glue them together along the boundary. Now you can flip boundary edges---at least combinatorially. You still have to think about what this means for the geometry. But like I said: this is a really wild idea. Most people just don't flip boundary edges! ;-)
dchen1
This part was a little confusing to me, as I couldn't understand how there weren't elements being created/destroyed.
After all, conceptually, we are literally removing two half edges and the edge bc, and adding in two half edges and an edge ad.
I only understood it after realizing that it probably meant that there was no need to allocate/deallocate any memory, and instead of explicitly creating/destroying we just repurpose the structs for the "removed" half edges for the new ones. Let me know if this is the correct thought process!
keenan
@dchen1 Yep! You have it right. Conceptually, you're getting rid of the old triangles/edges/halfedges and creating new ones. But since the number of elements before/after the flip is the same, it's easier to just reassign pointers.
sponge
Is there a clean way to think of doing edge flip such that pointers are unchanged after two flips?
keenan
@sponge Good question, and the answer is: I don't know. An edge flip routine that just depends on a fixed pattern of neighbors will likely "rotate" the halfedge a quarter turn in some fixed direction (either clockwise or counter-clockwise), so two flips won't by default restore the original pointer assignments. You could perhaps store a flag on each edge saying whether to "rotate left" or "rotate right" next time, but that seems like a lot of extra data/work for something that doesn't have a clear impact on the rest of your code (getting consistent pointer assignments).
The one situation where you might want to restore pointer assignments is when you perform a long sequence of flips, do some computation on the new mesh, then want to flip back to the original mesh. The reason you might want to preserve the correspondence is to preserve any mapping from this original mesh to (say) some other mesh. This kind of thing shows up occasionally when working with intrinsic triangulations. Here you can just store a list of edge flips (as an ordered list of edge pointers), performing "clockwise" flips when you originally go through the list and "counter-clockwise" flips when you reverse the list.
How would we define an edge flip for edges connected to a boundary surface?
@rlpo Typically you just don't allow boundary edges to be flipped.
A really wild idea, which you can find in this paper is to make two copies of the surface, and glue them together along the boundary. Now you can flip boundary edges---at least combinatorially. You still have to think about what this means for the geometry. But like I said: this is a really wild idea. Most people just don't flip boundary edges! ;-)
This part was a little confusing to me, as I couldn't understand how there weren't elements being created/destroyed.
After all, conceptually, we are literally removing two half edges and the edge bc, and adding in two half edges and an edge ad.
I only understood it after realizing that it probably meant that there was no need to allocate/deallocate any memory, and instead of explicitly creating/destroying we just repurpose the structs for the "removed" half edges for the new ones. Let me know if this is the correct thought process!
@dchen1 Yep! You have it right. Conceptually, you're getting rid of the old triangles/edges/halfedges and creating new ones. But since the number of elements before/after the flip is the same, it's easier to just reassign pointers.
Is there a clean way to think of doing edge flip such that pointers are unchanged after two flips?
@sponge Good question, and the answer is: I don't know. An edge flip routine that just depends on a fixed pattern of neighbors will likely "rotate" the halfedge a quarter turn in some fixed direction (either clockwise or counter-clockwise), so two flips won't by default restore the original pointer assignments. You could perhaps store a flag on each edge saying whether to "rotate left" or "rotate right" next time, but that seems like a lot of extra data/work for something that doesn't have a clear impact on the rest of your code (getting consistent pointer assignments).
The one situation where you might want to restore pointer assignments is when you perform a long sequence of flips, do some computation on the new mesh, then want to flip back to the original mesh. The reason you might want to preserve the correspondence is to preserve any mapping from this original mesh to (say) some other mesh. This kind of thing shows up occasionally when working with intrinsic triangulations. Here you can just store a list of edge flips (as an ordered list of edge pointers), performing "clockwise" flips when you originally go through the list and "counter-clockwise" flips when you reverse the list.