OpenVolumeMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues2024-02-02T17:33:39Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/57ovmb: improve error handling2024-02-02T17:33:39ZMartin Heistermannovmb: improve error handlingExample: a mesh that needs garbage collection. Currently we just return a failure code with no further info.
- [ ] make error text available
- [ ] add error code for `NeedsGarbageCollection`
- [ ] an empty (or worse, partial) file is st...Example: a mesh that needs garbage collection. Currently we just return a failure code with no further info.
- [ ] make error text available
- [ ] add error code for `NeedsGarbageCollection`
- [ ] an empty (or worse, partial) file is still written - see if there is a clean platform-independent way to delete the file upon failure in the filename-based interface.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/56Make it easy to write glm::vec props2024-02-02T18:12:51ZMartin HeistermannMake it easy to write glm::vec props- [ ] Ascii writer: At least support it when used in the geometry kernel
- [ ] ovmb: `register_arraylike` won't work, need some type traits here to get dimensionality
- [ ] ovmb: support it in GeometryWriter (including `float` type cf #...- [ ] Ascii writer: At least support it when used in the geometry kernel
- [ ] ovmb: `register_arraylike` won't work, need some type traits here to get dimensionality
- [ ] ovmb: support it in GeometryWriter (including `float` type cf #55)
can we unify geometry and prop writing?Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/54Support more file formats2024-01-23T15:33:45ZMartin HeistermannSupport more file formatsCompare https://github.com/cgg-bern/AlgoHex/issues/13Compare https://github.com/cgg-bern/AlgoHex/issues/13https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/53Tetmesh topology kernel: implement vertex_opposite_halfface()2024-01-23T15:05:10ZMartin HeistermannTetmesh topology kernel: implement vertex_opposite_halfface()Go from a halfface of a tet cell to the opposite vertex.
This is currently possible with the local TetTopology, but that's overkill in many cases.
We also already have `halfface_opposite_vertex()` to go from halfface to opposite vertex ...Go from a halfface of a tet cell to the opposite vertex.
This is currently possible with the local TetTopology, but that's overkill in many cases.
We also already have `halfface_opposite_vertex()` to go from halfface to opposite vertex (although the naming is a bit confusing IMHO).
Ideally this would work for tet elements in mixed meshes too, not just in pure tet meshes.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/52MeshChecker to test consistency2023-07-20T18:32:08ZMartin HeistermannMeshChecker to test consistencyLike OpenMesh's MeshChecker; very useful when using the low-level apis and messing up the mesh somehow.Like OpenMesh's MeshChecker; very useful when using the low-level apis and messing up the mesh somehow.https://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/47Deprecate n_vertices etc?2022-09-14T13:54:56ZMartin HeistermannDeprecate n_vertices etc?`TopologyKernel::n_{vertices, edges, ...}()` counts include deleted entities that are not garbage collected yet. Uses for this include finding out the maximum index, for property-like structure or translations to other data structures.
...`TopologyKernel::n_{vertices, edges, ...}()` counts include deleted entities that are not garbage collected yet. Uses for this include finding out the maximum index, for property-like structure or translations to other data structures.
In many cases `n_logical_{vertices, ...}()` is the correct choice, when the user is actually interested in the properties of the mesh, e.g. checking if it is empty, face-less etc.
I would like to replace the former functions by something with a new name (hard problem!) and deprecate the old ones.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/46TopologyKernel::adjacent_halfface_in_cell: Turn HEH argument into EH2022-09-09T12:13:59ZMartin HeistermannTopologyKernel::adjacent_halfface_in_cell: Turn HEH argument into EHKeep a compatibility version taking a HEH, marked as deprecated.Keep a compatibility version taking a HEH, marked as deprecated.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/45Add functions to check if input entities are incident.2022-09-07T14:49:04ZHeng LiuAdd functions to check if input entities are incident.e.g. bool is_incident(entity1, entity2), where the entities can be any of VH, EH, HEH, FH, HFH, CH.e.g. bool is_incident(entity1, entity2), where the entities can be any of VH, EH, HEH, FH, HFH, CH.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/44Local Topology classes2022-08-18T11:01:18ZMartin HeistermannLocal Topology classesImprove local topology classes from `dev-v3-operators` branch
- [ ] add relabeling/rotation operators:
- [ ] tri: rotate ±2, "change labels to make vertex `x` the `a` vertex instead"
- [ ] tet: flip edge (6 options - but flips of non...Improve local topology classes from `dev-v3-operators` branch
- [ ] add relabeling/rotation operators:
- [ ] tri: rotate ±2, "change labels to make vertex `x` the `a` vertex instead"
- [ ] tet: flip edge (6 options - but flips of non-intersecting edges are equivalent; ab+cd, ac+bd, ad+bc)
- [ ] tet: rotate face (4 faces * 2 options (-1=+2, -2=+1)
- [ ] extend testsMartin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/40Add Read-only access to shared properties on const meshes2022-07-27T17:36:22ZMartin HeistermannAdd Read-only access to shared properties on const mesheshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/39Iterate over all entities with range-for even when the mesh is modified2022-07-27T17:50:48ZMartin HeistermannIterate over all entities with range-for even when the mesh is modifiedCurrently, when using range-for on mesh entities (e.g. `for (auto c: mesh.cells()){}`), the end iterator is an explicit handle to a past-the-end element *during initialisation time*. If the mesh is modified, the loop will either skip the...Currently, when using range-for on mesh entities (e.g. `for (auto c: mesh.cells()){}`), the end iterator is an explicit handle to a past-the-end element *during initialisation time*. If the mesh is modified, the loop will either skip the new elements, or worse, go past the end.
```
CellIter cells_begin() const {
return CellIter(this, CellHandle(0));
}
CellIter cells_end() const {
return CellIter(this, CellHandle((int)cells_.size()));
}
std::pair<CellIter, CellIter> cells() const {
return std::make_pair(cells_begin(), cells_end());
}
```
While modifications during iteration usually is a bad idea, the expectation (IMO rightfully) is that this kind of range loop would iterate until the last element, as long as you use deferred deletion (or only add elements at the end).
My idea here would be to create a special immutable end iterator object, that compares equal to an iterator if the iterator is the current past-the-end element.
Maybe an extra type that implicitly converts to the current end iterator, or is that too much magic?
We could also comapare equal to an iterator that is further past the end - this way, even deleting the last element while iterating over it will work without deferred deletion.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/38Move primitive generating functions from OpenFlipper to OVM2022-06-28T14:19:29ZMartin HeistermannMove primitive generating functions from OpenFlipper to OVMhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/36Evaluate "Wuffs" for OVMB parsing2022-06-28T11:35:30ZMartin HeistermannEvaluate "Wuffs" for OVMB parsingPossibly better/safer than the hand-rolled parser (which demands some refactoring anyways to separate file parsing from mesh creation):
https://github.com/google/wuffsPossibly better/safer than the hand-rolled parser (which demands some refactoring anyways to separate file parsing from mesh creation):
https://github.com/google/wuffshttps://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/32Ensure some (limited) thread safety2022-03-19T08:18:46ZMartin HeistermannEnsure some (limited) thread safetyAdding and removing (even private) properties requires synchronisation between threads for the `Tracker` modification.
As private properties are allowed for const meshes (using `mutable`), this behaviour is definitely unwanted and surpr...Adding and removing (even private) properties requires synchronisation between threads for the `Tracker` modification.
As private properties are allowed for const meshes (using `mutable`), this behaviour is definitely unwanted and surprising.Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/22Implement OM-Style smart handles2023-02-01T10:57:31ZMartin HeistermannImplement OM-Style smart handlesWIP branch: https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/tree/dev/smart-handles
When everything works well, we can start returning smart handles everywhere :smile:WIP branch: https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/tree/dev/smart-handles
When everything works well, we can start returning smart handles everywhere :smile:v3.0Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/21cleanup2021-08-19T10:10:00ZMartin Heistermanncleanup- [x] Make all relative `#include` "absolute" (`<OpenVolumeMesh/...`)
- [ ] Code formatting: Replace all tabs, maybe run clang-tidy- [x] Make all relative `#include` "absolute" (`<OpenVolumeMesh/...`)
- [ ] Code formatting: Replace all tabs, maybe run clang-tidyv3.0Martin HeistermannMartin Heistermannhttps://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.