OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2018-04-05T09:11:36Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/9Create Benchmarks comparing Legacy and C++11 VectorT2018-04-05T09:11:36ZHans-Christian EbkeCreate Benchmarks comparing Legacy and C++11 VectorTFlesh out `src/Benchmark/VectorT.cpp` with a bunch of meaningful benchmarks so that we get an idea whether the new implementation is slower than the legacy one.Flesh out `src/Benchmark/VectorT.cpp` with a bunch of meaningful benchmarks so that we get an idea whether the new implementation is slower than the legacy one.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/77Create nuget packages?2021-02-15T11:36:59ZJan Möbiusmoebius@cs.rwth-aachen.deCreate nuget packages?There is an old unoffical nuget package available.
https://github.com/mworchel/openmesh-nuget
Bad news is, that the tools used seem to be deprecated.There is an old unoffical nuget package available.
https://github.com/mworchel/openmesh-nuget
Bad news is, that the tools used seem to be deprecated.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/40Creating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected...2019-01-15T15:13:18ZKersten SchusterCreating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected) for GCC, but not for MSVC (2013)One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : c...One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : cannot convert from 'int' to 'ACG::Vec3d'
No constructor could take the source type, or constructor overload resolution was ambiguousJanis BornJanis Bornhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/42Decimater ModRoundness alway collapses2017-05-05T14:26:01ZDaniel GotzenDecimater ModRoundness alway collapsesIn ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.In ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.Daniel GotzenDaniel Gotzenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/81Decimater/Subdivider seem not compatible with Eigen-bases meshes2022-05-05T13:57:18ZSven-Kristofer PilzDecimater/Subdivider seem not compatible with Eigen-bases meshesFor example
```cpp
template<class MeshT>
float ModEdgeLengthT<MeshT>::collapse_priority(const CollapseInfo& _ci) {
typename Mesh::Scalar sqr_length = (_ci.p0 - _ci.p1).sqrnorm();
return ( (sqr_length <= sqr_edge_length_) ? sqr_leng...For example
```cpp
template<class MeshT>
float ModEdgeLengthT<MeshT>::collapse_priority(const CollapseInfo& _ci) {
typename Mesh::Scalar sqr_length = (_ci.p0 - _ci.p1).sqrnorm();
return ( (sqr_length <= sqr_edge_length_) ? sqr_length : float(Base::ILLEGAL_COLLAPSE));
}
```
from: https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/d50cad4640d6d3657c4d0188fbf27ff38e4bfdca/src/OpenMesh/Tools/Decimater/ModEdgeLengthT_impl.hh#L75.
Calls `.sqrnorm()` which is not available, whereas `Core/GeometryEigenVectorT.hh` provides those function in the `Eigen` namespace (for argument-dependent lookup?).
Should that line be `sqrnorm(_ci.p0 - _ci.p1)`?https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/11Documentation2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deDocumentationSeems to be currently broken in Daily buildsSeems to be currently broken in Daily buildsOpenMesh 6.0https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/14Document deletion process2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deDocument deletion process
Add documentation about deletion:
Halfedges are updated on the fly, entities removed later.
Circulators ignore deleted entities, iterators only if skipping, ...
See Mailing list for some more info
Add documentation about deletion:
Halfedges are updated on the fly, entities removed later.
Circulators ignore deleted entities, iterators only if skipping, ...
See Mailing list for some more info
https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/27document that DecimaterT::decimate does not trigger a garbage collection2017-05-01T10:16:22ZJanis Borndocument that DecimaterT::decimate does not trigger a garbage collection`DecimaterT::decimate` removes mesh entities but does not trigger a garbage collection. It is expected that a user manually calls `garbage_collection` afterwards.
As indicated by [this question on StackOverflow](http://stackoverflow.com...`DecimaterT::decimate` removes mesh entities but does not trigger a garbage collection. It is expected that a user manually calls `garbage_collection` afterwards.
As indicated by [this question on StackOverflow](http://stackoverflow.com/questions/38483848/openmesh-decimater-does-not-reduce-vertex-number), this is unexpected and causes some confusion.
The fact that `DecimaterT::decimate` does not prompt a garbage collection should be properly documented.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/71Docu pics broken2020-03-18T08:22:32ZJan Möbiusmoebius@cs.rwth-aachen.deDocu pics brokenJan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/74Eigen3 Finder not included anymore and no global finder available2021-01-15T14:30:32ZJan Möbiusmoebius@cs.rwth-aachen.deEigen3 Finder not included anymore and no global finder availableMartin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/72Eigen tests fail to compile on Linux with Eigen 3.3.72020-04-20T05:58:58ZMartin HeistermannEigen tests fail to compile on Linux with Eigen 3.3.7With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/cl...With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/clang++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc:98:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
../src/Unittests/unittests_eigen3_type.cc:104:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: calling a protected constructor of class 'Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >'
return x;
^
../src/Unittests/unittests_eigen3_type.cc:98:3: note: in instantiation of function template specialization 'Eigen::normalize<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' requested here
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:5:
In file included from ../src/Unittests/../Unittests/unittests_common.hh:7:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:12: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
return normalize(n);
^
../src/Unittests/unittests_eigen3_type.cc:28:7: note: in instantiation of member function 'OpenMesh::PolyMeshT<OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity> >::calc_halfedge_normal' requested here
class OpenMeshEigenTest : public testing::Test {
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
4 errors generated.
```
GCC:
```
/usr/lib/ccache/c++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc: In member function ‘virtual void {anonymous}::OpenMeshEigenTest_Test_external_normalize_Test::TestBody()’:
../src/Unittests/unittests_eigen3_type.cc:98:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
98 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/Unittests/unittests_eigen3_type.cc:104:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
104 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh: In instantiation of ‘Eigen::MatrixBase<Derived> Eigen::normalize(Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’:
../src/Unittests/unittests_eigen3_type.cc:98:19: required from here
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘constexpr Eigen::MatrixBase<Derived>::MatrixBase(const Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
467 | EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
| ^~~~~~~~~~
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:844:65: note: in definition of macro ‘EIGEN_DEFAULT_COPY_CONSTRUCTOR’
844 | #define EIGEN_DEFAULT_COPY_CONSTRUCTOR(CLASS) EIGEN_DEVICE_FUNC CLASS(const CLASS&) = default;
| ^~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64,
from ../src/Unittests/../Unittests/unittests_common.hh:7,
from ../src/Unittests/unittests_eigen3_type.cc:5:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh: In instantiation of ‘OpenMesh::PolyMeshT<Kernel>::Normal OpenMesh::PolyMeshT<Kernel>::calc_halfedge_normal(OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle, double) const [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>; OpenMesh::PolyMeshT<Kernel>::Normal = Eigen::Matrix<double, 3, 1>; OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle = OpenMesh::HalfedgeHandle]’:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:355:29: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_halfedge_normals(double) [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:324:41: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_normals() [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/unittests_eigen3_type.cc:235:25: required from here
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:21: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
407 | return normalize(n);
| ~~~~~~~~~^~~
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/62Free functions for vector norm and others not found on gcc version greater or...2019-02-04T07:43:38ZJan Möbiusmoebius@cs.rwth-aachen.deFree functions for vector norm and others not found on gcc version greater or equal to 7.1OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.de2019-02-05https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/32GCC Compiler Bug Causes Crashes2017-05-01T10:16:22ZHans-Christian EbkeGCC Compiler Bug Causes CrashesThis bug is relevant for configurations which satisfy *all* of the following conditions:
* Using GCC >= 4.9 and < 6.0 to compile.
* Using `-O3` compile flag. (This is default behavior for Release mode.)
* Using `-std=c++11` (or `c+...This bug is relevant for configurations which satisfy *all* of the following conditions:
* Using GCC >= 4.9 and < 6.0 to compile.
* Using `-O3` compile flag. (This is default behavior for Release mode.)
* Using `-std=c++11` (or `c++0x` or `c++14`) compile flags.
The compiler sometimes generates SSE instructions (which require 16 byte alignment) using memory addresses that are not 16-byte-aligned. Since these errors lead to segfaults, suggesting that you tried to access invalid memory addresses, they are extremely hard to recognize and debug.
Known workarounds:
* Use GCC <= 4.8 or >= 6.0.
* Use clang to compile.
* Use `-O2` instead of `-O3`.
* Use `-O3 -march=<architecture>` for an architecture that supports AVX. This way the compiler will generate AVX instead of SSE instructions which do allow unaligned memory access at a small performance penalty.
Also see the corresponding GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/54get_property inconsistent return value over build configs2020-04-02T07:39:21ZMatthias Möllerget_property inconsistent return value over build configsHi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(pro...Hi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(prop_vec, name); //<-- request handle with wrong type
```
The output in result depends on the Build Configuration.
- In Debug mode, following holds: `result==false`
- In Release mode, following holds: `result==true`
It is because in "PropertyContainer.h", the type check is disabled in Release mode (line 126-128).
The function should return the same value over the different
build configurations.
(I would prefer the type check enabled, because it seems to be complex, checking outside of the PropertyContainer if the type of your prophandle is the correct one
__edit__ or provide an additional member-function "has_type", or something like this, skipping the dynamic_cast in get_property)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/39HalfedgeLoopCCWIter and HalfedgeLoopCWIter go into the wrong direction2017-05-01T10:16:21ZMax Lyonlyon@cs.rwth-aachen.deHalfedgeLoopCCWIter and HalfedgeLoopCWIter go into the wrong directionI believe the unit tests for the HalfedgeLoopCCWIter and HalfedgeLoopCWIter have been wrong. I fixed the test with commit 6fef88d5.
Now the test reveals that both iterators go in the wrong direction.I believe the unit tests for the HalfedgeLoopCCWIter and HalfedgeLoopCWIter have been wrong. I fixed the test with commit 6fef88d5.
Now the test reveals that both iterators go in the wrong direction.Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/66heap-buffer-overflow while adding an invalid triangle face2021-01-29T11:08:44ZSven-Kristofer Pilzheap-buffer-overflow while adding an invalid triangle faceI came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::P...I came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::PolyConnectivity::add_face(OpenMesh::VertexHandle const*, unsigned long)`).
```cpp
#include <OpenMesh/Core/Mesh/PolyMesh_ArrayKernelT.hh>
typedef OpenMesh::PolyMesh_ArrayKernelT<> MyMesh;
int main()
{
MyMesh mesh;
const auto a = mesh.add_vertex(MyMesh::Point{-6.95757 -0.418557 -7.25885});
const auto b = mesh.add_vertex(MyMesh::Point{-7.03569 -0.128014 -7.26395});
mesh.add_face(a,b,a);
return 0;
}
```
When run with assertions enabled, this triggers:
> OpenMesh/Core/Mesh/PolyConnectivity.cc:272: OpenMesh::ArrayKernel::FaceHandle OpenMesh::PolyConnectivity
> ::add_face(const VertexHandle*, size_t): Assertion `boundary_prev.is_valid()' failed.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/82Inconsistent capitalization2022-09-09T07:16:14ZMax Lyonlyon@cs.rwth-aachen.deInconsistent capitalization[PropertyManager](https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/master/src/OpenMesh/Core/Utils/PropertyManager.hh) uses `camelCase` instead of the usual `snake_case`.[PropertyManager](https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/master/src/OpenMesh/Core/Utils/PropertyManager.hh) uses `camelCase` instead of the usual `snake_case`.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/5Inefficient implementation of ArrayKernel::opposite_halfedge_handle()2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deInefficient implementation of ArrayKernel::opposite_halfedge_handle()Currently, ArrayKernel::opposite_halfedge_handle() is implemented like this:
HalfedgeHandle opposite_halfedge_handle(HalfedgeHandle _heh) const
{ return HalfedgeHandle((_heh.idx() & 1) ? _heh.idx()-1 : _heh.idx()+1); } ...Currently, ArrayKernel::opposite_halfedge_handle() is implemented like this:
HalfedgeHandle opposite_halfedge_handle(HalfedgeHandle _heh) const
{ return HalfedgeHandle((_heh.idx() & 1) ? _heh.idx()-1 : _heh.idx()+1); }
Here is what gcc makes of this with -O2:
0x00000000004594a0 <+0>: lea -0x1(%rsi),%edx
0x00000000004594a3 <+3>: lea 0x1(%rsi),%eax
0x00000000004594a6 <+6>: and $0x1,%esi
0x00000000004594a9 <+9>: cmovne %edx,%eax
0x00000000004594ac <+12>: retq
Why don't we change it to this:
HalfedgeHandle opposite_halfedge_handle(HalfedgeHandle _heh) const
{ return HalfedgeHandle(_heh.idx() ^ 1); }
gcc -O2 compiles this into
0x00000000004594a0 <+0>: mov %esi,%eax
0x00000000004594a2 <+2>: xor $0x1,%eax
0x00000000004594a5 <+5>: retq
which certainly looks more efficient to me (no conditional, fewer instructions).OpenMesh 5.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/7Instable algorithm for face normal computation2017-10-27T14:34:54ZChristopher TenterInstable algorithm for face normal computationThe current algorithm assumes that faces are convex and fails for other polygons.The current algorithm assumes that faces are convex and fails for other polygons.Christopher TenterChristopher Tenterhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/18Internal Compiler Error VS 2015 Update12017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deInternal Compiler Error VS 2015 Update1File: OpenMesh\Tools\VDPM\ViewingParameters.cc
Message:
1>------ Build started: Project: OpenMeshTools, Configuration: Debug x64 ------
1> ViewingParameters.cc
1>C:\cpplibs\openmesh\lib\src\OpenMesh\Tools\VDPM\ViewingParamet...File: OpenMesh\Tools\VDPM\ViewingParameters.cc
Message:
1>------ Build started: Project: OpenMeshTools, Configuration: Debug x64 ------
1> ViewingParameters.cc
1>C:\cpplibs\openmesh\lib\src\OpenMesh\Tools\VDPM\ViewingParameters.cc(89): fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\special.c', line 6211)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
Workaround what worked for me:
Replace in that file lines
...
Vec3f inv_rot[3], trans;
...
Vec3f normal[4];
…
to the following
...
Vec3f inv_rot[3]{ {},{},{} }, trans;
...
Vec3f normal[4]{ {},{},{},{} };
…OpenMesh 6.0Janis BornJanis Born