OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2017-05-05T14:26:01Zhttps://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/43Cannot compile OpenMesh with unittests enabled2017-06-29T08:32:21ZMartin SchultzCannot compile OpenMesh with unittests enabledI can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
``...I can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
```
The default gtest library is selected by cmake as
/ACG/acgdev/gcc-4.7-x86_64/gtest/
but since the lab machines have been updated the gcc --version command states the compiler version is 6.3.0. I tried using the gtest library from /ACG/acgdev/gcc-4.9-x86_64/gtest/ but it gives the same error.
Is this caused by incompatibilities of the older gcc versions / libraries built with it?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/45Possible importer Bug?2017-06-30T13:25:18ZJan Möbiusmoebius@cs.rwth-aachen.dePossible importer Bug?Können Sie folgenden Bug bestätigen oder widerlegen:
Wir vermuten, dass in OpenMesh/Core/IO/importer/ImporterT.hh in der Funktion
virtual FaceHandle add_face(const VHandles& _indices)
folgende Zeile 160:
FaceHandle fh = me...Können Sie folgenden Bug bestätigen oder widerlegen:
Wir vermuten, dass in OpenMesh/Core/IO/importer/ImporterT.hh in der Funktion
virtual FaceHandle add_face(const VHandles& _indices)
folgende Zeile 160:
FaceHandle fh = mesh_.add_face(vhandles);
durch diese zu ersetzen ist:
fh = mesh_.add_face(vhandles);
Dh. soll die FaceHandle fh des darüberliegenden Scopes überschrieben werden?
Dann würde die Funktion eine gültige FaceHandle zurückgeben.OpenMesh 7.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/44possible PolyConnectivity::split_edge_copy() bug2017-07-03T13:51:00ZJan Möbiusmoebius@cs.rwth-aachen.depossible PolyConnectivity::split_edge_copy() bugI would like to report a possible bug/design limitation in PolyConnectivity::split_edge_copy(). Apologies if it has been resolved recently, I have not checked the most recent version.
PolyConnectivity::split_edge_copy() does not copy...I would like to report a possible bug/design limitation in PolyConnectivity::split_edge_copy(). Apologies if it has been resolved recently, I have not checked the most recent version.
PolyConnectivity::split_edge_copy() does not copy built-in properties, and it does not offer the option to do so. This is undesirable, since it forces us to write the following unwieldy code on the caller side to propagate the status property for instance (e.g. to propagate the feature status when splitting).
quad_mesh_->split_edge_copy(eh, rfn_ehs[eh]); // does not copy status...?!
// .... hence we need to copy the status on our own!
const auto new_eh = quad_mesh_->edge_handle(
quad_mesh_->next_halfedge_handle(quad_mesh_->halfedge_handle(eh, 1)));
quad_mesh_->status(new_eh) = quad_mesh_->status(eh);
In addition to being unwieldy, this code relies on internal knowledge of how the new edge is allocated and is prone to breakage if internal behaviour changes. Maybe the best option here is to add and propagate the bool _copyBuildIn = false parameter from the void copy_all_properties(FaceHandle _fh_from, FaceHandle _fh_to, bool _copyBuildIn = false) to PolyConnectivity::split_edge_copy(). This is a binary in-compatible change, so you might want to leave this to version 7 (that is if you are using semver).OpenMesh 7.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/49OBJ Writer UV Coordinates2017-10-26T10:24:30ZJan Möbiusmoebius@cs.rwth-aachen.deOBJ Writer UV CoordinatesHallo!
Die UV coordinaten werden nicht richtig geschrieben:
```
=======================================
diff --git a/src/OpenMesh/Core/IO/writer/OBJWriter.cc
b/src/OpenMesh/Core/IO/writer/OBJWriter.cc
index 66cf3b3f..698e8bae 100644
...Hallo!
Die UV coordinaten werden nicht richtig geschrieben:
```
=======================================
diff --git a/src/OpenMesh/Core/IO/writer/OBJWriter.cc
b/src/OpenMesh/Core/IO/writer/OBJWriter.cc
index 66cf3b3f..698e8bae 100644
--- a/src/OpenMesh/Core/IO/writer/OBJWriter.cc
+++ b/src/OpenMesh/Core/IO/writer/OBJWriter.cc
@@ -363,1 +363,1 @@
write(std::ostream&·_out, BaseExporter& _be, Options
_opt, std::streamsize _prec
{
// write vertex texture coordinate index
if (_opt.check(Options::VertexTexCoord))
- _out << texMap[_be.texcoord(vh)];
+ _out << texMap[_be.texcoord(vhandles[j])];
}
// write vertex normal index
```OpenMesh 7.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/12CPPCHECK Hint2017-10-27T14:34:54ZJan Möbiusmoebius@cs.rwth-aachen.deCPPCHECK Hint[OpenMesh/Core/Geometry/VectorT.hh:254]: (performance) Function parameter '_v' should be passed by reference.
[OpenMesh/Core/Geometry/VectorT.hh:254]: (performance) Function parameter '_v' should be passed by reference.
Janis BornJanis Bornhttps://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/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/48Copy constructor adding face status twice?2017-11-08T10:18:45ZJan Möbiusmoebius@cs.rwth-aachen.deCopy constructor adding face status twice?Konkret tritt das Problem beim Löschen der face properties auf.
Ich habe den Verdacht, dass eine doppelte face status property die Ursache für das Problem ist.
Nach meiner Einschätzgun erzeugt der copy constructor eines tri mesh erzeug...Konkret tritt das Problem beim Löschen der face properties auf.
Ich habe den Verdacht, dass eine doppelte face status property die Ursache für das Problem ist.
Nach meiner Einschätzgun erzeugt der copy constructor eines tri mesh erzeugt die face status property doppelt:
IGM::TriMesh triMesh(quadMesh);
Der status property ist bereits vorhanden, jedoch ist der Referenzzähler auf 0 gesetzt, so dass diese doppelt
erzeugt wird.OpenMesh 7.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/50Standard Properties after Assignment2018-03-19T15:21:26ZMax Lyonlyon@cs.rwth-aachen.deStandard Properties after AssignmentIf a mesh which has standard properties is assigned a mesh which does not, the former will have no standard properties (as expected, I guess) but a positive ref count. When standard properties are than requested, they are not created due...If a mesh which has standard properties is assigned a mesh which does not, the former will have no standard properties (as expected, I guess) but a positive ref count. When standard properties are than requested, they are not created due to that positive ref count. Only for the four status properties does this work.
I added a unit test in da81dbaffa3222041c9edb42b8ad22ab38342afe for reproducibility.Martin SchultzMartin Schultzhttps://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/16Python Unittests segfaulting2018-04-05T09:11:56ZIsaak LimPython Unittests segfaultingOn MacOS and Linux the unittests for the python bindings will segfault occasionally.
This also happens for boost versions > 1.55 (and for all possible combinations of compilers and c++ standards see [here](https://www.graphics.rwth-aa...On MacOS and Linux the unittests for the python bindings will segfault occasionally.
This also happens for boost versions > 1.55 (and for all possible combinations of compilers and c++ standards see [here](https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/builds?scope=all)).
So far this has only happend for release builds and not debug builds, which might imply that there is a problem with uninitialized variables.
Cppcheck seems to be very happy with the bindings code.
Perhaps you have to run the unittests with valgrind ([[0]](http://valgrind.org/docs/manual/mc-manual.html) [[1]](http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/) [[2]](http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/messages.html)) to find the memory mismanagment bug.Alexander DielenAlexander Dielenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/29Python bindings fail to build with Visual Studio 14 20152018-04-05T09:13:11ZGhost UserPython bindings fail to build with Visual Studio 14 2015[log-4.txt](/uploads/1d549779d2af4776dfc94331ebad874b/log-4.txt)
This prevents to build bindings for conda environment (it's fine for linux & osx :)
```
[00:03:28] Scanning dependencies of target openmesh
[00:03:28] [ 97%] Building...[log-4.txt](/uploads/1d549779d2af4776dfc94331ebad874b/log-4.txt)
This prevents to build bindings for conda environment (it's fine for linux & osx :)
```
[00:03:28] Scanning dependencies of target openmesh
[00:03:28] [ 97%] Building CXX object src/Python/CMakeFiles/openmesh.dir/Bindings.cc.obj
[00:03:28] Bindings.cc
[00:03:32] C:\Miniconda35\conda-bld\work\OpenMesh-6.2\src\Python\..\Python/Vector.hh(148): error C2902: 'operator': unexpected token following 'template', identifier expected
[00:03:32]
[00:03:32] C:\Miniconda35\conda-bld\work\OpenMesh-6.2\src\Python\Bindings.cc(107): note: see reference to function template instantiation 'void OpenMesh::Python::expose_vec<float,2>(const char *)' being compiled
[00:03:32]
[00:03:32] NMAKE : fatal error
[00:03:32] U1077: 'C:\PROGRA~2\MI0E91~1.0\VC\bin\cl.exe' : return code '0x2'
[00:03:32] Stop.
[00:03:32] NMAKE : fatal error
[00:03:32] U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
[00:03:32] Stop.
[00:03:32] NMAKE : fatal error
[00:03:32] U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
[00:03:32] Stop.
[00:03:32] Command failed: C:\windows\system32\cmd.exe /c bld.bat
[00:03:32] Command exited with code 1
```
here's the line it doesn't like:
```.def("dot", &Vector::template operator|<Scalar>)```