OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2023-11-14T08:05:07Zhttps://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/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/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/79Several warnings for FilteredIterator2022-01-18T11:04:07ZJan Möbiusmoebius@cs.rwth-aachen.deSeveral warnings for FilteredIteratorhttps://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/jobs/128780https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/jobs/128780OpenMesh 9.0Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://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/75QT Apps not build on Linux/Mac?2021-02-15T11:37:14ZJan Möbiusmoebius@cs.rwth-aachen.deQT Apps not build on Linux/Mac?Seems to me that we are not compiling the qt apps in OpenMesh anymore. Might be related to the docker changes.
We should build the qt apps again. As in OF, we need one config file/option to specify the version and map it to the locatio...Seems to me that we are not compiling the qt apps in OpenMesh anymore. Might be related to the docker changes.
We should build the qt apps again. As in OF, we need one config file/option to specify the version and map it to the location of the installed qt versions.
Currently we should test on linux against 5.15.1 and 6.0.0
/ACG/acgdev/gcc-x86_64/qt/6.0.0/gcc_64/
/ACG/acgdev/gcc-x86_64/qt-5.15.1/5.15.1/gcc_64/OpenMesh 9.0Johannes LenzenJohannes Lenzenhttps://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/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/69Tons of warnings on windows, clang, ...2021-01-25T14:59:07ZJan Möbiusmoebius@cs.rwth-aachen.deTons of warnings on windows, clang, ...DLL Warnings on Windows
Unused Variables ...DLL Warnings on Windows
Unused Variables ...OpenMesh 8.1Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://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/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/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/68Lots of warnings2019-12-03T11:23:55ZJan Möbiusmoebius@cs.rwth-aachen.deLots of warningsOpenMesh/Core/Mesh/CirculatorsT.hh:319:49: warning: unused variable 'self' [-Wunused-variable]
const GenericCirculatorBaseT<Mesh>* self = this;
Also line 508 ...OpenMesh/Core/Mesh/CirculatorsT.hh:319:49: warning: unused variable 'self' [-Wunused-variable]
const GenericCirculatorBaseT<Mesh>* self = this;
Also line 508 ...OpenMesh 8.1Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/67property visualizer, edge property visualization2019-08-07T13:30:09ZNicolas Gallego-Ortizproperty visualizer, edge property visualizationSystem: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected be...System: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected behavior when visualizing edge properties of meshes (OpenMesh) with the property visualization plugin. I the provided file there is a triangle mesh of a plane, and an edge property saved from it.
I get this error message on the console, and the mesh is rendered as a tube on the z-direction as shown in the image. The plane mesh can be seen after clicking on the object for a short time but the edges shown are not those of the original mesh.
I would be happy to help solve this issue, for now just let me know if you can reproduce it in other systems and some hints on where to start the debugging process.
Thanks,
Nicolas
```
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:650 - 1282
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:704 - 1282 - inColor
```
[mesh2.om](/uploads/7d19640750d0d63bac96123c433397d2/mesh2.om)
[kappa.eprop](/uploads/85cb68a117b9b3876525ecc5ce580307/kappa.eprop)
![screenshot](/uploads/086c07c3b29a4618be864f85cb6e206e/screenshot.png)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/65Crash in subdivider after a vertex has been deleted2019-04-09T14:18:48ZJan Möbiusmoebius@cs.rwth-aachen.deCrash in subdivider after a vertex has been deletedOpenMesh 8.1Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/64PLY reader fix for ascii fix containing no endl2019-02-04T08:43:48ZJan Möbiusmoebius@cs.rwth-aachen.dePLY reader fix for ascii fix containing no endlThis patch fixes an error happening on ascii ply files without a newline at the end. To repro, remove the ending newline on a ply ascii file. I know it's a good practice to end text files with a newline, but for the PLY format where the ...This patch fixes an error happening on ascii ply files without a newline at the end. To repro, remove the ending newline on a ply ascii file. I know it's a good practice to end text files with a newline, but for the PLY format where the number of elements is specified, it seems unnecessary to be strict about this.OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/59OpenMesh with Eigen2019-01-17T08:42:43ZJan Möbiusmoebius@cs.rwth-aachen.deOpenMesh with EigenWe had an issue with the interoperability of OpenMesh and Eigen because Eigen does not provide matrix constructors from a single value, while such constructors happen to be used (we found only two use cases) in OpenMesh.
Would you consi...We had an issue with the interoperability of OpenMesh and Eigen because Eigen does not provide matrix constructors from a single value, while such constructors happen to be used (we found only two use cases) in OpenMesh.
Would you consider fixing this ? Please find a patch implementing the changes in attachment.OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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 Born