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/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/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/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/3calling vv_range on valence 0 vertices causes a crash2017-10-27T14:34:54ZMartin Schultzcalling vv_range on valence 0 vertices causes a crashWhen you call vv_range on a vertexhandle of a vertex with valence 0 OpenMesh will crash as vv_range uses the circulatorRange which uses cvv_end and cvv_begin which are marked as deprecated.
I propose to use cvv_cwend and cvv_cwbegin w...When you call vv_range on a vertexhandle of a vertex with valence 0 OpenMesh will crash as vv_range uses the circulatorRange which uses cvv_end and cvv_begin which are marked as deprecated.
I propose to use cvv_cwend and cvv_cwbegin which are mentioned in the documentation to be used instead of the deprecated one.Martin SchultzMartin Schultzhttps://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/52Move towards using free functions on built-in properties.2018-05-30T09:00:14ZChristian MattesMove towards using free functions on built-in properties.OpenMesh supports changing the type of the built-in properties (like the vertex position), which is a great feature.
For this to work however, the types have to implement certain methods such as `length()` and `normalize()` (as member m...OpenMesh supports changing the type of the built-in properties (like the vertex position), which is a great feature.
For this to work however, the types have to implement certain methods such as `length()` and `normalize()` (as member methods).
Replacing the calls to those methods by calls to free methods of the same name (and then implementing those free methods for the OpenMesh built-in Vectors as calls to the member) would make it easier to support new types for Points.
E.g. to use Eigen's Vector types with OpenMesh, it is currently required to use Eigen's "plugin" system, which can cause the program to fail in hard to debug ways.Christian MattesChristian Mattes