OpenVolumeMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues2023-03-31T10:17:32Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/50Implement std::hash for handles2023-03-31T10:17:32ZMartin HeistermannImplement std::hash for handlesuse case: use handles as keys in std::unordered_mapuse case: use handles as keys in std::unordered_maphttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/33Evaluate patch to support selfadjacent blocks2022-06-16T13:19:00ZMartin HeistermannEvaluate patch to support selfadjacent blockshttps://github.com/HendrikBrueckler/MC3D/blob/main/extern/patches/OpenVolumeMesh.patch
One issue lies within the _TopologyKernel::adjacent_halfface_in_cell(**halfface**, **halfedge**)_ method:
the information in **_halfedge_** is reduc...https://github.com/HendrikBrueckler/MC3D/blob/main/extern/patches/OpenVolumeMesh.patch
One issue lies within the _TopologyKernel::adjacent_halfface_in_cell(**halfface**, **halfedge**)_ method:
the information in **_halfedge_** is reduced to an **_edge_**. In normal cells, this is fine, because there are exactly 2 cell-interior halffaces sharing this **_edge_**. In a face-selfadjacent cell like depicted below, there are 3 cell-interior halffaces sharing each edge of the splitting quadrangle: front-facing quadrangle, back-facing quadrangle and one annular (edge-selfadjacent) halfface.
Just returning any halfface incident on the shared **_edge_** loses information here.
Possible solution: return cell-interior halfface that A) contains _opposite(**halfedge**)_ and B) is not _opposite(**halfface**)_ . Also, fix the call to adjacent_halfface_in_cell() within reorder_incident_halffaces()
![split](/uploads/b38271d771755cfdd8c689a2144a3f61/split.png)
Another issue is with the topology check of TopologyCheck::add_cell(...).
Here, the topology check returns an InvalidCellHandle when a halfedge occurs within the same cell more than once (which is valid for a face-selfadjacent cell which contains both halffaces of the same face).https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/20Support properties on const meshes2021-08-17T09:07:15ZMartin HeistermannSupport properties on const meshesNo handle-type-safe array storage is available for const meshes, although it would be very useful.
We could let the caller handle ownership and store pointers in a mutable class variable of `ResourceManager`, or even keep the property i...No handle-type-safe array storage is available for const meshes, although it would be very useful.
We could let the caller handle ownership and store pointers in a mutable class variable of `ResourceManager`, or even keep the property in the mesh along with the others (while making sure they are invisible for other users, so the `const` is not just ignored).https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/10PropertyPtr's public inheritance of shared_ptr reveals too many internals2021-08-17T09:08:29ZMartin HeistermannPropertyPtr's public inheritance of shared_ptr reveals too many internalsIn my opinion, a PropertyPtr should not expose the shared_ptr methods to the user, we should refactor this.In my opinion, a PropertyPtr should not expose the shared_ptr methods to the user, we should refactor this.