(Very) challenging 3D shapes for polycube-based hex-meshing
All models were designed with the Shaper module of the open-source SALOME platform.
| Name | Thumbnail | Files | Comments |
|---|---|---|---|
7-connected |
.hdf .py .step .brep .stl .obj |
The node at the middle has 7 adjacent patches, which is usually forbidden 1234, despite that the polycuboid corresponding to the labeling can be used to generate a good hex-mesh. | |
8-connected |
.hdf .py .step .brep .stl .obj |
Another high valence corner (here of valence 8) is present in the labeling, but the latter can still be used to generate a good hex-mesh. | |
24-connected |
.hdf .py .step .brep .stl .obj |
8 volumes connected by a vertex, making a labeling node with 24 adjacent patches. If we ignore diagonal feature edges, the labeling can be used to generate a polycube-based hex-mesh. | |
encrusted_cube |
.hdf .py .step .brep .stl .obj |
The labeling is justly classified as invalid (there are 4-connected corners with incident boundaries of the same axis) according to the "simple orthogonal polyhedra" criteria 12. But the issue is that the common processing for invalid corners (local relabeling 3) will result in a high distorsion, whereas a global operator (retracing of incident boundaries) would be better. Model inspired by ABC n°00001525 5. | |
conjoined_twins |
.hdf .py .step .brep .stl .obj |
Simplified configuration of the previous model. | |
cuboid_screw_thread |
.hdf .py .step .brep .stl .obj |
Introduced in 6 and mentioned in appendices of 3. Labeling-based approaches 23 will collapse the two parts of the slope, constrained to the same top and bottom planes. |
|
cuboid_torus_with_step |
.hdf .py .step .brep .stl .obj |
Introduced in 6 I believe. Here too labeling-based approaches 23 will not detect any invalidity and crush the step into the z-axis plane. |
|
cuboid_tray_with_step |
.hdf .py .step .brep .stl .obj |
Similar to the previous model (the step will still be crushed), but of genus 0. | |
in-volume_twist |
.hdf .py .step .brep .stl .obj |
Introduced in 7 Labeling-based approaches 23 will not detect the twist. The slits prevent hex-mesh extraction algorithms from un-twisting the through-hole and pushing all distorsion towards the left and right faces. |
|
in-volume_knot |
.hdf .py .step .brep .stl .obj |
Similar to the previous model, but the through-hole is twisting around itself. | |
pipe_helix_7 |
.hdf .py .step .brep .stl .obj |
7 pipes with helices around, inside a hexagonal prism. The helices slopes are likely to create conflicting normal constraints 6 along the pipes axis. | |
pipe_helix |
.hdf .py .step .brep .stl .obj |
Simplified configuration of the previous model. |
Thanks to François Protais for the ideas that led to in-volume_twist & in-volume_knot, and to Christophe Bourcier for your help with Shaper.
SALOME_Study.hdf
This is a study of the SALOME platform, based on the Hierarchical Data Format. It contains the CAD construction.
To open this file, open SALOME then, in the menu bar, click on "File" > "Open", and select the SALOME_Study.hdf file. Last, open the Shaper module.
SALOME_Shaper.py
This is a script generated by the Shaper module of SALOME, to construct the CAD model from a text-based user interface.
To execute a Shaper script, open SALOME then the Shaper module. In the menu bar click on "File" > "Load Script" and select the SALOME_Shaper.py file.
CAD.step
This is a static 3D CAD model under the STEP / ISO 10303 format. It was exported from Shaper.
You can open it with many tools, like the Shaper module of SALOME, Mayo, f3d or 3dviewer.net.
CAD.brep
This is a static 3D CAD model under the Boundary REPresentation format. It was exported from Shaper.
You can open it with many tools, like the Shaper module of SALOME, Mayo, f3d or 3dviewer.net.
CAD.stl
This is a discretized 3D model under the STL binary format. It was exported from Shaper with the default relative deflection of 0.0001.
You can open it with many tools, like the Shaper module of SALOME, Mayo, f3d or 3dviewer.net.
triangle_mesh.obj
This is a fine 3D triangle mesh under the Wavefront format. A tetrahedral mesh was first generated using Gmsh (with Mesh.CharacteristicLengthFactor = 0.05), except for encrusted_cube where I had to use the SMESH module of SALOME to obtain a volume mesh with the prescribed feature edges. Then the surface was extracted with extract_surface from LIHPC-Computational-Geometry/automatic_polycube. The mesh size is deliberately small and homogeneous to leave degrees of freedom to the labeling generation stage.
You can open it with many tools, like Graphite, f3d or 3dviewer.net.
labeling.txt
This is an ASCII file with as many lines as there are triangles in triangle_mesh.obj. Each triangle is mapped to one of the 6 global directions : pipe_helix and pipe_helix_7) cannot rely on such labeling to obtain a polycube.
To open this file, you have to load triangle_mesh.obj first in labeling_viewer from LIHPC-Computational-Geometry/automatic_polycube, then the labeling.
labeled_CAD.glb
This is a 3D render stored under the glTF 2.0 binary format. It is not based on triangle_mesh.obj + labeling.txt (too heavy) on a naive labeling of CAD.stl. It was generated using to_glTF from LIHPC-Computational-Geometry/automatic_polycube.
You can open it with many tools, like the official sample viewer from Khronos, f3d or 3dviewer.net.
If you defined new validity criteria for polycube labelings, that better discriminate between valid and invalid configurations, you can send a PR to link to your work.
Likewise, if you designed an automatic hex-meshing algorithm, in particular (but not limited to) a polycube-based one, that can handle one of these 3D models (except a *-connected, too easy), you can send a PR to link to your work.
Sébastien Mestrallet and Christophe Bourcier, "Nightmare of polycubes", https://github.com/LIHPC-Computational-Geometry/nightmare_of_polycubes, licensed under CC BY-NC 4.0
APA
Use the "Cite this repository" GitHub button.
BibTex
Use the "Cite this repository" GitHub button.
Citation File Format (.cff)
See CITATION.cff.
Hayagriva (for Typst)
nightmare_of_polycubes:
title: Nightmare of polycubes
author: ["Mestrallet, Sébastien", "Bourcier, Christophe"]
type: repository
url: https://github.com/LIHPC-Computational-Geometry/nightmare_of_polycubes
date: 2024Footnotes
-
David Eppstein, Elena Mumford, "Steinitz Theorems for Orthogonal Polyhedra", Proceedings of the 26th annual symposium on Computational Geometry, pp.429–438, 2010, DOI: 10.1145/1810959.1811030 ↩ ↩2
-
Marco Livesu, Nicholas Vining, Alla Sheffer, James Gregson, Riccardo Scateni, "PolyCut: Monotone Graph-Cuts for PolyCube Base-Complex Construction", Transactions on Graphics (Proc. SIGGRAPH ASIA 2013), 2013, DOI: 10.1145/2508363.2508388, project page: www.cs.ubc.ca/labs/imager/tr/2013/polycut/ ↩ ↩2 ↩3 ↩4 ↩5
-
Corentin Dumery, François Protais, Sébastien Mestrallet, Christophe Bourcier, Franck Ledoux, "Evocube: a Genetic Labeling Framework for Polycube-Maps", Computer Graphics Forum, 2022, DOI: 10.1111/cgf.14649, HAL: hal-03657779, project page: corentindumery.github.io/projects/evocube.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Lu He, Na Lei, Ziliang Wang, Chen Wang, Xiaopeng Zheng, and Zhongxuan Luo, "Expanding the Solvable Space of Polycube-Map via Validity-Enhanced Construction", Proceedings of the 2024 International Meshing Roundtable, DOI: 10.1137/1.9781611978001.4 ↩
-
Sebastian Koch, Albert Matveev, Zhongshi Jiang, Francis Williams, Alexey Artemov, Evgeny Burnaev, Marc Alexa, Denis Zorin, Daniele Panozzo, "ABC: A Big CAD Model Dataset For Geometric Deep Learning", Computer Vision and Pattern Recognition, DOI: 10.1109/CVPR.2019.00983, project page: deep-geometry.github.io/abc-dataset ↩
-
Dmitry Sokolov, Nicolas Ray, "Fixing normal constraints for generation of polycubes", research report, LORIA, 2015, HAL: hal-01211408 ↩ ↩2 ↩3
-
Sébastien Mestrallet, François Protais, Christophe Bourcier, Franck Ledoux, "Limits and prospects of polycube labelings", SIAM International Meshing Roundtable Workshop, March 2023, HAL: cea-04169841 ↩