OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2017-05-01T10:16:22Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/19OBJ Reader: Does not load 3D Texture coordinates2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deOBJ Reader: Does not load 3D Texture coordinates
I have an OBJ file which has "vt x,y,z"
I tried setting up for requesting the texture coordinate as 3D
mesh.request_halfedge_texcoords3D();
when I query the resulting data, I get lots of zeros and the occas...
I have an OBJ file which has "vt x,y,z"
I tried setting up for requesting the texture coordinate as 3D
mesh.request_halfedge_texcoords3D();
when I query the resulting data, I get lots of zeros and the occasional NaNs.
If I request for texcoords2D(), it works fine.
I just want to find out if this is a known limitation or bad coding on my part in calling functions in OpenMesh.
I am using OpenMesh 4.1 OpenMesh 6.0Martin SchultzMartin Schultzhttps://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 Bornhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/17Check for possible double swap in om writers2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deCheck for possible double swap in om writersOpenMesh 6.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/13Add some more unittests to cover the following functions2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deAdd some more unittests to cover the following functions all writers: binary_size(BaseExporter& _be, Options _opt)
- jacobi smoother with C1 continuity
- some function in IOmanager
- McDecimaterT<Mesh>::decimate_constraints_only
- PolyConnectivity::is_collapse_ok
- PolyConnectivity::is_s... all writers: binary_size(BaseExporter& _be, Options _opt)
- jacobi smoother with C1 continuity
- some function in IOmanager
- McDecimaterT<Mesh>::decimate_constraints_only
- PolyConnectivity::is_collapse_ok
- PolyConnectivity::is_simple_link(EdgeHandle _eh)/ PolyConnectivity::is_simply_connected(FaceHandle _fh)
- PolyConnectivity::remove_edge(EdgeHandle _eh) / PolyConnectivity::insert_edge(HalfedgeHandle _prev_heh, HalfedgeHandle _next_heh) / void PolyConnectivity::reinsert_edge(EdgeHandle _eh) / PolyConnectivity::split_edge/PolyConnectivity::split_edge_copy
- PolyConnectivity::triangulate()
- ArrayKernel::assign_connectivity
- TriConnectivity::vertex_split/ TriConnectivity::insert_loop / TriConnectivity::insert_edge / TriConnectivity::split_copyOpenMesh 6.0https://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/8Ugly clang warning2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deUgly clang warning/local/gitlab-runner/builds/0441ed36/0/OpenMesh/OpenMesh/src/OpenMesh/Core/../../OpenMesh/Core/Geometry /VectorT.hh:148:51: warning: suggest braces around initialization of subobject [-Wmissing-braces]
constexpr VectorDataT(T.../local/gitlab-runner/builds/0441ed36/0/OpenMesh/OpenMesh/src/OpenMesh/Core/../../OpenMesh/Core/Geometry /VectorT.hh:148:51: warning: suggest braces around initialization of subobject [-Wmissing-braces]
constexpr VectorDataT(T... vs) : values_ {vs...} {
^~
{ }
/local/gitlab-runner/builds/0441ed36/0/OpenMesh/OpenMesh/src/OpenMesh/Core/../../OpenMesh/Core/Geometry/VectorT_inc.hh:108:32: note: in instantiation of function template specialization 'OpenMesh::VectorDataT<float, 4>::VectorDataT<float, float, float, float>' requested here
constexpr VectorT(T... vs) : Base { static_cast<Scalar>(vs)...}
^
/local/gitlab-runner/builds/0441ed36/0/OpenMesh/OpenMesh/src/OpenMesh/Core/../../OpenMesh/Core/Geometry/VectorT.hh:445:12: note: in instantiation of function template specialization 'OpenMesh::VectorT<float, 4>::VectorT<float, float, float, float, void, void>' requested here
return OpenMesh::Vec4f(
^
1 warning generated. OpenMesh 5.0Hans-Christian EbkeHans-Christian Ebkehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/6Compiler Error in status flags2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deCompiler Error in status flagsThere seems to be a compiler error in ArrayKernel.hh Line 711
The clear function is never defined with an parameter. Not sure if this function gets called anywhere. I guess it was intended that the code swaps the erase element with th...There seems to be a compiler error in ArrayKernel.hh Line 711
The clear function is never defined with an parameter. Not sure if this function gets called anywhere. I guess it was intended that the code swaps the erase element with the last one in the vector and then pop it at the back to achieve O(1) complexity while std::vector would move all elements. Just a quick guess.
We need a unittest to build this part.
Seems to be a windows compiler triggerring the error.
/Core/Mesh/ArrayKernel.hh(704): error: too many arguments in function call
OpenMesh 5.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/4Mesh with 2D Points unsupported2017-10-27T14:34:54ZDominik SibbingMesh with 2D Points unsupportedDefining Point as e.g. Vec2d throws compile error.Defining Point as e.g. Vec2d throws compile error.OpenMesh 6.0Matthias MöllerMatthias Möllerhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/2Make Unittests respect CMAKE_CXX_FLAGS from cmake2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deMake Unittests respect CMAKE_CXX_FLAGS from cmakeOpenMesh 5.0Matthias MöllerMatthias Möllerhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/1Check reader parallelizability2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deCheck reader parallelizabilityPlease check the readers for static variables, that could prevent them from being used simultaniously on different meshes.Please check the readers for static variables, that could prevent them from being used simultaniously on different meshes.OpenMesh 5.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/85OBJ export stores (often bogus) texture coordinates of boundary halfedges2023-03-01T11:02:52ZMartin HeistermannOBJ export stores (often bogus) texture coordinates of boundary halfedgesWhen exporting a mesh as OBJ, unused boundary halfedge-texcoords are stored. They are not used anywhere and the resulting file seems valid.
However if those stem from uninitialized memory, the number of different texture coords can signi...When exporting a mesh as OBJ, unused boundary halfedge-texcoords are stored. They are not used anywhere and the resulting file seems valid.
However if those stem from uninitialized memory, the number of different texture coords can significantly bloat the .obj file size.
Example .obj excerpt
```
vt -76500107434139575140676561222651346944.000000 1.970980
vt -4950073864930567497435155906561048576.000000 -1.834825
vt -1931694947632209777361309154513256448.000000 -1.832364
vt -1238546134728614397081714835220070400.000000 1.814589
vt -707588858575282684185056046137475072.000000 2.654118
vt -73317830722383046556445364377878528.000000 2.735005
vt -19543880572954837544928206655586304.000000 1.928249
vt -3437403581334206476565834471833600.000000 1.928330
```Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/84Make OpenMesh build without prev halfedge again.2023-11-14T08:05:07ZJan Möbiusmoebius@cs.rwth-aachen.deMake OpenMesh build without prev halfedge again.For memory conservation purposes I would like to utilize the documented option to not store the previous halfedge handle in the Halfedge struct. Removing the above trait doesn't accomplish this, and ArrayItems.hh is hard-coded to use the...For memory conservation purposes I would like to utilize the documented option to not store the previous halfedge handle in the Halfedge struct. Removing the above trait doesn't accomplish this, and ArrayItems.hh is hard-coded to use the version with the previous handle:
```
//TODO: should be selected with config.h define
typedef Halfedge_with_prev Halfedge;
typedef GenProg::Bool2Type<true> HasPrevHalfedge;
```
This code is the same at the start of the Git repo from around 10 years ago. Does anyone know why this option was removed, or if there are any fundamental reasons it wouldn't still work?
As an aside, I was surprised to see there is no specialization for triangle meshes for the non-stored previous handle, since for triangle meshes it is just two next dereferences. I guess this option was never really used.Daniel SavchenkoDaniel Savchenkohttps://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/78missing #include for calc_centroid(MeshHandle)2021-03-17T09:37:13ZJanis Bornmissing #include for calc_centroid(MeshHandle)The implementation of `calc_centroid(MeshHandle)` in `PolyMeshT_impl.hh` uses `getPointsProperty`, which is defined in `PropertyManager.hh` but not included.
When you instantiate `calc_centroid(MeshHandle)` without having `PropertyManag...The implementation of `calc_centroid(MeshHandle)` in `PolyMeshT_impl.hh` uses `getPointsProperty`, which is defined in `PropertyManager.hh` but not included.
When you instantiate `calc_centroid(MeshHandle)` without having `PropertyManager.hh` included, you get a compile error.Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/76Is that save?2021-01-29T11:08:24ZJan Möbiusmoebius@cs.rwth-aachen.deIs that save?src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save w...src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save while adding Edges / Faces to the underlying vector?Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@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/73Bug in PropertyT<bool> restore function2021-01-25T14:58:48ZJan Möbiusmoebius@cs.rwth-aachen.deBug in PropertyT<bool> restore functionI stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs...I stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs at the beginning of the for loop where the bit packing happens (around
line 313). The problematic statement is `_istr >> bits;`
The problem is `std::istream` by default skips white space characters
(https://en.cppreference.com/w/cpp/io/manip/skipws), so if one of the bytes in the stream
being restored happens to be 0x20 (32 - 'space' character), it will be skipped,
leading to the stream getting out of sync with the bytes read (I was able to track this
down using lots of `_is.tellg();` calls).
I've made a minimal change in Property.hh to ensure white space characters aren't
skipped: `_istr >> std::noskipws;` right before the for loop. There might be a
better more central place to enable this setting but it resolves the bug for us for now.
If anyone has any feedback on the best place for this fix I'd love to know!Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/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.de