OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2022-05-10T15:03:17Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/80PLY reader fails with face properties before `vertex_indices`2022-05-10T15:03:17ZSven-Kristofer PilzPLY reader fails with face properties before `vertex_indices`It seems the PLY parser forgets to actually skip face properties before `vertex_indices`, resulting in a misread file.
For example:
```
ply
format ascii 1.0
element vertex 3
property float x
property float y
property float z
element fac...It seems the PLY parser forgets to actually skip face properties before `vertex_indices`, resulting in a misread file.
For example:
```
ply
format ascii 1.0
element vertex 3
property float x
property float y
property float z
element face 1
property int bad_property
property list uchar int vertex_indices
end_header
```
For me, the following (removing `elements_.back().properties_.clear();`) worked:
```diff
diff --git a/src/OpenMesh/Core/IO/reader/PLYReader.cc b/src/OpenMesh/Core/IO/reader/PLYReader.cc
index 5ab21b74..8ba7abc3 100644
--- a/src/OpenMesh/Core/IO/reader/PLYReader.cc
+++ b/src/OpenMesh/Core/IO/reader/PLYReader.cc
diff --git a/src/OpenMesh/Core/IO/reader/PLYReader.cc b/src/OpenMesh/Core/IO/reader/PLYReader.cc
index 5ab21b74..8ba7abc3 100644
--- a/src/OpenMesh/Core/IO/reader/PLYReader.cc
+++ b/src/OpenMesh/Core/IO/reader/PLYReader.cc
@@ -529,7 +529,7 @@ bool _PLYReader_::read_ascii(std::istream& _in, BaseImporter& _bi, const Options
omerr().enable();
if (complex_faces)
- omerr() << complex_faces << "The reader encountered invalid faces, that could not be added.\n";
+ omerr() << "The reader encountered invalid faces (" << complex_faces << "), that could not be added.\n";
// File was successfully parsed.
return true;
@@ -783,7 +783,7 @@ bool _PLYReader_::read_binary(std::istream& _in, BaseImporter& _bi, bool /*_swap
omerr().enable();
if (complex_faces)
- omerr() << complex_faces << "The reader encountered invalid faces, that could not be added.\n";
+ omerr() << "The reader encountered invalid faces (" << complex_faces << "), that could not be added.\n";
return true;
@@ -1298,7 +1298,6 @@ bool _PLYReader_::can_u_read(std::istream& _is) const {
if (!elements_.back().properties_.empty())
{
omerr() << "Custom face Properties defined, before 'vertex_indices' property was defined. They will be skipped" << std::endl;
- elements_.back().properties_.clear();
}
} else {
options_ += Options::Custom;
diff --git a/src/Unittests/TestFiles/property_before_face_vertex_list.ply b/src/Unittests/TestFiles/property_before_face_vertex_list.ply
new file mode 100644
index 00000000..f0dff8f9
--- /dev/null
+++ b/src/Unittests/TestFiles/property_before_face_vertex_list.ply
@@ -0,0 +1,14 @@
+ply
+format ascii 1.0
+element vertex 3
+property float x
+property float y
+property float z
+element face 1
+property int bad_property
+property list uchar int vertex_indices
+end_header
+-1.0 0.0 0.0
+1.0 0.0 0.0
+0.0 1.0 0.0
+0 3 0 1 2
diff --git a/src/Unittests/unittests_read_write_PLY.cc b/src/Unittests/unittests_read_write_PLY.cc
index 9cb614d7..ac797998 100644
--- a/src/Unittests/unittests_read_write_PLY.cc
+++ b/src/Unittests/unittests_read_write_PLY.cc
@@ -633,6 +633,21 @@ TEST_F(OpenMeshReadWritePLY, LoadSimplePLYWithCustomProps) {
}
+TEST_F(OpenMeshReadWritePLY, LoadWithFacePropertyBeforeVertexList) {
+ PolyMesh mesh;
+
+ OpenMesh::IO::Options options;
+ options += OpenMesh::IO::Options::Custom;
+
+ bool ok = OpenMesh::IO::read_mesh(mesh, "property_before_face_vertex_list.ply", options);
+
+ EXPECT_TRUE(ok) << "Unable to load property_before_face_vertex_list.ply";
+
+ EXPECT_EQ(3u , mesh.n_vertices()) << "The number of loaded vertices is not correct!";
+ EXPECT_EQ(3u , mesh.n_edges()) << "The number of loaded edges is not correct!";
+ EXPECT_EQ(1u , mesh.n_faces()) << "The number of loaded faces is not correct!";
+}
+
/*
* Just load a ply with custom properties, binary mode
*/
```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/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/54get_property inconsistent return value over build configs2020-04-02T07:39:21ZMatthias Möllerget_property inconsistent return value over build configsHi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(pro...Hi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(prop_vec, name); //<-- request handle with wrong type
```
The output in result depends on the Build Configuration.
- In Debug mode, following holds: `result==false`
- In Release mode, following holds: `result==true`
It is because in "PropertyContainer.h", the type check is disabled in Release mode (line 126-128).
The function should return the same value over the different
build configurations.
(I would prefer the type check enabled, because it seems to be complex, checking outside of the PropertyContainer if the type of your prophandle is the correct one
__edit__ or provide an additional member-function "has_type", or something like this, skipping the dynamic_cast in get_property)https://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/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/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/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/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/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 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 Schultz