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

Time consuming? #18

Open
satabol opened this issue Jun 12, 2024 · 4 comments
Open

Time consuming? #18

satabol opened this issue Jun 12, 2024 · 4 comments

Comments

@satabol
Copy link

satabol commented Jun 12, 2024

Can you explain why different settings consuming equal times?

image

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?

@mheistermann
Copy link
Member

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).
I think for this particular input, the parts of the algorithm that are independent of the target size will dominate the runtime.

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, quad_from_patches on that output (as many times as you like with different parameters), and it should generate a quadmesh much faster.

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 :)

@satabol
Copy link
Author

satabol commented Jun 13, 2024

Thank you. I have the same thoughts and it’s good you confirmed that. In Sverchok there is a way to understand what changes - a source mesh or some node params. So it is good idea to save data for "2" and use them later.
I have one question yet: as I see this algorithm is not multithread? I observed Task manager while a quadwild processing mesh. There is no one core of processor consume 100% of power at process:
image
Is quadwild a single thread application?

@mheistermann
Copy link
Member

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.

@satabol
Copy link
Author

satabol commented Jun 13, 2024

I test Blender Quadriflow Remesh. It is a single thread too. May be not simple to do it as multithread.

(Just for info how to call a Quadriflow Remesh in Blender)
image

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