OpenVolumeMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues2019-02-27T06:56:15Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/3Build without Boost2019-02-27T06:56:15ZJan Möbiusmoebius@cs.rwth-aachen.deBuild without BoostUpdate Build system to build OVM if boost is not available.
FileConverter Depends on boost but tries to use internal version and fails if it does not existUpdate Build system to build OVM if boost is not available.
FileConverter Depends on boost but tries to use internal version and fails if it does not existMax Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/2Warning2018-06-19T11:44:41ZJan Möbiusmoebius@cs.rwth-aachen.deWarning/local/gitlab-runner/builds/63e68e74/1/OpenFlipper-Free/OpenFlipper-Free/libs_required/OpenVolumeMesh/src/OpenVolumeMesh/Attribs/../Core/SerializersT.cc:56:49: warning: private field 'c' is not used [-Wunused-private-field]
template <> .../local/gitlab-runner/builds/63e68e74/1/OpenFlipper-Free/OpenFlipper-Free/libs_required/OpenVolumeMesh/src/OpenVolumeMesh/Attribs/../Core/SerializersT.cc:56:49: warning: private field 'c' is not used [-Wunused-private-field]
template <> class bool_type<false> { char c[2]; };Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/1Feature proposal: C++11 range-for support2021-08-17T09:08:14ZMartin HeistermannFeature proposal: C++11 range-for supportHi,
I have a few utility functions in my code that makes it nicer to iterate over elements of a mesh.
I think they might also be useful for other users, so I'd like to present them here for discussion.
They can be used like this:
```
fo...Hi,
I have a few utility functions in my code that makes it nicer to iterate over elements of a mesh.
I think they might also be useful for other users, so I'd like to present them here for discussion.
They can be used like this:
```
for(const auto &vh: iter_vertices(mesh)) {...} // vh is a VertexHandle&
```
If you think this is useful, I would suggest making them member functions of GeometryKernel instead, so they can be used like this:
```
for(const auto &vh: mesh.iter_vertices()) {...}
```
Let me know what you think of this, I can prepare a patch if you like.
My current implementation (a bit specific, not templated on mesh type) looks like this:
```
template<typename I> // iterator type
class RangeIter {
public:
RangeIter(I begin, I end) : begin_(begin), end_(end) {}
I begin() const {return begin_;}
I end() const {return end_;}
private:
I begin_, end_;
};
const inline RangeIter<OpenVolumeMesh::VertexIter>
iter_vertices(const PolyhedralMesh &mesh) {
return {mesh.vertices_begin(), mesh.vertices_end()};
}
const inline RangeIter<OpenVolumeMesh::EdgeIter>
iter_edges(const PolyhedralMesh &mesh) {
return {mesh.edges_begin(), mesh.edges_end()};
}
// ... etc for the other mesh elements
```
(NB: the code uses C++11 uniform initialization, but I could refactor it to call the constructor explicitly)https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/4Windows CI seems broken2017-12-12T15:34:13ZMartin HeistermannWindows CI seems brokenHi,
it seems the windows build for some reason stopped building the tests.
When I couldn't understand the CI fail for my branch, i pushed the current master to a new branch to trigger CI, and [it fails on windows](https://www.graphics.r...Hi,
it seems the windows build for some reason stopped building the tests.
When I couldn't understand the CI fail for my branch, i pushed the current master to a new branch to trigger CI, and [it fails on windows](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/pipelines/4803) ([after succeeding before for the same commit](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/pipelines/4803)):Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/5Mesh copy support2018-02-07T13:24:00ZMartin HeistermannMesh copy supportCurrently, the C++ default copy constructors handle copying a mesh; this seems problematic in the ResourceManager, which keeps the mesh properties as vectors of raw pointers, so we have a duplicate ownership situation after the copy.
I ...Currently, the C++ default copy constructors handle copying a mesh; this seems problematic in the ResourceManager, which keeps the mesh properties as vectors of raw pointers, so we have a duplicate ownership situation after the copy.
I would change the code to clone the properties (assuming valid copy constructors for property types).
This is related to https://www.graphics.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/issues/143https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/6`BaseProperty::operator=` causes memory corruption2019-02-20T11:42:35ZMartin Heistermann`BaseProperty::operator=` causes memory corruption`BaseProperty::operator=` assigns its `resMan_` to the other prop's resource manager.
This uses ResourceManager's implicit assignment operator (which we should delete!), copying a vector of pointers from one resMan to another, each belie...`BaseProperty::operator=` assigns its `resMan_` to the other prop's resource manager.
This uses ResourceManager's implicit assignment operator (which we should delete!), copying a vector of pointers from one resMan to another, each believing to be the sole owner of those pointers - this easily causes use-after-free.
```
BaseProperty& BaseProperty::operator=(const BaseProperty& _cpy) {
resMan_ = _cpy.resMan_;
lock_ = _cpy.lock_;
return *this;
}
```
Now I'm not sure how to fix this, as it is unclear to me how BaserProperty's `operator=` is actually supposed to behave / how existing code might use it - do we want a per-element assignment/copy here? Or more like a pointer assignment?
What should happen when assigning one mesh's property to a prop of another mesh?
My suggestion would be removing operator= from both BaseProperty and ResourceManager, and possibly adding a different method to bulk-assign between two properties of the same size.Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/7VS2017 CI broken2018-07-23T12:23:48ZMartin HeistermannVS2017 CI brokenhttps://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/jobs/55537
```
The license for Visual Studio has expired.
Your VS Online subscription for this product is expired or needs attention. Please go online to resolve t...https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/jobs/55537
```
The license for Visual Studio has expired.
Your VS Online subscription for this product is expired or needs attention. Please go online to resolve the issue.ERROR: Job failed: exit status 1
```Kersten SchusterKersten Schusterhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/8`ToplogyKernel::n_{vertices,...}()` includes deleted elements, counting logic...2018-10-08T11:24:47ZMartin Heistermann`ToplogyKernel::n_{vertices,...}()` includes deleted elements, counting logical elements would be usefulThe `n_*` methods return the sizes of the underlying vectors, which can be different from the actual logical count when the mesh is not garbage collected.
I suggest we track the actual number of logical undeleted elements in counters, h...The `n_*` methods return the sizes of the underlying vectors, which can be different from the actual logical count when the mesh is not garbage collected.
I suggest we track the actual number of logical undeleted elements in counters, however returning those in `n_*` would be a breaking change, some code might rely on this behaviour.
My suggestion would be introducing `n_logical_{vertices,...}()` methods. Any thoughts (or better suggestions for a name), @moebius, @lyon?https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/9Properties are not typesafe2019-02-20T10:39:38ZMartin HeistermannProperties are not typesafeWhen you accidentally index a property with a Handle of the wrong kind, this gives no error indication at compile time.
I think `VertexProperty[EdgeHandle]` etc. should not compile.
`PropertyPtr::operator[]` currently has overloads for ...When you accidentally index a property with a Handle of the wrong kind, this gives no error indication at compile time.
I think `VertexProperty[EdgeHandle]` etc. should not compile.
`PropertyPtr::operator[]` currently has overloads for `OpenVolumeMeshHandle` and `size_t` arguments, IMO there should be only one function that takes the correct specific handle type.
The `size_t` overload is dangerous in combination with the Handle's implicit `int()` conversion, as it would still allow this kind of type unsafety, I think we should at least not keep both, if not even remove both.
This would be a backwards-incompatible change - maybe best to handle with depreciation macros?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.https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/11Investigate `iterators` branch2019-07-03T14:56:32ZMartin HeistermannInvestigate `iterators` branchThis abandoned branch maybe have some useful functionality, if it works:
https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/tree/iteratorsThis abandoned branch maybe have some useful functionality, if it works:
https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/tree/iteratorshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/12Cleanup to make cppcheck happy2019-05-27T15:54:13ZJan Möbiusmoebius@cs.rwth-aachen.deCleanup to make cppcheck happyMartin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/13Fully eliminate OVM_FORCE_STATIC_CAST2019-10-15T12:46:48ZMartin HeistermannFully eliminate OVM_FORCE_STATIC_CASTMartin HeistermannMartin Heistermannhttps://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/15Config Header Problem2019-07-26T07:45:13ZJan Möbiusmoebius@cs.rwth-aachen.deConfig Header ProblemI recently updated my installation of OpenVolumeMesh to the latest commit and then had trouble building a project that linked to it, getting this error:
"/usr/local/include/OpenVolumeMesh/System/Deprecation.hh:3:10: fatal error: Deprecat...I recently updated my installation of OpenVolumeMesh to the latest commit and then had trouble building a project that linked to it, getting this error:
"/usr/local/include/OpenVolumeMesh/System/Deprecation.hh:3:10: fatal error: DeprecationConfig.hh: No such file or directory #include "DeprecationConfig.hh""
I tracked it down and the problem was that Deprecation.hh was looking for "DeprecationConfig.hh", however CMake installed that file in "Config/DeprecationConfig.hh".
Modifying the installed header so that /usr/local/include/OpenVolumeMesh/System/Deprecation.hh looks for the config file at "../Config/DeprecationConfig.hh" fixed the error.
I'm running Ubuntu 18.04 if that makes any difference.Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/16cppcheck CI warning2020-12-02T15:31:55ZMartin Heistermanncppcheck CI warning```(information) Cppcheck cannot find all the include files (use --check-config for details)```
Maybe it'd be a good idea to use `compile_commands.json` -- however this might miss platform-dependent ifdefs?```(information) Cppcheck cannot find all the include files (use --check-config for details)```
Maybe it'd be a good idea to use `compile_commands.json` -- however this might miss platform-dependent ifdefs?https://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/19"collect_garbage()" crashes after call to "collapse_edge()"2021-08-17T09:07:45ZValentin Nigolian"collect_garbage()" crashes after call to "collapse_edge()"I'm running experiments with collapse_edge() and I found "collect_garbage" to crash after calling the former.
Below's a minimal example to reproduce it.
It ran with Xcode.
```
int main(int _argc, char** _argv) {
TetrahedralM...I'm running experiments with collapse_edge() and I found "collect_garbage" to crash after calling the former.
Below's a minimal example to reproduce it.
It ran with Xcode.
```
int main(int _argc, char** _argv) {
TetrahedralMesh mesh;
double two_pi_5 = 2 * M_PI / 5.;
//pentagon shape
Point p0 = {cos(0 * two_pi_5) , sin(0 * two_pi_5), 0};
Point p1 = {cos(1 * two_pi_5) , sin(1 * two_pi_5), 0};
Point p2 = {cos(2 * two_pi_5) , sin(2 * two_pi_5), 0};
Point p3 = {cos(3 * two_pi_5) , sin(3 * two_pi_5), 0};
Point p4 = {cos(4 * two_pi_5) , sin(4 * two_pi_5), 0};
Point p5 = {0,0,1};
Point p6 = {0,0,-1};
Point p7 = {1,0,1};
VertexHandle v0 = mesh.add_vertex(p0);
VertexHandle v1 = mesh.add_vertex(p1);
VertexHandle v2 = mesh.add_vertex(p2);
VertexHandle v3 = mesh.add_vertex(p3);
VertexHandle v4 = mesh.add_vertex(p4);
VertexHandle v5 = mesh.add_vertex(p5);
VertexHandle v6 = mesh.add_vertex(p6);
VertexHandle v7 = mesh.add_vertex(p7);
//'top faces
FaceHandle f0 = mesh.add_face({v0, v1, v5});
FaceHandle f1 = mesh.add_face({v1, v2, v5});
FaceHandle f2 = mesh.add_face({v2, v3, v5});
FaceHandle f3 = mesh.add_face({v3, v4, v5});
FaceHandle f4 = mesh.add_face({v4, v0, v5});
//bottom faces
FaceHandle f5 = mesh.add_face({v0, v1, v6});
FaceHandle f6 = mesh.add_face({v1, v2, v6});
FaceHandle f7 = mesh.add_face({v2, v3, v6});
FaceHandle f8 = mesh.add_face({v3, v4, v6});
FaceHandle f9 = mesh.add_face({v4, v0, v6});
//interior faces
FaceHandle f10 = mesh.add_face({v0, v5, v6});
FaceHandle f11 = mesh.add_face({v1, v5, v6});
FaceHandle f12 = mesh.add_face({v2, v5, v6});
FaceHandle f13 = mesh.add_face({v3, v5, v6});
FaceHandle f14 = mesh.add_face({v4, v5, v6});
//additional faces
FaceHandle f15 = mesh.add_face({v0, v1, v7});
FaceHandle f16 = mesh.add_face({v1, v5, v7});
FaceHandle f17 = mesh.add_face({v0, v5, v7});
FaceHandle f18 = mesh.add_face({v0, v4, v7});
FaceHandle f19 = mesh.add_face({v4, v5, v7});
//and cells
mesh.add_cell({mesh.halfface_handle(f0, 0),
mesh.halfface_handle(f5, 1),
mesh.halfface_handle(f10,0),
mesh.halfface_handle(f11,1)});
mesh.add_cell({mesh.halfface_handle(f1, 0),
mesh.halfface_handle(f6, 1),
mesh.halfface_handle(f11,0),
mesh.halfface_handle(f12,1)});
mesh.add_cell({mesh.halfface_handle(f2, 0),
mesh.halfface_handle(f7, 1),
mesh.halfface_handle(f12,0),
mesh.halfface_handle(f13,1)});
mesh.add_cell({mesh.halfface_handle(f3, 0),
mesh.halfface_handle(f8, 1),
mesh.halfface_handle(f13,0),
mesh.halfface_handle(f14,1)});
mesh.add_cell({mesh.halfface_handle(f4, 0),
mesh.halfface_handle(f9, 1),
mesh.halfface_handle(f14,0),
mesh.halfface_handle(f10,1)});
mesh.add_cell({mesh.halfface_handle(f0, 1),
mesh.halfface_handle(f15,1),
mesh.halfface_handle(f16,1),
mesh.halfface_handle(f17,1)});
mesh.add_cell({mesh.halfface_handle(f4, 1),
mesh.halfface_handle(f17,1),
mesh.halfface_handle(f18,1),
mesh.halfface_handle(f19,1)});
mesh.collapse_edge(HalfEdgeHandle(23));
//ok up to this point
//crashes there
mesh.collect_garbage();
```
`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/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/28C++17 CI2021-11-19T15:12:17ZMartin HeistermannC++17 CIv3.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/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/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/35Missing OVM_EXPORT in BoundaryItemIter2022-06-28T14:21:19ZHendrik BrücklerMissing OVM_EXPORT in BoundaryItemIterMissing OVM_EXPORT in file BoundaryItemIter.hh prevents use of this class in shared library.Missing OVM_EXPORT in file BoundaryItemIter.hh prevents use of this class in shared library.Hendrik BrücklerHendrik Brücklerhttps://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 mesheshttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/41Throw exception instead of crashing when using ResourceManager::set_persisten...2022-07-29T14:08:38ZMartin HeistermannThrow exception instead of crashing when using ResourceManager::set_persistent on a property of another meshhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/42Add unit tests for find_half{face,edge}_in_cell2022-07-29T14:42:00ZMartin HeistermannAdd unit tests for find_half{face,edge}_in_cellhttps://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/43OVMB float endianness2022-08-18T10:44:58ZMartin HeistermannOVMB float endiannessApparently float byte order can also be different between machines! Make sure we always save as little-endian.Apparently float byte order can also be different between machines! Make sure we always save as little-endian.Martin HeistermannMartin Heistermannhttps://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/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/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/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/48FileManager (.ovm): Files with only valence-6 cells always identified as hexm...2023-02-01T10:21:40ZMartin HeistermannFileManager (.ovm): Files with only valence-6 cells always identified as hexmeshes[`FileManager::isHexahedralMesh`](https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/master/src/OpenVolumeMesh/FileManager/FileManager.cc#L134-178) uses a very simplistic check to figure out if a file contains a ...[`FileManager::isHexahedralMesh`](https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/master/src/OpenVolumeMesh/FileManager/FileManager.cc#L134-178) uses a very simplistic check to figure out if a file contains a hex mesh: if every cell has valence 6, it must be a hex mesh.
This leads to false positives, not only in the (less common) case of some unusual cells, but a hex mesh which was created and saved as polyhedral mesh, but not using the prescribed halfface order will be read as hex mesh, which causes all sorts of weird issues.
Not sure what the best way to fix this is!https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/issues/49Check Hex half-face order consistency2023-02-01T10:27:44ZMartin HeistermannCheck Hex half-face order consistencyMultiple places define orderings for the half-faces of a hex cell:
- Figure in [doc description + induced_coordsys.png](https://www.graphics.rwth-aachen.de/media/openvolumemesh_static/Documentation/OpenVolumeMesh-Doc-Latest/classOpenVol...Multiple places define orderings for the half-faces of a hex cell:
- Figure in [doc description + induced_coordsys.png](https://www.graphics.rwth-aachen.de/media/openvolumemesh_static/Documentation/OpenVolumeMesh-Doc-Latest/classOpenVolumeMesh_1_1HexahedralMeshTopologyKernel.html]
- ASCII art in [`HexahedralMeshTopologyKernel::check_halfface_ordering`](https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/master/src/OpenVolumeMesh/Mesh/HexahedralMeshTopologyKernel.cc#L159-182)
- Code in [HexahedralMeshTopologyKernel::add_cell(const std::vector<VertexHandle>& _vertices,...)`](https://gitlab.vci.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/-/blob/master/src/OpenVolumeMesh/Mesh/HexahedralMeshTopologyKernel.hh#L114-134)
- OpenFlipper's [`FileVTKPlugin::addHexaCellToOpenVolumeMesh`](https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/Plugin-FileVTK/-/blob/master/FileVTK.cc#L532-582)
- Maybe more places.
Are these all equivalent? Check, and definitely improve documentation!
#48 is related.
Internal discussion with PA: https://chat.inf.unibe.ch/group/cgg-coding-questions?msg=xYxP8FNw55kLgkTnshttps://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/51Hexmesh `add_cell` using vertex handles is surprisingly slow2023-07-04T17:57:29ZMartin HeistermannHexmesh `add_cell` using vertex handles is surprisingly slowprofile and optimize :smile:
Weirdly, in some preliminary tests bottom up incidences make it even *slower*?!
`reorder_incident_halffaces` is very expensive, much of it is `opposite_halfface`, which creates a new vector with the halfed...profile and optimize :smile:
Weirdly, in some preliminary tests bottom up incidences make it even *slower*?!
`reorder_incident_halffaces` is very expensive, much of it is `opposite_halfface`, which creates a new vector with the halfedges - this should be a cheap iterator instead.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/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/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/55OVMB: support reading/writing float vertex coordinates2024-02-02T17:29:42ZMartin HeistermannOVMB: support reading/writing float vertex coordinates`vertex_encoding()` always claims `Double`, but `write()` may write floats.`vertex_encoding()` always claims `Double`, but `write()` may write floats.Martin HeistermannMartin Heistermannhttps://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/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/58`TetrahedralMeshTopologyKernel::split_edge` issues2024-02-05T15:51:14ZMartin Heistermann`TetrahedralMeshTopologyKernel::split_edge` issues- [ ] incident faces without cells are not split into two triangles
- [ ] the `alpha` parameter of `TetrahedralGeometryKernel::split_edge` is interpreted in a counter-intuitive way (to me). Guess we are stuck with this, but we should at ...- [ ] incident faces without cells are not split into two triangles
- [ ] the `alpha` parameter of `TetrahedralGeometryKernel::split_edge` is interpreted in a counter-intuitive way (to me). Guess we are stuck with this, but we should at least document it.