Skip to content
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

Open
yoterel opened this issue Jan 5, 2023 · 2 comments
Open

split and collapse steps operate on different domains #16

yoterel opened this issue Jan 5, 2023 · 2 comments

Comments

@yoterel
Copy link

yoterel commented Jan 5, 2023

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)

@sgsellan
Copy link
Owner

sgsellan commented Jan 5, 2023

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:

Screenshot 2023-01-05 at 9 36 06 AM

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?

@yoterel
Copy link
Author

yoterel commented Jan 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants