Quadriflow integration

I created an addon called JRemesh with that you can use Instant meshes for quad based remeshing (GitHub - jayanam/jremesh-tools: Blender addon for quad remeshing)

I will integrate Quadriflow as well and I saw that an operator is included in Blender that is called Quadriflow. Then I compared the results of this operator with the Quadriflow application and got huge differences. I digged a bit into the Blender code and found out that the operator is an own quad extraction algorithmn and doesnt use Quadriflow, is that correct?

I also wonder why the Quadriflow code is included in the Blender sources, when it is not used at all.

Thx and best


I also am suspicious whether Quadriflow that is inside Blender works correctly, since the examples the original repository has look much better than the unusable thing that we have now.
Good work on making a bridge for instant meshes, gonna try it out!


Yes, give it a try, I got way better results than with the internal quadriflow operator. But as I said, the Blender internal quadriflow library does not use the “real” Quadriflow implementation.
You find the JRemesh addon and and installation instruction here also on the Blendermarket:

I also included the Quadriflow application into my addon (not comitted yet) and it is waaay faster and has better results. Will add it soon.


But as I said, the Blender internal quadriflow library does not use the “real” Quadriflow implementation

citation needed, where exactly in the code did you come to this conclusion?

1 Like

Have you seen this free addon that appears to do the same thing?

Ah sorry, I stepped through it and now I see it is using the external quadriflow parametrizer, ok. But then I dont know why the results differ that much when it comes to performance and topology compared to using the external application. Which version of quadriflow is included?

1 Like

the readme says 27a6867 but that seems to be a copy/paste error from the clew dep, so no idea…

@ZedDB can you shed some light here?

Well this rev. was for a patch, the integration of quadriflow was on Sep 13 2019 which seems fine cause then was the latest significant merge pull request to quadriflow repository.

@ZedDB can you shed some light here?

When I integrated quadriflow, it was using the latest upstream version that had any useful changes (the rest are essentially just clean ups). Jayanam discovered this as well.

At that time I also made sure that the output meshes were the same as in the standalone quadriflow program. I also made benchmark tests to make sure that the speed for conversion was the same, and it was (at least on my system).

Later on Pablo Dobarro made some changes to the code to speed up the conversion by using the symmetry axes in sculpt mode to only process half of the meshes and then mirror the result.
I guess this might be the differences you are noticing?

After integrating Quadriflow in Blender we discovered that the Quadriflow algorithm was not as stable and robust as you might think from reading the paper or looking at the examples posted on their website.
I looked into this myself as well and came to the conclusion that it wouldn’t be viable to try to fix these issues and that we should instead use an other approach that is not based on Quadriflow and in turn instant meshes. I also talked to the authors of Quadriflow and they confirmed that the issues we were seeing were issues with the algorithm and not implementation bugs.

There has been some newer quad remeshing papers that seems promising, but we have not had time to look into these yet.

One of them that could be interesting is the Monte Carlo geometry processing paper as they propose a method that can provide accurate local solutions (Instant Meshes and in turn Quadriflow calculates a global solution). That means that the Monte Carlo method could scale a lot better on huge input meshes and be much easier to multi thread.

In addition to this they also state that the method is a lot better at handling singularities in the cross field as they do not subdivide the input mesh to get sample points (like Instant Meshes and Quadriflow). In practice this should mean that it is less prone to “explosions” or distortions in the meshing result.

However to implement that paper there is a lot of work to be done.
There is an other paper is more practical and has the source code available now, is still actively developed, and has a Blender compatible licence (GPL3).

QuadWild seems very robust and doesn’t seem to suffer from the stability and robustness issues in Quadriflow (and to a certain degree Instant Meshes). So for quick results, I would go and test out that one and see if it could replace Quadriflow in Blender.

Let me know what you find out :wink:


Wow. I watched their video. And it looks very promising for the fact that it uses line features to generate meshes. I’m curious how it performs with organic models that have poor mesh quality…