OpenVolumeMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/groups/OpenVolumeMesh/-/issues2019-08-16T19:20:09Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/14CMake overhaul2019-08-16T19:20:09ZMartin HeistermannCMake overhaul* [x] CMakeLists rewrite
* [ ] Windows dll/lib build (need to add OVM_EXPORT macros / disable warnings about STL containers)
* [ ] Tests on windows (with or without ctest?)
* [x] Support static library build (if needed?)
* [x] Adjus...* [x] CMakeLists rewrite
* [ ] Windows dll/lib build (need to add OVM_EXPORT macros / disable warnings about STL containers)
* [ ] Tests on windows (with or without ctest?)
* [x] Support static library build (if needed?)
* [x] Adjust OpenFlipper to work with new OVM (without its own custom finder)
* [ ] Test in-tree build
* [ ] Test standalone build
* [ ] File converter
* [ ] support find_package after add_subdirectory
http://www.brianlheim.com/2018/04/09/cmake-cheat-sheet.html
https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
Maybe: https://cmake.org/cmake/help/latest/module/WriteCompilerDetectionHeader.html
Development branch (may receive force pushes): https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/commits/cmake-overhaul-2Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/17Support proper shared library build2019-08-13T13:21:54ZMartin HeistermannSupport proper shared library buildFor a clean shared library, we need to
* [ ] Avoid exposing STL containers in the interface.
* [ ] Add OVM_EXPORT macros in many placesFor a clean shared library, we need to
* [ ] Avoid exposing STL containers in the interface.
* [ ] Add OVM_EXPORT macros in many placeshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/18TopologyKernel::face_cells return value contains an invalid handle for surfac...2019-08-19T15:27:26ZMartin HeistermannTopologyKernel::face_cells return value contains an invalid handle for surface facesThis is unexpected behaviour (at least for me).This is unexpected behaviour (at least for me).https://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/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/23OVMB: binary file format2021-11-19T14:55:28ZMartin HeistermannOVMB: binary file formatFor first release:
- [x] Implement ~~all~~ important prop types from the current ASCII format
- [x] get rid of (or catch) exceptions
- [x] save options
- [x] De-templatize implementation, often a TopologyKernel is sufficient
- [ ] Docume...For first release:
- [x] Implement ~~all~~ important prop types from the current ASCII format
- [x] get rid of (or catch) exceptions
- [x] save options
- [x] De-templatize implementation, often a TopologyKernel is sufficient
- [ ] Document API
- [ ] Standard load/save API
- [ ] Custom prop type API
- [x] file format
- [x] OF integration
- [x] .ovmb file picker
- [x] ACG vector types
- [x] PluginFunctions to register custom prop types
- [x] Add unit tests
- [x] save + load
- [x] load existing files (to avoid incompatibility regressions)
- [x] Eigen types
- [ ] custom property types
Later:
- [ ] compression (zstd?) - figure out how to handle dependency well
- [ ] progress callback + abort functionv3.0Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/24Add tests for TetTopoKernel split_*/collapse_*2021-08-19T10:08:02ZMartin HeistermannAdd tests for TetTopoKernel split_*/collapse_*v3.0https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/25Add tests for attributes2021-08-19T10:10:04ZMartin HeistermannAdd tests for attributesv3.0https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/26Better mixed mesh support2022-06-28T14:25:05ZMartin HeistermannBetter mixed mesh supportA lot of functionality implemented for tet/hex meshes would also be useful in polyhedral meshes for cells/regions of the appropriate type.A lot of functionality implemented for tet/hex meshes would also be useful in polyhedral meshes for cells/regions of the appropriate type.v3.0https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/27Add mesh analysis2021-08-19T10:10:03ZMartin HeistermannAdd mesh analysisMove code from OF/Plugin-InfoVolumeMeshMove code from OF/Plugin-InfoVolumeMeshv3.0Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/29Fix inconsistencies2021-09-09T15:41:49ZMartin HeistermannFix inconsistencies- [ ] `TopologyKernel::opposite_halfface()` returns face- [ ] `TopologyKernel::opposite_halfface()` returns facev3.0Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/30FileManager: check if mesh is garbage collected2021-11-08T13:29:44ZMartin HeistermannFileManager: check if mesh is garbage collectedsaving a non-garbage-collected mesh will have weird results and a potentially unreadable mesh.saving a non-garbage-collected mesh will have weird results and a potentially unreadable mesh.Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/31Clean up CI scripts2022-06-28T14:19:41ZMartin HeistermannClean up CI scriptsMartin HeistermannMartin Heistermannhttps://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/34Ensure move-assignment behaves as expected2022-06-28T14:22:21ZMartin HeistermannEnsure move-assignment behaves as expectedFor use in OF, it would be excellent if existing properties are ensured to keep working with the new moved-in mesh.
Write a test :)For use in OF, it would be excellent if existing properties are ensured to keep working with the new moved-in mesh.
Write a test :)Martin HeistermannMartin Heistermannhttps://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/37Document, test and fix SmartTagger:2022-06-28T13:51:15ZMartin HeistermannDocument, test and fix SmartTagger:I think the comparison in reset() is the wrong way around:
https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/52042166262c32729498a671b1b92ffe1c7eb299/src/OpenVolumeMesh/Util/SmartTagger.hh#L23-28I think the comparison in reset() is the wrong way around:
https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/52042166262c32729498a671b1b92ffe1c7eb299/src/OpenVolumeMesh/Util/SmartTagger.hh#L23-28https://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/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/40Add Read-only access to shared properties on const meshes2022-07-27T17:36:22ZMartin HeistermannAdd Read-only access to shared properties on const meshes