OpenVolumeMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/groups/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/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/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/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/28C++17 CI2021-11-19T15:12:17ZMartin HeistermannC++17 CIv3.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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.de