OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2017-05-01T10:16:22Zhttps://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/30test_load_obj_with_material segfaults with osx/py3k2018-11-27T13:18:20ZGhost Usertest_load_obj_with_material segfaults with osx/py3kOn osx (compiled with native clang) with Python 3 (3.4 and 3.5 from conda) when running ctest I get this error:
```
***Exception: SegFault
test_load_obj_with_material (test_read_write_obj.ReadWriteOBJ) ...
```
However the test pass...On osx (compiled with native clang) with Python 3 (3.4 and 3.5 from conda) when running ctest I get this error:
```
***Exception: SegFault
test_load_obj_with_material (test_read_write_obj.ReadWriteOBJ) ...
```
However the test passes with Python 2.7, and on Linux it passes with Python3.4/3.5 too,
but I dont see anything python3-specific here.
https://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>)```https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/28Warning with gcc 62017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deWarning with gcc 6/local/moebius/OpenMesh/src/Unittests/../OpenMesh/Core/Mesh/CirculatorsT.hh:507:41: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]/local/moebius/OpenMesh/src/Unittests/../OpenMesh/Core/Mesh/CirculatorsT.hh:507:41: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]OpenMesh 6.3Janis BornJanis Bornhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/27document that DecimaterT::decimate does not trigger a garbage collection2017-05-01T10:16:22ZJanis Borndocument that DecimaterT::decimate does not trigger a garbage collection`DecimaterT::decimate` removes mesh entities but does not trigger a garbage collection. It is expected that a user manually calls `garbage_collection` afterwards.
As indicated by [this question on StackOverflow](http://stackoverflow.com...`DecimaterT::decimate` removes mesh entities but does not trigger a garbage collection. It is expected that a user manually calls `garbage_collection` afterwards.
As indicated by [this question on StackOverflow](http://stackoverflow.com/questions/38483848/openmesh-decimater-does-not-reduce-vertex-number), this is unexpected and causes some confusion.
The fact that `DecimaterT::decimate` does not prompt a garbage collection should be properly documented.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/26Unexpected circulator behavior2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deUnexpected circulator behavior
Hi,
I am currently encountering some unexpected behavior when using
circulators. According to the documentation page at
http://www.openmesh.org/media/Documentations/OpenMesh-Doc-Latest/a00026.html
given a vertex handle, ...
Hi,
I am currently encountering some unexpected behavior when using
circulators. According to the documentation page at
http://www.openmesh.org/media/Documentations/OpenMesh-Doc-Latest/a00026.html
given a vertex handle, I should be able to iterate over the faces
around that vertex using the following code:
auto vertex_face_iter(mesh.cvf_iter(vertex_handle));
for (; vertex_face_iter.is_valid(); ++vertex_face_iter)
{
std::cout << vertex_face_iter->idx() << "\n";
}
The code above basically works, the loop just never terminates. When I
look at the indices printed, I detect an endless loop over the adjacent
faces, e.g.
47833
47838
47834
47842
47833
47838
47834
47842
47833
...
According to the documentation, is_valid() should return false once the
cycle is completed, shouldn't it? The documentation says:
"While it is possible to use operator bool(), which returns true, as
long as the circulator hasn't reached the end of the sequence, this
function is deprecated. Use the function is_valid() instead."
I also looked at the issue list and found a recent remark about
updating the documentation with respect to CW and CCW circulators,
referencing the OpenMesh 4.0 changelog. There, I found a hint stating
"These new iterator versions also fix the problems that
circulators could get valid again, if iterating past the end [...]"
Unfortunately, replacing my existing code with calls to cvf_cwiter() or
cvf_ccwiter() does not alter the behavior in any way, the loop is still
not terminating.
Any ideas as to what is happening here?
Cheers,
Matthew
OpenMesh 6.2Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/25OpenMesh::IO::write_mesh not writing out FaceTexCoord2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deOpenMesh::IO::write_mesh not writing out FaceTexCoordVia Mailinglist:
Hi there,
First time poster. I have a question regarding writing out an OBJ with face texture coordinates. Is it possible?
To write my texture coordinates, I've done the following with my textures being std:...Via Mailinglist:
Hi there,
First time poster. I have a question regarding writing out an OBJ with face texture coordinates. Is it possible?
To write my texture coordinates, I've done the following with my textures being std::vector<OpenMesh::Vec6f>:
this->_mesh.request_halfedge_texcoords2D();
if (!this->_mesh.has_halfedge_texcoords2D())
return false;
//iterate through faces
int f_idx = 0;
for (Mesh::FaceIter it = _mesh.faces_begin(); it != _mesh.faces_end(); ++it)
{
Mesh::FaceHalfedgeIter fh_it = _mesh.fh_iter(*it);
int k = 0;
OpenMesh::Vec6f uv = textures->at(f_idx);
for(; fh_it.is_valid(); ++fh_it) {
_mesh.set_texcoord2D(*fh_it, Mesh::TexCoord2D(uv[2*k], uv[2*k + 1]));
k ++;
}
f_idx ++;
}
I write out the OBJ with:
OpenMesh::IO::Options wopt;
if (_mesh->has_halfedge_texcoords2D()) {
wopt += OpenMesh::IO::Options::FaceTexCoord;
}
std::string path = "out.obj";
if (OpenMesh::IO::write_mesh(*_mesh, path, wopt)) {
return true;
}
Is this correct? The "has_halfedge_texcoords2D" does pass.
Thanks,
Jan-Michael
OpenMesh 6.3Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/24Please check this diff2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.dePlease check this diff[stl.diff](/uploads/066f5c05a203c0a228f641dd1eef3645/stl.diff)[stl.diff](/uploads/066f5c05a203c0a228f641dd1eef3645/stl.diff)Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/23conversion between tri meshes and poly meshes2017-05-01T10:16:22ZJanis Bornconversion between tri meshes and poly meshesTo my knowledge, there are no methods to convert back and forth between triangle and polygon meshes.
The conversion from tri mesh to poly mesh should be straightforward as no modifications are required.
The conversion from poly mes...To my knowledge, there are no methods to convert back and forth between triangle and polygon meshes.
The conversion from tri mesh to poly mesh should be straightforward as no modifications are required.
The conversion from poly mesh to tri mesh requires to perform some kind of triangulation (i.e., `PolyConnectivity::triangulate`). It will also create some new mesh entities (edges, halfedges) which will have no meaningful property values.Janis BornJanis Bornhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/22Add complex face handling to ply reader.2018-06-19T07:12:01ZJan Möbiusmoebius@cs.rwth-aachen.deAdd complex face handling to ply reader.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/19OBJ Reader: Does not load 3D Texture coordinates2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deOBJ Reader: Does not load 3D Texture coordinates
I have an OBJ file which has "vt x,y,z"
I tried setting up for requesting the texture coordinate as 3D
mesh.request_halfedge_texcoords3D();
when I query the resulting data, I get lots of zeros and the occas...
I have an OBJ file which has "vt x,y,z"
I tried setting up for requesting the texture coordinate as 3D
mesh.request_halfedge_texcoords3D();
when I query the resulting data, I get lots of zeros and the occasional NaNs.
If I request for texcoords2D(), it works fine.
I just want to find out if this is a known limitation or bad coding on my part in calling functions in OpenMesh.
I am using OpenMesh 4.1 OpenMesh 6.0Martin 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 Schultzhttps://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/14Document deletion process2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deDocument deletion process
Add documentation about deletion:
Halfedges are updated on the fly, entities removed later.
Circulators ignore deleted entities, iterators only if skipping, ...
See Mailing list for some more info
Add documentation about deletion:
Halfedges are updated on the fly, entities removed later.
Circulators ignore deleted entities, iterators only if skipping, ...
See Mailing list for some more info
https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/13Add some more unittests to cover the following functions2017-05-01T10:16:22ZJan Möbiusmoebius@cs.rwth-aachen.deAdd some more unittests to cover the following functions all writers: binary_size(BaseExporter& _be, Options _opt)
- jacobi smoother with C1 continuity
- some function in IOmanager
- McDecimaterT<Mesh>::decimate_constraints_only
- PolyConnectivity::is_collapse_ok
- PolyConnectivity::is_s... all writers: binary_size(BaseExporter& _be, Options _opt)
- jacobi smoother with C1 continuity
- some function in IOmanager
- McDecimaterT<Mesh>::decimate_constraints_only
- PolyConnectivity::is_collapse_ok
- PolyConnectivity::is_simple_link(EdgeHandle _eh)/ PolyConnectivity::is_simply_connected(FaceHandle _fh)
- PolyConnectivity::remove_edge(EdgeHandle _eh) / PolyConnectivity::insert_edge(HalfedgeHandle _prev_heh, HalfedgeHandle _next_heh) / void PolyConnectivity::reinsert_edge(EdgeHandle _eh) / PolyConnectivity::split_edge/PolyConnectivity::split_edge_copy
- PolyConnectivity::triangulate()
- ArrayKernel::assign_connectivity
- TriConnectivity::vertex_split/ TriConnectivity::insert_loop / TriConnectivity::insert_edge / TriConnectivity::split_copyOpenMesh 6.0https://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 Born