-
Notifications
You must be signed in to change notification settings - Fork 14
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
split and collapse steps operate on different domains #16
Comments
Hi @yoterel ! I'm glad you like this repo. If I understand you correctly, this behaviour is intentional. If we want the final mesh to have a lower bound on its edge length, we will need to collapse all edges that go below that bound, including those that we may have accidentally created during splitting. This moves us closer to the target than if we just collapsed the ones identified prior to splitting. The authors of the original paper also present it as a sequential, iterative method that happens in four steps: Further, openflipper, the software package designed in part by one of the paper's authors, also does these steps sequentially and reidentifies the corresponding edges (see L444 onwards here) So I'm fairly confident that we're doing it as the authors intended. Nonetheless, maybe I am misunderstanding you, and I don't understand your last paragraph. What is an example of an application where you would like the behaviour you describe and what functionality would you like to see added here? |
Thank you for the quick response. I have skimmed through the open-flipper implementation and confirmed that it performs collapse over the split result, and not jointly, like you said. One such application using the edge map (and the reason I was asking about this from the beginning) would be when wanting to have L from step (1) and (2) change per edge, according to some metric or heuristic such as local curvature. Then, assuming this computation is expensive, instead of computing this scalar field twice for the whole mesh, it would only be needed to be computed once and locally edited where splits happened. So I guess the actual benefit is more of an efficiency improvement when extending the method. |
Hi, thanks for this repo !
According to the paper, during a single iteration, every edge that meets a certain lower bound is split, and every edge that meets a certrain upper bound is collapsed.
It seems like in this implementation, the collapse step operates on the mesh after it has been split, rather than on the input of the iteration, which would yield a different result than the original paper where selected edges that meet the upper bound are considered prior to splitting (i.e. there could be edges that were newly created, that are considered for collapsing, and edges that should have been selected for collapsing, but aren't because their length got shortened by some split).
Is this by design? or an error?
if error, is it possible to ask you document the inputs to the split step? I noticed there is a map between old and new edges, which could potentially be used to resolve this (which I will happily submit a pull request for)
The text was updated successfully, but these errors were encountered: