nightmare_of_polycubes
(Very) challenging 3D shapes for polycube-based hex-meshing
https://github.com/lihpc-computational-geometry/nightmare_of_polycubes
Science Score: 49.0%
This score indicates how likely this project is to be science-related based on various indicators:
-
○CITATION.cff file
-
✓codemeta.json file
Found codemeta.json file -
✓.zenodo.json file
Found .zenodo.json file -
✓DOI references
Found 14 DOI reference(s) in README -
✓Academic publication links
Links to: acm.org -
○Academic email domains
-
○Institutional organization owner
-
○JOSS paper metadata
-
○Scientific vocabulary similarity
Low similarity (9.0%) to scientific vocabulary
Keywords
Repository
(Very) challenging 3D shapes for polycube-based hex-meshing
Basic Info
Statistics
- Stars: 11
- Watchers: 2
- Forks: 0
- Open Issues: 0
- Releases: 0
Topics
Metadata Files
README.md
Nightmare of polycubes
(Very) challenging 3D shapes for polycube-based hex-meshing
Dataset
All models were designed with the Shaper module of the open-source SALOME platform.
Name | Thumbnail | Files | Comments
:---:|-----------|-------|---------
7-connected |
.py
.step
.brep
.stl
.obj | The node at the middle has 7 adjacent patches, which is usually forbidden [^eppstein2010][^livesu2013][^dumery2022][^he2024], 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 [^eppstein2010][^livesu2013]. But the issue is that the common processing for invalid corners (local relabeling [^dumery2022]) will result in a high distorsion, whereas a global operator (retracing of incident boundaries) would be better. Model inspired by ABC n°00001525 [^koch2019].
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 [^sokolov2015] and mentioned in appendices of [^dumery2022].
Labeling-based approaches [^livesu2013][^dumery2022] 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 [^sokolov2015] I believe.
Here too labeling-based approaches [^livesu2013][^dumery2022] 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 [^mestrallet2023]
Labeling-based approaches [^livesu2013][^dumery2022] 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 [^sokolov2015] along the pipes axis.
pipe_helix | | .hdf .py
.step
.brep
.stl
.obj | Simplified configuration of the previous model.
[^livesu2013]: 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/ [^sokolov2015]: Dmitry Sokolov, Nicolas Ray, "Fixing normal constraints for generation of polycubes", research report, LORIA, 2015, HAL: hal-01211408 [^dumery2022]: 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 [^mestrallet2023]: 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 [^eppstein2010]: 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 [^koch2019]: 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, 2019, DOI: 10.1109/CVPR.2019.00983, project page: deep-geometry.github.io/abc-dataset [^he2024]: 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, 2024, DOI: 10.1137/1.9781611978001.4
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.
Per model files
SALOME_Study.hdf
This is a study of the [SALOME platform](https://www.salome-platform.org/), based on the [Hierarchical Data Format](https://www.hdfgroup.org/solutions/hdf5/). 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](https://www.salome-platform.org/?page_id=327) module of [SALOME](https://www.salome-platform.org/), 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](https://en.wikipedia.org/wiki/ISO_10303) format. It was exported from Shaper. You can open it with many tools, like the [Shaper](https://www.salome-platform.org/?page_id=327) module of [SALOME](https://www.salome-platform.org/), [Mayo](https://github.com/fougue/mayo/), [f3d](https://github.com/f3d-app/f3d) or [3dviewer.net](https://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](https://www.salome-platform.org/?page_id=327) module of [SALOME](https://www.salome-platform.org/), [Mayo](https://github.com/fougue/mayo/), [f3d](https://github.com/f3d-app/f3d) or [3dviewer.net](https://3dviewer.net/).CAD.stl
This is a discretized 3D model under the [STL](https://en.wikipedia.org/wiki/STL_(file_format)) 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](https://www.salome-platform.org/?page_id=327) module of [SALOME](https://www.salome-platform.org/), [Mayo](https://github.com/fougue/mayo/), [f3d](https://github.com/f3d-app/f3d) or [3dviewer.net](https://3dviewer.net/).triangle_mesh.obj
This is a fine 3D triangle mesh under the [Wavefront](https://en.wikipedia.org/wiki/Wavefront_.obj_file) format. A tetrahedral mesh was first generated using [Gmsh](http://gmsh.info/) (with Mesh.CharacteristicLengthFactor = 0.05), except for `encrusted_cube` where I had to use the [SMESH](https://www.salome-platform.org/?page_id=374) module of [SALOME](https://www.salome-platform.org/) to obtain a volume mesh with the prescribed feature edges. Then the surface was extracted with [extract_surface](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling/blob/main/app/extract_surface.cpp) from [LIHPC-Computational-Geometry/validity-first-polycube-labeling](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling). 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](https://github.com/BrunoLevy/GraphiteThree), [f3d](https://github.com/f3d-app/f3d) or [3dviewer.net](https://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 : $\{0 = +X, 1 = -X, 2 = +Y, 3 = -Y, 4 = +Z, 5 = -Z\}$. In the thumbnail and the .glb file, red-white-blue colors are used to represent $X$, $Y$, and $Z$ labels. The text file was generated using [naive_labeling](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling/blob/main/app/naive_labeling.cpp) from [LIHPC-Computational-Geometry/validity-first-polycube-labeling](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling), that is by picking the closest direction of each triangle normal. Complex shapes (like `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](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling/blob/main/app/labeling_viewer.cpp) from [LIHPC-Computational-Geometry/validity-first-polycube-labeling](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling), then the labeling.labeled_CAD.glb
This is a 3D render stored under the [glTF](https://www.khronos.org/gltf/) 2.0 binary format. It is not based on triangle_mesh.obj + labeling.txt (too heavy), but on a naive labeling of CAD.stl. It was generated using [to_glTF](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling/blob/main/app/to_glTF.cpp) from [LIHPC-Computational-Geometry/validity-first-polycube-labeling](https://github.com/LIHPC-Computational-Geometry/validity-first-polycube-labeling). You can open it with many tools, like the [official sample viewer from Khronos](https://github.khronos.org/glTF-Sample-Viewer-Release/), [f3d](https://github.com/f3d-app/f3d) or [3dviewer.net](https://3dviewer.net/).Contributing
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.
License
How to cite
Sébastien Mestrallet and Christophe Bourcier, "Nightmare of polycubes", https://github.com/LIHPC-Computational-Geometry/nightmareofpolycubes, licensed under CC BY-NC 4.0
APA
Use the "[Cite this repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files)" GitHub button.BibTex
Use the "[Cite this repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files)" GitHub button.Citation File Format (.cff)
See [CITATION.cff](CITATION.cff).Owner
- Name: LIHPC-Computational-Geometry
- Login: LIHPC-Computational-Geometry
- Kind: organization
- Location: France
- Repositories: 9
- Profile: https://github.com/LIHPC-Computational-Geometry
GitHub Events
Total
- Watch event: 2
- Push event: 1
Last Year
- Watch event: 2
- Push event: 1