VOLMAP: a Large Scale Benchmark for Volume Mappings to Simple Base Domains

Correspondences between geometric domains (mappings) are ubiquitous in computer graphics and engineering, both for a variety of downstream applications and as core building blocks for higher level algorithms. In particular, mapping a shape to a convex or star-shaped domain with simple geometry is a fundamental module in existing pipelines for mesh generation, solid texturing, generation of shape correspondences, advanced manufacturing etc. For the case of surfaces, computing such a mapping with guarantees of injectivity is a solved problem. Conversely, robust algorithms for the generation of injective volume mappings to simple polytopes are yet to be found, making this a fundamental open problem in volume mesh processing. VOLMAP is a large scale benchmark aimed to support ongoing research in volume mapping algorithms. The dataset contains 4.7K tetrahedral meshes, whose boundary vertices are mapped to a variety of simple domains, either convex or star-shaped. This data constitutes the input for candidate algorithms, which are then required to position interior vertices in the domain to obtain a volume map. Overall, this yields more than 22K alternative test cases. VOLMAP also comprises tools to process this data, analyze the resulting maps, and extend the dataset with new meshes, boundary maps and base domains. This article provides a brief overview of the field, discussing its importance and the lack of effective techniques. We then introduce both the dataset and its major features. An example of comparative analysis between two existing methods is also present.


Introduction
One-to-one correspondences (mappings) between geometric domains are the underlying workhorse of countless downstream applications in graphics, engineering and medicine, where they are used to transfer signals of various kind from one domain to the other. Of particular interest for many of these applications are the mappings to parametric domains with simple topology and geometry, such as convex polygons [FH05], spheres [GGS03], grid spaces [BLP * 13, PCS * 22] or simplexes of base domains that are used for cross-parameterization [HPS08] and morphing [Ale02].
These basic mappings are in fact used as atomic building blocks in many higher level pipelines, where it is often required solving numerous instances of these problems, on input data for which very little assumptions can be made (in the wild). For this reason, mapping methods to base domains are expected to operate as trusted black-boxes, that is, to be both efficient and unconditionally robust.
While for the surface case there exist robust methods that fulfill these requirements [Tut63,Flo97,GGT06,SJZP19,Liv23a], none of these approaches currently extends to 3D, making the fully robust computation of injective volume mappings a prominent open problem for practitioners in graphics and engineering [FSZ * 21, NNZ21]. Indeed, the volume mapping problem has been the subject of extensive research in recent years, but satisfactory solutions to this problem are still lacking (Section 2).
In this paper we introduce VOLMAP (volmap.github.io): a dataset aimed to support ongoing research on volume mapping to simple base domains. VOLMAP comprises 4.7K input tetrahedral meshes, all endowed with a set of boundary mappings to a variety of alternative simple base domains, such as cubes, tetrahedra, pyramids, octahedra, spheres and, following the capabilities of recent constructive methods for provably injective mapping [Liv23a,NCB,HC], also star-shaped domains. Overall, VOLMAP amounts to more than 22K alternative inputs for algorithms, which are then required to complete the boundary map we provide by positioning interior vertices inside the base domain, generating an injective volume map. In addition to this, we also release various scripts and code to assess the quality of the generated results, compare to alternative methods, or enrich the dataset with additional meshes, boundary maps or base domains.
Connecting to the evaluation criteria listed in the call for dataset papers, VOLMAP is: • Novel: no alternative dataset for the same task was ever released.
Large scale datasets of volumetric meshes were already released for the related problem of untangling a tetrahedral mesh containing inverted elements (e.g., [DAZ * 20, DKZ * 22]). However, since most of these meshes are not convex or star-shaped, they cannot be used for the task that we aim to support; • Impactful: considering the centrality of volume mappings in many tasks, the growing amount of articles published in recent years, and the lack of input data, we expect VOLMAP to have a significant impact in the graphics community and other communities alike. While there cannot be guarantees in this regard, we observe that prior large scale datasets such as Thingi10K [ZJ16] have arguably increased the evaluation standards, becoming a de facto mandatory validation step for diverse algorithms that make claims on scalability or robustness [HZG * 18, HSW * 20, CLSA20, LPC22, CPAL22, DA21, TNK22, TBFL19, FDBH22, DAZ * 20, GSC21]. With VOLMAP, we wish to extend this practice also to volume mesh processing, contributing to the creation of truly robust volume mapping algorithms; • Accessible: VOLMAP data will be hosted at the servers of CNR IMATI. Prominent datasets of 3D shapes in our community have already been hosted at the same institution for many years † , thus guaranteeing the reliability and permanent accessibility to the data. Considering the large number of meshes and additional information contained in VOLMAP, the dataset is split into † http://visionair.ge.imati.cnr.it smaller thematic chunks that can be downloaded separately. For file formats, all input meshes are in the popular MESH format, and conversion facilities to alternative VTK formats are also provided. MESH and VTK are arguably the two most widely used file formats to exchange volume meshes in our community, and are largely supported by existing academic and commercial tools.
• Ethical: data in VOLMAP was mostly created by processing previously existing meshes included in other datasets, performing tetrahedralization and boundary maps as detailed in Sections 4 and 5. Prior to collecting data, we ensured that all the sources we considered did not prevent the processing or redistribution of their models with a restrictive license.

Field Overview
The goal of this section is to provide the reader with a comprehensive overview of topics related to volume mapping to simple base domains. We first discuss methods for the generation or repairing of injective mappings, emphasizing the lack of robust volume techniques and the inability to extend the existing surface methods to volumes (Section 2.1). Then, we briefly mention relevant volume pipelines that rely on the existence of injective volume mappings (Section 2.2), also discussing related datasets that were released to the community to support research in these areas.

Existing Mapping Methodologies
For simplicial complexes of dimension 2 (triangle meshes), fully robust methods to map a surface with simple topology to a convex domain have been known since 1963, when Tutte introduced his celebrated embedding [Tut63]. Geometric and topological relaxations that extend the applicability of Tutte [GGT06,WZ14,XCGL11] or that offer superior robustness against limited precision floating point implementations [SJZP19] have also been proposed. However, none of these methods is applicable to simplicial complexes of dimension 3 (tetrahedral meshes), leaving the volume mapping problem largely unsolved.
Tutte 3D. Trivial extensions of the Tutte embedding to three dimensional spaces are notoriously prone to failures. A variety of failure examples have been shown in literature [CDL95,CSZ16,DVPV03], also for trivial meshes containing only four boundary and two internal vertices [FP06,Liv20a]. Chilakamarri and colleagues conjectured that a subclass of graphs for which the Tutte's theorem extends to 3D exists, without formalizing it [CDL95].
Only recently, Alexa proved that 4-connected graphs not having K 6 and K 3,3,1 minors admit a valid three-dimensional Tutte embedding [Ale23]. However, quoting the author, "this result has little direct consequence on the practice of using the commonly generated tetrahedral meshes for creating PL mappings: almost all of them have a K 6 minor and, consequently, a convex combination mapping will likely not be an embedding". In Section 8, we test Tutte 3D on our benchmark, verifying that in all our experiments the so generated maps contain inverted elements.
Progressive Embeddings. Floating point implementations of the (2D) Tutte embedding may fail to produce an injective map due to numerical cancellation errors. Shen and colleagues extended the seminal idea of progressive meshes [Hop96] to the generation of simplicial mappings, obtaining higher practical robustness. They called their algorithm Progressive Embeddings [SJZP19]. This method operates by first removing all inverted elements from an existing input map through a sequence of edge collapses and then insert back all the previously removed elements by means of vertex splits, ensuring that no vertex insertion changes the orientation of its incident triangles, thus ensuring injectivity. Despite the main ingredients of this algorithm (edge collapse, vertex split) are well defined also for tetrahedral meshes, extending Progressive Embeddings to the generation of volume maps seems overly complex. In fact, differently from triangle meshes, tetrahedral meshes cannot always be collapsed through a sequence of edge collapses, and even deciding whether a given mesh is collapsible is an NPcomplete problem [Tan16,MF08,ADGL16]. Barycentric subdivision ensures collapsibility [AB20] but, even if a valid collapsing sequence of a refined mesh is guaranteed to exist, the size of the search space is exponential w.r.t. the number of mesh edges. Failed attempts to heuristically compute a valid collapsing sequence are reported in [Liv20a,Liv20b]. According to [LN21], the chances to get stuck at an incollapsible configuration along a randomly selected collapsing sequence grow exponentially with the number of simplexes in the mesh.
Numerical approaches. Considering the limits of topological approaches, to date, the most reliable methods for the generation of volume maps is through numerical optimization. As detailed in two recent surveys on the topic [FSZ * 21, NNZ21], numerical methods compute injective mappings by solving difficult non convex problems. The vast majority of existing approaches solves directly for the xyz coordinates of the mesh vertices. However, explicitly imposing injectivity in this formulation yields cubic constraints, making the numerical problem impossible to optimize with any existing solver. A variety of relaxed formulations that promote injectivity without strictly imposing it have been proposed over the years [AL13, KABL14, KABL15, FL16, SFL19, SLS22, ASGS22, NZZ20,OKN21,POK23,DAZ * 20,GKK * 21], often showcasing remarkable results even on extremely challenging tests. In Section 8, we tested the authors' implementation of [DAZ * 20] on a portion of our dataset: in 34% of the cases it fails to produce an injective map. This emphasizes the complexity of the problem we consider, also suggesting that numerical methodologies that do not offer strict theoretical guarantees of correctness are perhaps intrinsically too brittle to reliably compute mappings to simple base domains. A critical aspect of methods in this class is that they often assume that the input mesh connectivity is fixed. As shown in recent research, this assumption hinders the overall robustness of mapping methods, who often need to refine the mesh to open the space of solutions and permit the existence of a valid mapping [Liv23a,NCB,HC]. VOLMAP is designed to test algorithms also on this aspect, providing inputs for which an injective mapping is not guaranteed to exist for a fixed mesh connectivity.
Foliations. Campen and colleagues propose a topological method to construct bijective volume mappings to cubes and spheres [CSZ16] based on simplicial foliations. To date, this is the only published method that is guaranteed to produce a valid map. However, the algorithm applies only to bi-shellable simplicial complexes and, most importantly, the maps it generates are not piecewise linear. In the article, the authors discuss a technique to convert their mappings into a piecewise linear form, but this operation involves huge refinement steps that trigger mesh growths even by orders of magnitude, making this algorithm hardly usable in practical cases. Since its introduction in 2016, we are not aware of any method that internally uses it to compute volume maps. Another foliation algorithm for volumetric mapping to spheres was presented in [CBC19]. However, in this case the approach is numerical, hence it does not provide guarantees of correctness.

Applications that Enjoy a Volume Map
Volume mappings to simple geometric domains play an important role in a variety of applications. Here we briefly mention a few important ones.
Solid Texturing. Mapping a mesh to the unit cube is used for solid texturing, which is the analog of 2D texturing in UV mapping [PCOS10]. 3D textures are typically used to design the interior material of objects that would break or be sliced, showing their internal structures [TOII08]. This is relevant to model wood, stones, fruits, but also tissues in medical applications [DFRVDVM14]. Solid texturing is also used in advanced manufacturing to map atomic elements of periodic microstructures inside objects [PZM * 15, SBR * 15, ABC * 19], obtaining lightweight pieces with a controlled physical response. Furthermore, cube mappings are also relevant in CAD, where IGA methods exploit them to fit tensor product splines for the numerical resolution of PDEs [ZC21, YLSF21, LYLF20].
Low Distortion Injective Mappings. Mappings to convex domains are a fundamental building block in pipelines that generate low distortion injective maps to generic shapes. These methods operate by first computing a highly distorted but provably injective map to a convex shape. Then, they iteratively reduce distortion by relaxing vertex positions, using line search to prevent the introduction of inverted elements. This technique was pioneered in [SS15] and then extended in many subsequent works [RPPSH17,LYNF18, JSP17,SYLF20,FW22], also for structured meshing [Liv23b]. Due to the lack of robust methods to map a volume to a convex domain, these methods are currently applicable only to surface meshes, where the initialization step is performed using Tutte or similar techniques [Tut63,SJZP19]. For the case of volumes, it has only been validated for tetrahedral mesh improvement ( Figure 18 in [RPPSH17]), because this application does not require the generation of the initial valid map.
Shape Correspondences. Algorithms for the computation of shape correspondences or morphing between shapes rely on the existence of an underlying injective map. Prominent methods in this field operate on intermediate base domains for cross parameterization, consisting in a coarse simplicial complex where both shapes are mapped. Each shape is first decomposed into an atlas of charts. Each chart is then assigned to a face of the base domain and mapped to it using Tutte [Tut63]. Correspondences are therefore constructed as a global (chart-wise) cross-mapping between all the shapes that map to the same base domain. This simple yet effective idea has been extensively used to generate cross-mappings between shapes [LSS * 98, GVSS00, PSS01, KLS03, SAPH04], also supporting arbitrary positional constraints [KSG03,SJZP19]. An extension to volumetric cross-mappings using coarse tetrahedral meshes as base domains seems feasible and likely useful, but once again, the lack of robust volume mapping to a tetrahedron prevents the realization of this neat idea. The tetrahedron is one of the base domains we consider in VOLMAP.
Hexmeshing. Not only single cubes, but also mappings to assemblies of cubes are important. In hexahedral mesh generation, these spaces are used to generate a conforming all-hex mesh connectivity that is then projected inside a target shape through an injective map. hosts challenging tetrahedral meshes that can be given in input to these methods. None of these datasets are aimed to support research on the more specific problem that we tackle in VOLMAP. It should be noted that, in the general case, the domains used for hexmesh generation are not convex or star-shaped, therefore they fall outside the scope of VOLMAP. Nevertheless, due to their grid structure they can be easily split into (sub) mappings to single cuboids, thus benefitting from advancements in this field.

Anatomy of VOLMAP
The VOLMAP dataset is composed of three main ingredients: • Meshes: we collected 4700 tetrahedral meshes with simple topology (genus zero) from various data sources (Section 4). These meshes exhibit a significant variety in resolution (from 1K to more than 1M elements) and a large variety of geometries and features, spanning from CAD to free-form shapes, scanned objects, and artificial models designed for 3D printing and other applications; • Boundary Maps: the boundary of each tetmesh is associated with a set of surface maps to alternative convex or star shaped domains. For most of the models, we provide mappings to five canonical polyhedra, that is: tetrahedron, cube, pyramid, octahedron and star (Fig. 1). For models that were collected from datasets released with mapping methods, such as [PH03, DAZ * 20], we also provide surface mappings to spheres and simple (star-shaped) polycubes; • Tools: in addition to meshes and boundary maps we also release a variety of tools for quality assessment and to support dataset extensions. This includes: C++ code for the computation of inverted elements, mesh distortions, tetrahedralization, and generation of new boundary maps, possibly on brand-new base domains, as well as scripts to batch process the whole (or a selected portion) of the dataset. A tool for the visual inspection of the generated maps and to plot inverted elements and color-coded distortion metrics is also included in the package.
Intended usage. VOLMAP is designed to provide input data for volume mapping algorithms that operate under strict boundary conditions. As discussed in Section 2, this is relevant for a broad variety of applications. Given a tetrahedral mesh and a surface mapping associated to it, candidate algorithms are expected to compute a volume mapping that positions boundary vertices as indicated by the input surface map, solving for the position of internal vertices so as to generate a piecewise linear injective mapping, that is, a mapping where the linear transformation associated to each tetrahedron does not flip its orientation. A natural consequence of the proposed setup is that the mapped mesh precisely interpolates the target domain without possibility to deviate from it. To this end, VOLMAP is mostly focused on the validity of the map and not on its geometric fidelity, which is given for granted. Nevertheless, the benchmark could also be used to asses methods that partially relax boundary conditions (e.g. permitting tangential smoothing along the flat faces or the sharp creases of the boundary domains). No tools to measure geometric fidelity are provided. Considering the number of meshes in the dataset and the boundary mappings associated to them, overall VOLMAP provides 22642 diverse inputs for benchmarking volume mapping algorithms. It should be noted that these mapping tasks are not guaranteed to be well posed, meaning that a piecewise linear injective map of the input meshes may not exist. This is a wanted feature of the dataset, which aims to evaluate the ability of candidate algorithms to employ local mesh refinement to open the space of solutions and provide a valid mapping. As observed in multiple recent works local refinement is an unavoidable step to ensure unconditional robustness, but maintaining mesh growth within practical bounds remains an open unsolved challenge for volume meshing algorithms [CSZ16, HC, NCB].
File structure. i.e., each surface vertex is encoded in a line of text, reporting its vertex id in the tetrahedral mesh and its prescribed coordinates in the base domain. Vertex ids start from zero. Note that this is the same indexing that users would find in any mesh data structure for geometry processing, but it is not the convention used internally by the .mesh format, which enumerates vertex indices starting from 1. Once again, VOLMAP provides all the necessary utilities to process data in this format.

Data sources
Meshes in VOLMAP have been collected by a variety of alternative sources, sometimes already composed of tetrahedral volume meshes, some other times composed of triangular surface meshes that were originally assembled for other tasks. In this section, we provide details regarding the source data for each mesh group in Table 1, also clarifying the format of the original data and the type of processing that was necessary to import the models into VOLMAP.
G1. This group contains tetrahedral meshes that were originally contained in a dataset released with [FBL16], where they were used for the generation of volumetric maps in the context of polycube mesh construction. The original dataset counts 106 models, from which we extracted 25 meshes with genus zero. Most of these models are freeform and do not contain sharp features. For the most part, these are well known models in the field, that already appeared in numerous articles prior to be released in this specific dataset.
G2. This group contains a subset of 67 models used in [YFL19] for generating surface polycube mappings. As for the group before, the original dataset contains a higher number of shapes, but only those with trivial topology have been incorporated in VOLMAP. Differently from group G1, meshes in G2 were originally triangle meshes, and we transformed them into volumetric meshes using TetGen [Si15] with the Yq flags. The class of shapes in this group is the same as G1.
G3. This group contains 1942 meshes from Thingi10K [ZJ16], a large scale dataset that collects thousands of triangle meshes, ranging from toys to abstract and mechanical shapes, originally designed for 3D printing. Most of the meshes in Thingi10K contain a variety of geometric and topological defects, such as open boundaries, non-manifold edges and vertices or self-intersections. For this reason, we considered the clean version of the dataset, which was provided by the authors of [HZG * 18], and we used Tetgen [Si15] to tetrahedralize them, using the Yq flags. Overall, the dataset con- G4. This is the largest group of meshes in VOLMAP. It contains 2633 models taken from the dataset released by the authors of [DAZ * 20], and originally distributed by [LYNF18]. This dataset contains shapes of heterogeneous classes (noteworthy is the presence of a big group of humanoids and characters that were not present in previous groups). Since they were originally released to support research in uv mapping and injective surface mappings, the original meshes were mostly topological disks. Luckily, most of these meshes were obtained by starting from a watertight model and cutting it open along a cut graph. For all models generated with this procedure we could therefore reconstruct the original watertight mesh by merging coincident vertices, thus restoring the original topology. In case the so generated mesh had genus zero, we completed the processing by tetrahedralizing it with TetGen [Si15] using the Yq flags and including it in VOLMAP.
G5. In this group we collected all mappings to spheres that we could grasp from previously released data. This amounts to 20 volume sphere mappings from [DAZ * 20] plus 6 surface sphere mappings computed with [PH03]. For the latter, we transformed the input surface meshes into tetrahedral meshes using TetGen [Si15] with the Yq flags.
G6. This group contains 4 models that realize a polycube mapping to a convex or star shaped polycube. These were obtained by processing existing polycube mappings from [YFL19,FBL16] and retaining only polycubes that had a non empty kernel. The kernel (or absence thereof) was checked with [SBS22].

Boundary Maps
In this section, we provide details on how the boundary of the tetrahderal meshes in groups G1-G4 have been mapped to the simple domains shown in Fig. 1. Meshes in groups G5 and G6 are not Figure 3: Base domains (red) are embedded in the input shape by fitting them into the mesh bounding box (black). Specifically, each base domain corner is assigned one or a linear combination of the bounding box corners, and is eventually associated to the mesh vertex that is closest to it. considered because they were already endowed with a mapping to a spherical or polycube base domain.
Computing the boundary maps amounts to solving two problems: (i) embed the graph of the base domain on each tetmesh; (ii) map the elements of the chartification induced by such embedding inside each face of the base domain. A pictorial illustration of this pipeline is shown in Fig. 2. Graph Embedding. Embedding an abstract graph in a mesh is a complex combinatorial problem that may easily produce undesirable poor geometric results [BSK21]. Similarly to existing approaches, we heuristically proceed by first mapping graph nodes to mesh vertices, and then embedding graph arcs in the mesh, defining them as chains of edges connecting the images of their associated graph nodes.
Corners of the base domains are mapped to the mesh by exploiting a correspondence between the topological cube in the left part of Fig. 2 and the eight corners of the mesh bounding box. Once such a correspondence is established, nodes of the base domains are mapped to the mesh by simply locating the vertices that are closest to one (or to a linear combination of) the bounding box corners (Fig. 3). Specifically: • cube nodes are associated to the mesh vertices that are closest to each bounding box corner; • tet nodes are associated to the mesh vertices that are closest to a bounding box corner and to its three adjacent vertices; • pyramid nodes are associated to mesh vertices that are closest to the four bottom corners of the bounding box, plus the vertex closest to the centroid of its upper face; • octahedron nodes are associated to the mesh vertices that are closest to the midpoint of the four vertical edges of the bounding box, plus the points closest to the centroid of its top and bottom faces; • star nodes are associated to the mesh vertices that are closest to all eight corner of the bounding box, plus the centroid of all its faces. Figure 4: During graph embedding we always split edges (green shaded) connecting previously embedded graph arcs (in red). We do this both around graph nodes (top) and in narrow passages between adjacent arcs (bottom). This refinement permits to always embed a new graph arc passing in between two previously embedded ones (right column).
Once all nodes of the base graph have been mapped, we proceed by heuristically inserting one arc at a time, using Dijkstra's algorithm [Dij59] restricted to operate only on the surface edges of the tetrahedral mesh. As shown in [BSK21], the ordering at which arcs are inserted in the mesh may have a dramatic impact on the quality of the embedding, because each insertion creates a non intersection barrier for the subsequent ones, possibly resulting in significant deviations when connecting two nodes of the graph. We avoid excessively distorted results by exploiting local mesh refinement, ensuring that for any pair of embedded arcs there always exists a fully disjoint chain of edges that passes in between them and that can be used for embedding a new arc, if needed (Fig. 4). Note that since our meshes are volumetric, the necessary split operations are performed on the tetrahedral mesh and not only on the surface. Also note that, because of this refinement, tetrahedral meshes in VOLMAP are not identical to the meshes in the source datasets listed in Section 4. In particular, for each model we calculate all the separatrices required for the maps to all five domains, so that the  Fig. 1 (right, red edges). Mesh growth was around 5% (from 12601 to 13238 tetrahedra). Model: duck.mesh from group G1.
connectivity of the mesh is modified only once and the same mesh is mapped to all the available domains. Fig. 5 shows an example of mesh structure before and after refinement.
Mapping. Emebdding the graph of each base domain induces a chartification of the mesh surface, which can be trivially computed by exhaustively flooding the surface triangles by starting at a seed and propagating to adjacent triangles without crossing edges associated to a graph arc (Fig. 1). Once a chartification is computed, the boundary mapping is completed by positioning inner vertices of each chart inside the convex faces of the base domain, using the Tutte embedding.
Sanity checks. Despite provably correct, floating point implementations of Tutte 2D may generate vanishing or inverted triangles, preventing the construction of a valid map [SJZP19]. Since surface mappings will be used as strict boundary conditions to initialize a volume map, it is important to ensure that the mapping is fully injective, so as to permit the generation of a valid volume map. To verify the correctness of each result we generate a tetrahedral mesh of each base domain by adding an interior point at the centroid of each polytope and then forming tetrahedra joining such vertex with all boundary triangles. We then use exact orientation predicates [She97] to verify that all the so generated tethrahedra have coherent orientation. Meshes where this check fails are excluded from the dataset. The existence of failures of this kind explains why the number of models in each group reported in Table 1 is slightly higher than the number of actual mappings to each base domain. Missing boundary maps are the ones who failed to be injective due to numerical issues in the computation. Note that while for all the target domains currently considered in the dataset the centroid is contained in the kernel, this property may not hold for alternative more complex star-shaped domains. In this case, the kernel can be explicitly computed -e.g., with [SBS22] -and the kernel centroid used to generate the tetrahedral mesh. Figure 6: Snapshot of the visual tool used to inspect a given volumetric mapping, based on [Liv19]. In this example elements are color coded w.r.t. the MIPS 3D geometric distortion, but other distortion metrics can also be chosen. Meshes can be sliced with a cutting plane to inspect the interior of the mapping. Model: maxplanck.mesh from group G6.

Tools
Besides tetrahedral meshes and their associated boundary mappings, VOLMAP includes a variety of facilities to ease the processing of the dataset, help assess the quality of its results and also extend it with additional models, maps and base domains. In this section, we list and briefly introduce all such tools. All the software facilities we provide are implemented in C++, have minor self-contained external dependencies and can be easily (and automatically) be compiled with CMake on MacOS, Windows and Linux.
Tetmesh checks. This tool ensures that tetrahedral meshes in VOLMAP encode their elements according to the correct convention. Indeed, a tetrahedron can be fully encoded by the list of its four vertices in two alternative ways: given the first three vertices, the fourth one can be positioned either on the positive or the negative half-space defined by the previous three. From the perspective of the correctness of the mapping, either choice is valid. What is important is that the orientation of all mesh elements is globally coherent. However, many algorithms make assumptions on these orientations, often expecting a positive one. In case the input mesh follows the opposite convention, this tool flips all its elements, making it compatible with the VOLMAP orientation of choice.
Surface Mapping. This tool implements the graph embedding strategy described in Section 5. The software only depends on CinoLib [Liv19], which is internally used for low level volume mesh processing. Besides the ability to map new tetrahedral meshes to the previously existing base domains, the tool can also be used to define new simple base domains to be included in the dataset. For this latter task, practitioners can provide the description of a novel abstract graph, an embedding of it, and a point within its kernel. The software will then automatically proceed to embed the graph nodes and arcs onto the surface connectivity of the mesh in the pre-scribed order, also mapping the surface patches of the embedded graph onto the facets of the base domain.
Surface Mapping Check. This tool takes as input a boundary mapping computed with the previous tool and constructs a tetrahedral mesh of its interior to verify that all tets have strictly positive orientation, as detailed in Section 5. This can be used to ensure that additional maps added to VOLMAP fulfill all the necessary correctness requirements.
Metrics. This tool inputs a volume mapping computed with a candidate algorithm and returns information regarding its validity and geometric distortion. For validity, exact orientation predicates [She97] are used to verify that the linear map associated to each tetrahedron has a positive determinant. For geometric distortion, the tool computes the per element distortion energy according to a variety of metrics, such as Conformal [LPRM02], ARAP [LZX * 08], MIPS 3D [FLG15], Dirichlet and Symmetric Dirichlet [SS15]. The global distortion energy for each such metric is also returned. This is computed as the normalized sum of per element distortion energies, weighted by the volume of each input tetrahedron. Output mesh size, and in particular its ratio with the input mesh size, can also be regarded as an evaluation metric for methods that employ mesh refinement to ensure the existence of a solution. Such a refinement is in fact aimed to be minimal. Finally, in addition to map metrics, we also give the possibility to measure the per element quality of the input or output mesh, measured as the normalized ratio between the incircle and the outcircle, as described in the Verdict Library [SEK * 07] ( §6.11). In particular, the input mesh quality may be an indicator of the toughness of the mapping task, especially for numerical methods that solve for the vertex coordinates.
Map Visualization. This is the only visual tool provided in VOLMAP. It can be used to visually inspect a volume mapping, plotting its inverted elements and color-coding tetrahdera according to some geometric distortion. A variety of volume inspection tools are supported, such as slicing along axis aligned planes, filtering by per element quality or manual selection of mesh elements to be shown/hidden. All previously mentioned distortion energies are supported and can be selected through the user interface. A screenshot of the application is shown in Fig. 6.
Tetmeshing. This is a simple wrap of Tetgen [Si15] that is included in the package to make it self-contained, and to easily allow pratictioners to generate new volume data starting from existing surface meshes.
Scripts. Python scripts to execute the aforementioned tools on large collections of shapes or to launch experiments with a given volume mapping algorithm are also included in the package.

How to contribute
VOLMAP is open to new contributions from the community. Practitioners in volume mapping may submit new tracks of the benchmark by simply creating a zip file containing tetrahedral meshes  [FLG15] on volume mappings generated with Tutte 3D (violet) and TLC [DAZ * 20] (green) on the groups G1 and G5 of our dataset. Distortion wise methods are comparable, but Tutte 3D introduced inverted elements in all the mappings whereas TLC could make a (barely) injective map in more than half of the cases. and boundary conditions according to the formats and structure described in Section 3. Data can be assembled and its correctness be verified either by exploiting the tools described in Section 6 or by using external software. The zip file can then be passed to the authors for verification of correctness and license verification. In case of positive checks, data will then be added to the benchmark, and a new group with a growing progressive number will be assigned to it (e.g., G7). In case the submitted surface maps consider a novel target domain, a corresponding suffix for file naming (akin the ones discussed in Section 3) will also be introduced.

Example Evaluation
In this section, we report on a simple experiment where we tested Tutte 3D and TLC [DAZ * 20] against VOLMAP. We emphasize that these experiments are not meant to rank the two methods, but rather to illustrate how the dataset can be exploited by pratictioners in the field. We also remind the reader that mapping tasks in VOLMAP are not strictly guaranteed to always admit a valid solution, hence since these two methods do not employ local mesh refinement they may be asked to solve an impossible problem. The choice of these two techniques and not others is dictated by the availability of reference code that we could readily use for our experiments. Specifically, for Tutte 3D we used the implementation contained in CinoLib [Liv19], whereas for TLC we considered the author's reference implementation ‡ , using the default parameters suggested in the official documentation.
Tutte 3D. We considered mappings to the four canonical domains in Fig. 1 (cube, tet, pyramid and octahedron) for the meshes in group G1 and sphere mappings for the meshes in group G5. Overall, this amounts to 98 experiments for group G1 plus 26 experiments for group G5. For each such experiment we compute the volumetric Tutte embedding by solving a linear system, using the combinatorial Laplacian matrix [XCGL11] and setting (hard) Dirichlet boundary conditions for surface vertices according to the boundary ‡ https://github.com/duxingyi-charles/lifting_ simplices_to_find_injectivity mappings provided in VOLMAP. Each solve produces an alternative volume map, that we then analyzed as described in the remainder of the section.
TLC. We used the mappings obtained with Tutte 3D to bootstrap the TLC solver, which was then asked to remove all the vanishing or inverted elements contained in the map. TLC requires input data to come in a proprietary format. We exploited the scripts released by the authors to perform this conversion, also using their reference file to set the solver options with default arguments.
Results. The two tests above produce 124 volume mappings each, which we then processed with the tools in Section 6 to extract the number of success and failures and to measure the mapping quality. Not surprisingly, experiments with Tutte 3D confirm that this naive method failed in 100% of the cases, always producing non injective mappings with at least one element having negative volume (computed with exact orient predicates [She97]). Conversely, TLC [DAZ * 20] was able to produce a valid map in the 63% of the cases for meshes in G1 (37 failures out of 98) and in the 77% of the cases for meshes in G5 (6 failures out of 26), also exhibiting a slightly lower geometric distortion (Fig. 7). To this end, it should be noted that TLC is not designed to address distortion issues, but rather focuses on the hard problem of removing inverted elements. Overall, this experiment confirms that mappings to simple base domains are extremely complex, and even if TLC is recognized as being one of the most robust numerical methods for injective mapping and mesh untangling, it has collected 44 failures on 124 attempts, suggesting that more research in the field is needed (Section 2.1).

Conclusions
We have presented VOLMAP, a novel large scale dataset to support ongoing research on volume mapping algorithms to geometrically and topologically simple base domains. In the first part of the article, we have discussed a variety of applications where this type of mappings are useful, also showing that this is still an extremely challenging problem for which no satisfactory solutions (and dedicated datasets) exist. We have then introduced the VOLMAP components: meshes, boundary mappings, and software tools. Finally, we have shown an example of comparative analysis of two volume mapping methods from the state of the art. As predicted in Section 2.1, none of these methods was able to successfully compute all the maps, suggesting that more research in the field is indeed needed to achieve the wanted level of robustness and scalability. We are confident that our contribution will aid practitioners in the field, helping them to assess their algorithms and improve their implementations, finding bugs and unexpected corner cases. Last but not least, we would like to emphasize that VOLMAP is intended to be a live dataset, which can grow mainly in two directions: (i) incorporating novel tetrahedral meshes and associated mappings to the known domains; (ii) introducing interesting novel mappings to alternative base domains. Our software tools were designed so as to be modular and to easily support further extensions of the dataset.