Page MenuHome

Poor performance with QuadriFlow on high density meshes, eats RAM, and refuses to cancel when pressing Esc
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 980/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.30

Blender Version
Broken: version: 2.81 (sub 12), branch: master (modified), commit date: 2019-09-27 17:16, hash: rBbe985bdde27f
Worked: (optional)

Short description of error
I tried using the baseline settings for the QuadriFlow Remesher on a model with around 728k verts with a ratio of 1.000. The process however was incredibly slow and did not reach 50% until several minutes of waiting. Once that happened, QuadriFlow refused to complete the action and cancelling the action did nothing. The process also ate an incredible amount of RAM, practically maxing out mine which has 32 GB built in.

Exact steps for others to reproduce the error
You can try using QuadriFlow on the sculpt file shown in the video here.

Event Timeline

You should not be using Quadriflow to remesh with a target count that high. I don't recommend to use any value higher than 50k target faces. If you need more resolution, you should use Quadriflow to calculate a low poly subdividable mesh and the reproject the details back with a multires modifier in a higher subdivision level.
@Brecht Van Lommel (brecht) Can we change the default settings in Quadrifllow to use target face count by default instead of ratio?

@Pablo Dobarro (pablodp606) I've tried that and have managed to get better results. The problem is though that QuadriFlow allows you to use settings that it will never be able to calculate properly. Just for comparison, this is how ZRemesher behaves on the exact same model when using a similar setting as the 1.000 ratio in Blender:

ZRemesher doesn't try to hit 700k+, but instead creates a quad mesh with a much more manageable density that it can calculate. I think QuadriFlow should behave similarly while using the ratio setting to avoid issues like the ones I reported.

I still think ratio is the more intuitive control. We could perhaps initialize the ratio automatically to a value that generates no more than e.g. 100k faces? So that if you have a 1k mesh, the ratio is still 1.0 and it'll still generate 1K faces. But if you have 1m it becomes 0.1 by default and doesn't do anything excessive.

I'm also not sure how much this performance and memory usage depends on the input mesh vs. output mesh resolution.

If you're generating a low poly mesh from a high poly mesh, it would make sense to decimate the high poly mesh to e.g. 4x the low poly resolution before running QuadriFlow.

Philipp Oeser (lichtwerk) lowered the priority of this task from Needs Triage by Developer to Waiting for Developer to Reproduce.Sep 30 2019, 11:06 AM

Like an artist I vote for face count, is the first thing that I do every time.

An user rarely want a ratio of triangles, because rarely he knows the number of polygons of the model. He only want a clear number of polygons, because he know the final number that he needs.

In reality I don't understand why to use other mode than face count. More when quadriflow is not really good in create dense meshes.

I would say keep ratio as default, as Brecht already mentioned. QuadriFlow simply needs to get smarter and not overshoot the amount of quads it can produce. ZRemesher on average produces around 120-150k verts when used on a human looking model at max settings, which should be a decent goal to set for QuadriFlow. Trying to go beyond that will make it too taxing on pretty much any computer.

I don't see why don't use the face counts when Zremesher uses face count by default.

Face count by default makes more sense to me.