OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2019-04-09T14:18:48Zhttps://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/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/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/41Check Clear/Clean2018-06-19T07:11:23ZJan Möbiusmoebius@cs.rwth-aachen.deCheck Clear/CleanClear should remove all additional properties. Clean should keep the properties.Clear should remove all additional properties. Clean should keep the properties.OpenMesh 8.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/37Unittests added for midpoint, but they segfault2017-05-01T10:16:21ZJan Möbiusmoebius@cs.rwth-aachen.deUnittests added for midpoint, but they segfaultBranch is midpoint_unittestBranch is midpoint_unittestOpenMesh 7.0Janis BornJanis Bornhttps://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/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/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/58Peristent Edge Properties2018-11-27T13:40:38ZMax Lyonlyon@cs.rwth-aachen.dePeristent Edge PropertiesThe om file format allows to store meshes together with custom properties. This does not work correctly for edge (and halfedge) properties.
The om file format stores explicitly only vertices and faces (as ordered set of vertices). When ...The om file format allows to store meshes together with custom properties. This does not work correctly for edge (and halfedge) properties.
The om file format stores explicitly only vertices and faces (as ordered set of vertices). When reading from a file, edges are created on the fly when they are needed for a face. This means that the edges in the loaded mesh may be in a different order than in the stored mesh.
Edge properties are stored and loaded in the same order. Thus, the loaded edge properties may not correspond to the edge.
I added a unittest which runs into this problem in commit 84eccff6a64a3749c0d01ff1f8a9b84d050c74cc.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/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/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/34OBJWriter does not support face texture coordinates2017-05-01T10:16:22ZHans-Christian EbkeOBJWriter does not support face texture coordinatesThe `OpenMesh::IO::OBJWriter` class does not support per-halfedge texture coordinates (`OpenMesh::IO::Options::FaceTexCoord`).The `OpenMesh::IO::OBJWriter` class does not support per-halfedge texture coordinates (`OpenMesh::IO::Options::FaceTexCoord`).Martin SchultzMartin Schultzhttps://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/31Cannot write binary stl files2017-05-01T10:16:22ZMartin SchultzCannot write binary stl filesWhen a mesh is saved as a binary stl file, the file contains no data.
Only the header "binary stl file" followed by whitespaces is written When a mesh is saved as a binary stl file, the file contains no data.
Only the header "binary stl file" followed by whitespaces is written Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/21Possible bug in ConstVertexOHalfedgeIter2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.dePossible bug in ConstVertexOHalfedgeIterSee Mailing List entries
See Mailing List entries
Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/20Check OBJ writer patch2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deCheck OBJ writer patchPlease check the patch applied in branch obj_mat_file
* The material file's name for “name.obj” was “nam.obj” (off by
one) and
* a white space was missing between the color components (0.10.20.3
instead of 0.1 0.2 0.3).
Please check the patch applied in branch obj_mat_file
* The material file's name for “name.obj” was “nam.obj” (off by
one) and
* a white space was missing between the color components (0.10.20.3
instead of 0.1 0.2 0.3).
Martin SchultzMartin Schultz