OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2019-01-15T14:07:52Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/63Warnings with gcc 8.22019-01-15T14:07:52ZJan Möbiusmoebius@cs.rwth-aachen.deWarnings with gcc 8.2OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/60OBJ Writer/Reader Issue2019-01-15T14:07:52ZJan Möbiusmoebius@cs.rwth-aachen.deOBJ Writer/Reader IssueHi all,
I found an issue regarding the OBJ writer and saving Face TexCoords.
Basically, what I'm seeing is that the OBJ writer is adding extra vt entries into the OBJ file. The file still works in Meshlab if I add the missing MTL head...Hi all,
I found an issue regarding the OBJ writer and saving Face TexCoords.
Basically, what I'm seeing is that the OBJ writer is adding extra vt entries into the OBJ file. The file still works in Meshlab if I add the missing MTL header to the top of the OBJ file, but I'm unable to reopen the file using OpenMesh.
The error I'm getting is "Only single 2D or 3D texture coordinate per vertexallowed!". From what I'm seeing, the new OBJ file has (in my case) an additonal 983 VT entries.
To open the mesh, I'm doing:
OpenMesh::IO::Options ropt;
ropt += OpenMesh::IO::Options::FaceTexCoord;
_mesh.request_vertex_normals();
_mesh.request_face_normals();
_mesh.request_halfedge_texcoords2D();
if (!OpenMesh::IO::read_mesh(_mesh, path, ropt))
{
return false;
}
_mesh.update_normals();
To save the mesh, I'm doing:
OpenMesh::IO::Options wopt;
if (_mesh.has_vertex_normals())
{
wopt += OpenMesh::IO::Options::VertexNormal;
}
if (_mesh.has_halfedge_texcoords2D())
{
std::cout << "has 2d" << std::endl;
wopt += OpenMesh::IO::Options::FaceTexCoord;
}
if (!OpenMesh::IO::write_mesh(_mesh, path, wopt))
return true;
There have been no modifications to the file.OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/56Mention new OM python bindings in Documentation2018-12-06T08:20:56ZMartin HeistermannMention new OM python bindings in Documentationhttps://www.openmesh.org/Daily-Builds/Doc/a00036.html only describes the old python bindings, which can lead to confusion (see OM mailing list on 2016-06-08), I think we should (very visibly) refer to the new bindings there.https://www.openmesh.org/Daily-Builds/Doc/a00036.html only describes the old python bindings, which can lead to confusion (see OM mailing list on 2016-06-08), I think we should (very visibly) refer to the new bindings there.Isaak LimIsaak Limhttps://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/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/57Add SmartTagger to OpenMesh2018-10-30T09:20:21ZJan Möbiusmoebius@cs.rwth-aachen.deAdd SmartTagger to OpenMesh@born@bornOpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/51split_edge Creates Non-Triangular Faces on TriMeshes2018-10-30T09:20:21ZMax Lyonlyon@cs.rwth-aachen.desplit_edge Creates Non-Triangular Faces on TriMeshes```PolyConnectivity``` implements the two methods ```split_edge(EdgeHandle, VertexHandle)``` and ```split_edge_copy(EdgeHandle, VertexHandle)``` which split an edge without splitting the incident faces, thus increasing the valence of the...```PolyConnectivity``` implements the two methods ```split_edge(EdgeHandle, VertexHandle)``` and ```split_edge_copy(EdgeHandle, VertexHandle)``` which split an edge without splitting the incident faces, thus increasing the valence of the incident faces by one.
```TriConnectivity``` implements the two similar methods ```split(EdgeHandle, VertexHandle)``` and ```split_copy(EdgeHandle, VertexHandle)``` which do split the incident faces, thus performing a 2 to 4 split (or 1 to 2 split on boundaries) as expected.
Since ```TriConnectivity``` publicly inherits from ```PolyConnectivity```, ```split_edge``` can be called on a ```TriConnectivity``` resulting in non-triangular faces.
Should we add ```split_edge``` and ```split_edge_copy``` methods to ```TriConnectivity``` which call ```split``` and ```split_edge``` to prevent this?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/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/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 Matteshttps://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/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/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/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/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/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/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/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/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/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.de