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

Bug in preprocessing: holes appears after mesh simplification #56

Closed
spaceZt3 opened this issue Mar 15, 2023 · 5 comments
Closed

Bug in preprocessing: holes appears after mesh simplification #56

spaceZt3 opened this issue Mar 15, 2023 · 5 comments

Comments

@spaceZt3
Copy link

After mesh simplification, there is a probability that holes will appear. Try it a few more times, and each time the results are different: sometimes holes are produced, sometimes no holes are produced. I think it's a data race problem when parallel edge collapse.

@Yixin-Hu
Copy link
Collaborator

Hi,

The mesh simplification is a preprocessing on the input and it does not touch the non-manifold edges/vertices of the mesh so it should not create holes.

Could you share your input and command with me? Thanks.

@nmnobre
Copy link

nmnobre commented Jul 7, 2023

After mesh simplification, there is a probability that holes will appear. Try it a few more times, and each time the results are different: sometimes holes are produced, sometimes no holes are produced. I think it's a data race problem when parallel edge collapse.

Hey @spaceZt3,

I actually found a race condition in the preprocessing edge collapse algorithm myself yesterday!
I put together a fix in #58. It's currently the last commit, 628ef41, although that might change if I rebase...
Since you seem to be encountering a similar issue, could you please check if that fix works for you too?

Cheers,
-Nuno

@spaceZt3
Copy link
Author

spaceZt3 commented Jul 11, 2023

After mesh simplification, there is a probability that holes will appear. Try it a few more times, and each time the results are different: sometimes holes are produced, sometimes no holes are produced. I think it's a data race problem when parallel edge collapse.

Hey @spaceZt3,

I actually found a race condition in the preprocessing edge collapse algorithm myself yesterday! I put together a fix in #58. It's currently the last commit, 628ef41, although that might change if I rebase... Since you seem to be encountering a similar issue, could you please check if that fix works for you too?

Cheers, -Nuno

Thanks. @nmnobre I saw your commit. But I wonder why it can fix the data race problem? It just simply change "std::vector" to "std::vector".

@nmnobre
Copy link

nmnobre commented Jul 11, 2023

Thanks. @nmnobre I saw your commit. But I wonder why it can fix the data race problem? It just simply change "std::vector" to "std::vector".

std::vector<bool> to std::vector<char> to be more precise. :)
The difference is with the latter you are guaranteed each thread accesses entirely different bytes, guaranteeing thread safety purely via cache coherence. Let me know if the fix works in your case as well or if there's still something else we need to nail down.

@spaceZt3
Copy link
Author

spaceZt3 commented Jul 13, 2023

Thanks. @nmnobre I saw your commit. But I wonder why it can fix the data race problem? It just simply change "std::vector" to "std::vector".

std::vector<bool> to std::vector<char> to be more precise. :) The difference is with the latter you are guaranteed each thread accesses entirely different bytes, guaranteeing thread safety purely via cache coherence. Let me know if the fix works in your case as well or if there's still something else we need to nail down.

@nmnobre ,thanks for your explanation! I will try it later.

@spaceZt3 spaceZt3 closed this as completed Nov 7, 2023
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

3 participants