-
Notifications
You must be signed in to change notification settings - Fork 10
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
Time consuming? #18
Comments
There's a bunch of different parts of the meshing pipeline that respond differently to changes in target resolution. For some of them, coarser meshes are more difficult (often the case of quantization, i.e., integer length assignments to patch decompositions), but for others, finer meshes may be harder (I'd expect that to the the case for the final round of smoothing). Often, initial remeshing and field tracing take the longest time. I think you're on the right track with the idea to cache some parts that are independent of the parameters you'd want to change. In your screenshot you're using quadwild.exe with the "3" parameter, which will do the entire pipeline from start to finish. If you use "2", it will stop after remeshing, field generation and patch decomposition. Then you can use the other tool, Also, if you disable the final smoothing step, you'll often save a lot of time and get a pretty good preview: the mesh topology is already the final one, only vertex positions are not optimized yet. Hope this helps :) |
The part I worked on (quantisation) is definitely single-threaded. I'm not certain about the rest of the code by the original creators of quadwild. |
Can you explain why different settings consuming equal times?
A left figure is a more complicated than a right one. Why it consumes the same time to quad? Is a way to do it more quick for low density?
Or is a way to cache a "something" to play with params?
The text was updated successfully, but these errors were encountered: