Parameterization of Triangulated Surface Meshes - cgal

I’d like to perform a surface parametrization of a triangle mesh (for the purpose of texture mapping).
I tried using some of CGAL’s algorithms, e.g. ARAP, Discrete Conformal Map etc.
The problem is that the surface parameterization methods proposed by CGAL only deal with meshes which are homeomorphic (topologically equivalent) to discs.
Meshes with arbitrary topology can be parameterized, provided that the user specifies a cut graph (a set of edges), which defines the border of a topological disc.
So the problem now becomes – how to cut the graph properly (using CGAL’s interface).
I found a similar question from 3 years ago that went unanswered.
P.S.
If someone can point me to a different library that can do the job, that’ll be just as great.
Thanks.

Related

OpenCascade: How to subdivide elongated triangles?

I am using OpenCascade to import STEP/IGES as meshes in my software. Works nicely.
But I need small triangles, and the one I get are sometimes very large (in flat area), or very elongated (eg. when meshing a cylinder). The best would be to split triangle's edge bigger than some absolute value. Avoiding T vertices, too.
I was'nt able to google anything about that... So, currently, I pass the mesh to OpenMesh, apply the OpenMesh::Subdivider::Uniform::LongestEdgeT operator, then pass it back to my software. Tedious and costly when I manage several M triangles...
Questions:
Is there an equivalent in OpenCascade ?
Or a simple code snipet to implement my own loop to do so ?
Thanks !
The meshing algorithm BRepMesh_IncrementalMesh coming with Open CASCADE Technology is mainly focused on two usage scenarios:
Visualization in 3D Viewer. Large and prolonged triangles make no harm to presentation, as vertex normals ensure proper smooth shading. Deflection parameters allows managing presentation quality.
Computing Algorithms using triangulation as approximation (to speed up calculations compared to the same algorithm working on exact geometry). In this case, deflection parameters determine the target precision of the algorithm. Large and prolonged triangles should not cause problems here, as deviation from exact geometry is controlled by meshing parameters.
There are, however, some categories of algorithms, where shape of mesh element is very important. Solvers (numerical simulation) make one of such categories, where unfortunate mesh elements may cause numerical instability or other issues. What exactly matters / cause issues depend on specific algorithm - this may include element skewness, element aspect ratio, element size and elements grid. Some solvers work much better on quads rather than on triangles.
If you take a look onto meshing result of BRepMesh_IncrementalMesh algorithm, you may notice that not only large prolonged triangles, but entire mesh structure is somewhat suboptimal for solver algorithms:
There are several options you may consider:
Triangulation refinement algorithm. Such algorithm processes existing triangulation and tries healing some properties like skewness. This what does OpenMesh from your question, I suppose. Such postprocessing algorithm might give satisfactory results at good performance, but final result will dramatically depend on properties of original meshing algorithm. For the moment, OCCT doesn't have any refinement tool, although it is possible writing such algorithm on your own (I cannot give you a small code snippet, because such algorithm is not that small an trivial as it may look from a first glance).
Consider alternative meshing algorithm. Probably incomplete list:
Express Mesh by Open Cascade (hence, working directly on OCCT shapes). This tool generates triangulation having nice grid-alike structure (for smooth surfaces), configurable element size and quad-dominant generation option. This is a commercial product though.
Netgen mesher. This open source tool provides bindings to OCCT, and although it is focused on 3D tetrahedral mesh generation, it may be also used for generating a common triangular mesh. I cannot say something good about this tool - it was rather slow and unstable when I've seen its work many years ago.
MeshGems surface meshing. Another commercial tool providing an interface to OCCT. Never worked with this product, so cannot share any opinion on it.
Consider improving BRepMesh_IncrementalMesh. As OCCT is an open source framework, you may consider extending its meshing algorithm with more parameters and contribute to the project.

CGAL cut cube with arbitrary surface

I'm new to CGAL and I'm trying to cut a cube with an arbitrary surface mesh in 3d (no self intersections, not closed/no volume). The goal is to get a volume which consists of one "side" of the cut cube, closed by the part of the surface inside the cube.
The surface itself consists of unordered triangles which should have the same winding order (consistent normal directions) but have no neighborhood information and could contain same points multiple times for different triangles.
I tried to use the clip function, like:
CGAL::Polygon_mesh_processing::clip(cube,surface,true);
Which of course does not work because the surface is not closed (as far as I understood). But It shows the idea on how the operation should work.
Boolean operations (https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#title14)) cannot be used for this as well since they are calculated on volumes and the surface has no volume.
I also thought about extending the outside of the surface so that it is closed. This, however, does not seem like a good approach.
Sadly, my research on similar problems was not successful.
I'm pretty sure that there is a nice way to do this in CGAL. Maybe someone with more experience in CGAL knows how to do this.
What would be the best approach for getting this volume?
Regards
EDIT:
By removing redundant points in my surface mesh I was able to get clip to work. Nevertheless, I do not always get the right side of the volume, even though the winding order should yield normals which point to the outside.
Is it necessary to calculate the normals and pass them as an extra parameter (see here) of the surface before the cut in order to always get the same "inner" side of the volume?
Also, the clip function seems to be quite slow. I have to do this cut for a very high number of cubes and different surfaces.
I use CGAL as header only lib and without GMP and MPFR, since it crashed my other application. How big is the speedup using these libraries and are there any other tricks which can be used to speedup computation, e.g. using parallelization?
I saw that CGAL uses Intel's TBB which. But in the header files which are included by the clipping algorithm CGAL_LINKED_WITH_TBB is not tested.
Thanks
It was a problem with the clipping mesh. Clipping could not be done properly. I increased it size and now it always intersects the volume.

Conversion of fine organic surface mesh to a few patches of NURBS

I have a very fine mesh (STL) of some organic shapes (e.g., a bone) and would like to convert it to a few patches of NURBS, which will be much smoother with reasonable simplification.
I can do this manually with Solidworks ScanTo3D function, but it is not scriptable. It's a pain when I need to do hundreds of them.
Would there be a way to automate it, e.g., with some open source libraries available? I am perfectly fine with quite some loss in accuracy. I use mainly Python, but I don't mind if it is in other languages and I can work my way around it.
Note that one thing I'd like to avoid is to convert an STL of 10,000 triangles to a NURBS with 10,000 patches. I'd like to automatically (programmatically, could be with some parameter tunings) divide the mesh into a few patches and then fit it. Again, I'm perfect fine with quite some loss in accuracy.
Converting an arbitrary mesh to nurbs is not easy in general. What is a good nurbs surface for a given mesh depends on the use case. Do you want to manually edit the nurbs surface afterwards? Should symmetric structures or other features be recognized and represented correctly in the nurbs body? Is it important to keep the volume of the body? Are there boundary lines that should not be simplified as they change the appearance or angles that must be kept?
If you just want to smooth the mesh or reduce the amount of vertices there are easier ways like mesh reduction and mesh smoothing.
If you require your output to be nurbs there are different methods leading to different topologies and approximations like indicated above. A commonly used method for object simplification is to register the mesh to some handmade prototype and then perform some smaller changes to shape the specific instance. If there are for example several classes of shapes like bones, hearts, livers etc. it might be possible to model a prototype nurbs body for each class once which defines the average appearance and topology of that organ. Each instance of a class can then be converted to a nurbs by fitting the prototype to that instance. As the topology is fixed the optimization problem is reduced to the problem where we need to find the control points that approximate the mesh with the smallest error.Disadvantage of this method is that you have to create a prototype for each class. The advantage is that the topology will be nice and easily editable.
Another approach would be to first smooth the mesh and reduce the polygon count (there are libraries available for mesh reduction) and then simply converting each triangle/ quad to a nurbs patch (like the Rhino MeshToNurb Command). This method should be easier to implement but the resulting nurbs body could have an ugly topology.
If one of this methods is applicable really depends on what you want to do with your transformed data.

CGAL 3D surface mesh generation for unbounded implicit surfaces

This is again a question about the CGAL 3D surface mesher.
http://doc.cgal.org/latest/Surface_mesher/index.html#Chapter_3D_Surface_Mesh_Generation
With the definition
Surface_3 surface(sphere_function, // pointer to function
Sphere_3(CGAL::ORIGIN, 64.0)); // bounding sphere
(as given too in the example code) I define an implicit surface given by 'sphere function' and a Sphere_3 of radius 8.
The difference is now, that the zeros of 'sphere function' are (contrary to its now misleading name) no longer bounded and inside Sphere_3. Instead 'sphere_function' represents an unbounded surface (think of x^2 + y^2 - z^2 - 1 = 0) and my intention is to triangularize its part that is in the Sphere_3.
In my examples up to now this worked quite well, if only for some annoying problem, I do not know how to overcome: The boundaries, where the implicit surface meets the Sphere, are very "rough" or "jagged" in a more than acceptable amount.
I already tried the 'Manifold_with_boundary_tag()', but it gave no improvements.
One road to improve the output that I am contemplating, is converting the triangulated mesh (a C2t3) into a Polyhedron_3 and this in a Nef_polyhedron and intersect that with a Nef_polyhedron well approximating a slightly smaller Sphere. But this seems a bit like shooting with cannons for sparrows, nevertheless I have currently no better idea and googling gave me also no hint. So my question: What to do about this problem? Can it be done with CGAL (and moderate programming effort) or is it necessary or better to use another system?
(Just for explanation for what I need this: I try to develop a program that constructs 3D-printable models of algebraic surfaces and having a smooth and also in the boundaries smooth triangulation is my last step that is missing before I can hand the surface over to OpenSCAD to generate a solid body of constant thickness).
The only solution I see is to use the 3D Mesh Generation with sharp feature preservation and no criteria on the cells. You will have to provide the intersection of the bounding sphere with the surface yourself.
There is one example with two intersecting spheres in the user manual.

Tetrahedralization from surface mesh of thin-walled object

I need to generate a tetrahedral (volume) mesh of thin-walled object object. Think of objects like a bottle or a plastic bowl, etc, which are mostly hollow. The volumetric mesh is needed for an FEM simulation. A surface mesh of the outside surface of the object is available from measurement, using e.g. octomap or KinectFusion. Therefore the vertex spacing is relatively regular. The inner surface of the object can be calculated from the outside surface by moving all points inside, since the wall thickness is known.
So far, I have considered the following approaches:
Create a 3D Delaunay triangulation (which would destroy the existing surface meshes) and then remove all tetrahedra which are not between the two original surfaces. For this check, it might be required to create an implicit surface representation of the 2 surfaces.
Create a 3D Delaunay triangulation and remove tetrahedra which are "inside" (in the hollow space) or "outside" (of the outer surface) with Alphashapes.
Close the outside and inside meshes and load them into tetgen as the outside hull and as a hole respectively.
These approaches seem to be a bit inelegant to me, and they still have some pitfalls. I would probably need several libraries/tools for them. For 1 and 2, probably tetgen or another FEM meshing tool would still be required to create well-conditioned tetrahedra. Does anyone have a more straight-forward solution? I guess this should also be a common problem in 3D printing.
Concerning tools/libraries, I have looked into PCL, meshlab and tetgen so far. They all seem to do only part of the job. Ideally, I would like to use only open source libraries and avoid tools which require manual intervention.
One way is to:
create triangular mesh of surface points,
extrude (move) that surface to inner for a given thickness. That produces volume (triangular prism) mesh of a wall,
each prism can be split in three tetrahedrons.
The problem I see is aspect ratio.
A single layer of tetrahedra will not reproduce shell or bending behavior very well. A single element through the thickness will already require a large mesh. Putting more than one will likely break the bank in order to keep aspect ratios and angles acceptable.
I'd prefer brick or thick shell elements to tetrahedra in this case. I think the modeling will be easier and the behavior will be more faithful to the physics.