cgg-bern / quadwild-bimdf

QuadWild extended with BiMDF solver
GNU General Public License v3.0
34 stars 7 forks source link

Time consuming? #18

Open satabol opened 2 weeks ago

satabol commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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