Closed jdumas closed 5 months ago
Here are my explanations regarding your questions:
Constructing a Centroidal Voronoi Tessellation (CVT) requires repeatedly computing the Restricted Voronoi Diagram (RVD), defined as the intersection between a 3D Voronoi diagram given a set of seeds/sites and the input mesh surface. To calculate the exact RVD, the seeds/sites must always be on the input mesh, necessitating a projection step before each RVD calculation. One related work can be found at:
Yan, Dong‐Ming, Bruno Lévy, Yang Liu, Feng Sun, and Wenping Wang. "Isotropic remeshing with fast and exact computation of restricted Voronoi diagram." In Computer graphics forum, vol. 28, no. 5, pp. 1445-1454. Oxford, UK: Blackwell Publishing Ltd, 2009. (https://i2.cs.hku.hk/~gfxgroup/projects/remesh/index.html)
Yes, the CVT weights decay from the start of the optimization, as indicated in the paper. Additionally, the number of line search steps is typically limited to <5 at the beginning of the optimization and <2 as iterations progress, so the decay of the CVT weight will not have a significant impact. Please refer to Sec. 4.2 of the paper for a detailed explanation regarding the differences in the order of magnitude between these two energy terms.
This version of code only contains the termination condition at 50 iterations, please see README.md
:
In order to allow you to view the optimization process in more detail, we have only set the optimization stop at 50 iterations, you can manually stop the optimization, and view all iteration results in the data\LBFGSOUT folder.
Thanks for the answer @ningnawang
Thanks for the quick reply!
To calculate the exact RVD, the seeds/sites must always be on the input mesh, necessitating a projection step before each RVD calculation
I guess that's not exactly true. In the reference you mentioned, they distinguish between a constrained CVT (CCVT) and a RVD. In a CCVT the seeds are constrained to be on the surface, but that is not the case for a RVD in general. But anyway, I can see how the constrained version would work better on smooth input surfaces.
Hi! Thanks for sharing the implementation of your paper. I have a few questions about some of your implementation details and how they match the paper:
Surface Projection
https://github.com/Xrvitd/CWF/blob/bff182e94e3725a3799e76360532427ab3bbef0d/src/CVTLike/CVT.cpp#L406-L408
You seem to be projecting the optimized coordinates onto the surface before computing the RVD (and later on use the chain rule to get the proper gradient). I think you only mention that in your abstract, but otherwise this detail is absent from the paper. In the LpCVT paper and other work from Bruno Levy I don't think they constrain the sites to be moving on the surface. I was wondering if you could comment on that, whether it the projection is necessary or not?
Weight Decay
https://github.com/Xrvitd/CWF/blob/bff182e94e3725a3799e76360532427ab3bbef0d/src/CVTLike/CVT.cpp#L400
It seems that the CVT weight is being decayed at the start of the callback function. This is surprising because I think it will also decay the CVT weight during the linesearch in each Newton step. Is this an oversight or am I reading the code incorrectly?
Stop Condition
Eq. (11) in the paper indicates that you stop the optimization when the CVT energy increases above a certain threshold. I tried to look for this condition in the code, but I am not seeing it. Can you point me to where it is being set in the code?