I don't understand surface parameterization

[stla]

Hello,

I tried the Discrete_conformal_map_parameterizer_3. I firstly tried with the mesh of a half torus, and I got "Error: no one-to-one mapping". So I tried with the mesh of a half cube. Then I got a matrix of UV coordinates full of (0, 0) except 4 points:

What can I do with that?

That's not the first time I tried the surface parameterizations, and I always got strange results. I thought the UV coordinates could help to map for example a checkeboard texture on the mesh, but I don't see how to do that.

[MaelRL]

Could you please provide code & input data?

[stla]

Yes. Please wait, I deleted the OFF file and I have to redo it. In the meantime I applied the Loop subdivision to my half cube and here are the UV coordinates:

That looks better. But there's still a lot o (0,0).

[stla]

Here is the half cube:

And the code :

#ifndef _HEADER_
#include "cgalMesh.h"
#endif

#include <CGAL/Surface_mesh_parameterization/parameterize.h>
#include <CGAL/Surface_mesh_parameterization/Discrete_conformal_map_parameterizer_3.h>
namespace SMP = CGAL::Surface_mesh_parameterization;
typedef K::Point_2                                       Point2;

// [[Rcpp::export]]
Rcpp::NumericMatrix testparam() {
  const std::string filename = "halfcube.off";
  
  Mesh3 sm;
  if(!CGAL::IO::read_polygon_mesh(filename, sm))
  {
    std::cerr << "Invalid input file." << std::endl;
    return EXIT_FAILURE;
  }
  
  // A halfedge on the border
  halfedge_descriptor bhd = CGAL::Polygon_mesh_processing::longest_border(sm).first;
  
  // The 2D points of the uv parametrisation will be written into this map
  typedef Mesh3::Property_map<vertex_descriptor, Point2>  UV_pmap;
  UV_pmap uv_map = sm.add_property_map<vertex_descriptor, Point2>("v:uv").first;
  
  typedef SMP::Discrete_conformal_map_parameterizer_3<Mesh3> Parameterizer;
  
  SMP::Error_code err = SMP::parameterize(sm, Parameterizer(), bhd, uv_map);
  
  if(err != SMP::OK) {
    std::cerr << "Error: " << SMP::get_error_message(err) << std::endl;
    return EXIT_FAILURE;
  }
  
  const size_t nvertices = sm.number_of_vertices();
  Rcpp::NumericMatrix out(nvertices, 2);
  int i = 0;
  for(Mesh3::Vertex_index v : sm.vertices()) {
    Point2 pt = uv_map[v];
    out(i, 0) = pt.x();
    out(i, 1) = pt.y();
    i++;
  }
  
  return out;
}

halfcube.off.txt

[stla]

What's this joke? There's a lot of duplicated vertices.

[stla]

And here is the half torus, without duplicated vertices, clean. Error: no one-to-one mapping.

halftorus.off.txt

[sloriot]

Some parameterization expects only one boundary, that might be the reason.

[stla]

Ah ok. But it doesn't fail with the other half torus. I'm going to try the colors on the human face.

[stla]

This works with this human face

[stla]

Here is another half-torus, splitted in another direction. And it works.

> mesh$isValid()
[1] TRUE
> mesh$isValidFaceGraph()
Halfedge Graph Structure is valid.
Face Graph Structure is valid.
[1] TRUE
> mesh$isValidHalfedgeGraph()
Halfedge Graph Structure is valid.
[1] TRUE
> mesh$isValidPolygonMesh()
Halfedge Graph Structure is valid.
Face Graph Structure is valid.
Polygon Mesh Structure is valid.
[1] TRUE

halftorus2.off.txt

[stla]

Now, what am I supposed to do? I assigned a black color to each vertex with u < 0.5 && v < 0.5 or with u > 0.5 && v > 0.5. All other vertices are white. Here is what I get:

[stla]

Now I tried with an hemisphere. Only one border, guaranteed. But here is what I get:

[stla]

OH MY GOD I KNOW: THE ORDER OF THE VERTICES IS PERTURBED WHEN I WRITE THE OFF FILE !!!!!

[MaelRL]

I haven't had time to look at your issue, but see the maybe-relevant issue: #2994

[stla]

Maybe this is an additional issue, but the first one is that writing OFF or PLY file changes the order, even before I do the parameterization. I have to investigate that.

[MaelRL]

What do you use to write the file? The IO function of CGAL should preserve the order.

[stla]

I use CGAL::IO::write_OFF. And my mesh is EPECK.

[stla]

Yes, that was the problem !!!

[stla]

Here are my first 6 mesh faces:

> head(mesh$getFaces())
     [,1] [,2] [,3]
[1,]   31    2    1
[2,]   32    3    2
[3,]   33    4    3
[4,]   34    5    4
[5,]   35    6    5
[6,]   36    7    6

Then I observed that the first 6 vertices in the OFF file are vertices 31, 32, 33, 34, 35, 36.

[stla]

I think I know: that's because I do a copy_face_graph before writing. The goal is to convert EPECK to EPICK because there's a bug when writing an EPECK mesh to a binary PLY file. And copy_face_graph changes the order.

[stla]

And by the way, since the upgrade to 5.5.2, I cannot read anymore a PLY/OFF file, this crashes the session. This perfectly worked with 5.4.2.

[stla]

Here is the disk of uv-coordinates for the Enneper surface:

As you can see, I colored it with a checkerboard, by grouping the points in squares [0, 0.25] x [0, 0.25] etc. The lines of the checkerboard are not very regular. As a consequence, when I color the corresponding vertices on the 3D mesh, I retrieve these non-regular lines:

Is there a way to make the lines regular? Of course the quality increases if I add some vertices, but is there another way?

[stla]

Wow, I did an isotropic remeshing (but not with CGAL yet) before the parameterization, top!

[stla]

Now I did it with CGAL.

But why do we see "radial" lines (especially in the blue)?

[stla]

But why do we see "radial" lines (especially in the blue)?

Ooohh because there's no normals!

[stla]

Look at this twisted horn. The UV-circle is fully textured with a checkerboard. But the blue squares appear only at the bottom of the horn. Any idea why?

[stla]

ARAP has crashed the session.

[stla]

Strange, it always crashes. Segfault "memory not mapped".

[stla]

ARAP works now (it was slow):

Indeed, the angles are clearly not preserved, but the areas are not preserved too. Maybe one has to play with the parameter lambda?

I don't understand why this mesh does not appear smooth while it has normals and more than 500000 faces.

[MaelRL]

The lambda gives control between angle and area. As lambda goes to infinity, you get more and more rigid (area preserving), but by default it should already be "quite rigid" (1000). You can also try the iterative authalic parameterizer.

[stla]

I don't think so. I read the doc. The lambda controls the balance between the angles and the shape, not the area. Maybe I misread but I don't think.

I tried the IAP but it is too slow, I abandonned.

Still I don't know why this mesh does not appear smooth but after a slight shape smoothing it is perfect. Maybe it's the isotropic remeshing which breaks the smoothness?... aahhh I understand right now: the isotropic remeshing adds some vertices on the faces, so it does not change the shape, and the mesh does not appear smooth because before the isotropic remeshing it has not a lot of faces.

[stla]

I have some plans for today: some animated textures. A rotating radial checkerboard, and a checkerboard transformed by a Möbius transformation. Prepare your eyes.

I still tried ARAP, it has always crashed. Wondering whether it is bugged.

[stla]

First, here is a small experiment.

There is a conformal map between the square and the disk. So I did a checkerboard on the square and I transported it to the disk with this map. The result is the right figure:

Then I mapped these two circular checkerboards to the Enneper surface, with the conformal parameterization:

Do you see any striking difference? Not very conclusive... Time to go to the next experiment.

[stla]

Here is the first promised animation.

[stla]

The second promised animation. I take a Möbius transformation of order 2 (i.e. M^2=Id). Here is for example the transformation of the radial checkerboard with M^(1.5):

Then I use M^t for the animation, with t varying from 0 to 2:

[stla]

Costa surface. It has several borders but the DCP works.

[stla]

I mapped an image! Terrific!!

[stla]

[stla]

Togliatti surface

[stla]

Hmm, something strange. Usually when I do a parameterization with a circular border, the UV space I get is a disk centered at (0.5, 0.5) and having radius 0.5. But now, I've just done an ARAP parameterization, and I get a different disk:

Is it normal?

[stla]

And I also get this disk with the border parameterizer SMP::Square_border_uniform_parameterizer_3<Mesh3>!

[stla]

Stupid of me, this is a border-free parameterization! I confounded with the DAP I think.

[stla]

The Sudanese Möbius band. Unfortunately, this mesh has a "cut", and it breaks the harmony. In fact this cut separates the back side from the front side.

[stla]

I started to write a vignette for my package, about the parameterizations. A vignette of a R package is a short documentation. There is some documentation inside the package but the vignette allows to write more details and is more convenient.

If you want to take a look, and if you have some feedback it would be welcome.

This is a HTML document converted to PDF, this is why there are some breaks.

Parameterizations of surface meshes.pdf

[stla]

I've just tried the orbifold borderless parameterization. I used this mesh, with the three cones shown in red:

Then I got this uv-space:

How can I use such a parameterization? The points do not fill a nice shape. Maybe I did something bad?

[MaelRL]

As ARAP and some other parameterizers, it's a free border parameterizer. It has the advantage that the parameterization is a canonical domain that tiles the 2D space, and you get a seamless parameterization.

See https://noamaig.github.io/html/projects/orbifold/orbifold_lowres.pdf, e.g. Fig 2.

[stla]

Not sure to understand. Can we map a texture with such a strange parameterization? I don't see how to do.

[MaelRL]

You can check the parameterization plugin in the demo: https://github.com/CGAL/cgal/blob/master/Polyhedron/demo/Polyhedron/Plugins/Surface_mesh/Parameterization_plugin.cpp and in particular the class Scene_textured_surface_mesh_item.

[stla]

Thanks, I will try to understand that. In the meantime, I took one half of my star to do an easy DCP :)