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/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/36Phong shading looks funny when using Shader Pipeline Renderer2017-05-01T10:16:22ZJanis BornPhong shading looks funny when using Shader Pipeline RendererConsider the following images of the same object. The first is rendered using the Default Internal Renderer, while the second one is rendered using the Shader Pipeline Renderer.
![phong-classical](/uploads/715664c92b2ca66ce89c0a22c5bb1e...Consider the following images of the same object. The first is rendered using the Default Internal Renderer, while the second one is rendered using the Shader Pipeline Renderer.
![phong-classical](/uploads/715664c92b2ca66ce89c0a22c5bb1e72/phong-classical.png)
![phong-shader-pipeline](/uploads/17d0c5c32397e5930c5fd96ed573fa3f/phong-shader-pipeline.png)
(Ignore the fact that the first picture only shows highlights from one light source; That's a limitation of the old renderer.) Notice how the shape of the highlight in the first picture is smooth while the highlights in the second picture exhibit noticeable artifacts, exposing the tessellation of the rendered object.
I suspect there's something wrong with the interpolation of normals in the new Phong shader. Can you check?Christopher TenterChristopher Tenterhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/35Converting tri- polymesh leaves standard propertyhandles uninitialized2017-05-01T10:16:22ZMartin SchultzConverting tri- polymesh leaves standard propertyhandles uninitializedwhen a mesh is converted from poly to tri or vice versa, the standard propertyhandles are not initialized.
e.g. points_ is -135.
Handles should be initialized after conversion. For the refcounting i recommend to set refcounters of the ...when a mesh is converted from poly to tri or vice versa, the standard propertyhandles are not initialized.
e.g. points_ is -135.
Handles should be initialized after conversion. For the refcounting i recommend to set refcounters of the converted mesh to 1 if the property was set.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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/59OpenMesh with Eigen2019-01-17T08:42:43ZJan Möbiusmoebius@cs.rwth-aachen.deOpenMesh with EigenWe had an issue with the interoperability of OpenMesh and Eigen because Eigen does not provide matrix constructors from a single value, while such constructors happen to be used (we found only two use cases) in OpenMesh.
Would you consi...We had an issue with the interoperability of OpenMesh and Eigen because Eigen does not provide matrix constructors from a single value, while such constructors happen to be used (we found only two use cases) in OpenMesh.
Would you consider fixing this ? Please find a patch implementing the changes in attachment.OpenMesh 8.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/40Creating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected...2019-01-15T15:13:18ZKersten SchusterCreating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected) for GCC, but not for MSVC (2013)One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : c...One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : cannot convert from 'int' to 'ACG::Vec3d'
No constructor could take the source type, or constructor overload resolution was ambiguousJanis BornJanis Bornhttps://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/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/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/66heap-buffer-overflow while adding an invalid triangle face2021-01-29T11:08:44ZSven-Kristofer Pilzheap-buffer-overflow while adding an invalid triangle faceI came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::P...I came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::PolyConnectivity::add_face(OpenMesh::VertexHandle const*, unsigned long)`).
```cpp
#include <OpenMesh/Core/Mesh/PolyMesh_ArrayKernelT.hh>
typedef OpenMesh::PolyMesh_ArrayKernelT<> MyMesh;
int main()
{
MyMesh mesh;
const auto a = mesh.add_vertex(MyMesh::Point{-6.95757 -0.418557 -7.25885});
const auto b = mesh.add_vertex(MyMesh::Point{-7.03569 -0.128014 -7.26395});
mesh.add_face(a,b,a);
return 0;
}
```
When run with assertions enabled, this triggers:
> OpenMesh/Core/Mesh/PolyConnectivity.cc:272: OpenMesh::ArrayKernel::FaceHandle OpenMesh::PolyConnectivity
> ::add_face(const VertexHandle*, size_t): Assertion `boundary_prev.is_valid()' failed.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/67property visualizer, edge property visualization2019-08-07T13:30:09ZNicolas Gallego-Ortizproperty visualizer, edge property visualizationSystem: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected be...System: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected behavior when visualizing edge properties of meshes (OpenMesh) with the property visualization plugin. I the provided file there is a triangle mesh of a plane, and an edge property saved from it.
I get this error message on the console, and the mesh is rendered as a tube on the z-direction as shown in the image. The plane mesh can be seen after clicking on the object for a short time but the edges shown are not those of the original mesh.
I would be happy to help solve this issue, for now just let me know if you can reproduce it in other systems and some hints on where to start the debugging process.
Thanks,
Nicolas
```
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:650 - 1282
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:704 - 1282 - inColor
```
[mesh2.om](/uploads/7d19640750d0d63bac96123c433397d2/mesh2.om)
[kappa.eprop](/uploads/85cb68a117b9b3876525ecc5ce580307/kappa.eprop)
![screenshot](/uploads/086c07c3b29a4618be864f85cb6e206e/screenshot.png)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/68Lots of warnings2019-12-03T11:23:55ZJan Möbiusmoebius@cs.rwth-aachen.deLots of warningsOpenMesh/Core/Mesh/CirculatorsT.hh:319:49: warning: unused variable 'self' [-Wunused-variable]
const GenericCirculatorBaseT<Mesh>* self = this;
Also line 508 ...OpenMesh/Core/Mesh/CirculatorsT.hh:319:49: warning: unused variable 'self' [-Wunused-variable]
const GenericCirculatorBaseT<Mesh>* self = this;
Also line 508 ...OpenMesh 8.1Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/69Tons of warnings on windows, clang, ...2021-01-25T14:59:07ZJan Möbiusmoebius@cs.rwth-aachen.deTons of warnings on windows, clang, ...DLL Warnings on Windows
Unused Variables ...DLL Warnings on Windows
Unused Variables ...OpenMesh 8.1Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/71Docu pics broken2020-03-18T08:22:32ZJan Möbiusmoebius@cs.rwth-aachen.deDocu pics brokenJan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/72Eigen tests fail to compile on Linux with Eigen 3.3.72020-04-20T05:58:58ZMartin HeistermannEigen tests fail to compile on Linux with Eigen 3.3.7With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/cl...With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/clang++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc:98:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
../src/Unittests/unittests_eigen3_type.cc:104:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: calling a protected constructor of class 'Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >'
return x;
^
../src/Unittests/unittests_eigen3_type.cc:98:3: note: in instantiation of function template specialization 'Eigen::normalize<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' requested here
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:5:
In file included from ../src/Unittests/../Unittests/unittests_common.hh:7:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:12: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
return normalize(n);
^
../src/Unittests/unittests_eigen3_type.cc:28:7: note: in instantiation of member function 'OpenMesh::PolyMeshT<OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity> >::calc_halfedge_normal' requested here
class OpenMeshEigenTest : public testing::Test {
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
4 errors generated.
```
GCC:
```
/usr/lib/ccache/c++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc: In member function ‘virtual void {anonymous}::OpenMeshEigenTest_Test_external_normalize_Test::TestBody()’:
../src/Unittests/unittests_eigen3_type.cc:98:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
98 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/Unittests/unittests_eigen3_type.cc:104:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
104 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh: In instantiation of ‘Eigen::MatrixBase<Derived> Eigen::normalize(Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’:
../src/Unittests/unittests_eigen3_type.cc:98:19: required from here
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘constexpr Eigen::MatrixBase<Derived>::MatrixBase(const Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
467 | EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
| ^~~~~~~~~~
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:844:65: note: in definition of macro ‘EIGEN_DEFAULT_COPY_CONSTRUCTOR’
844 | #define EIGEN_DEFAULT_COPY_CONSTRUCTOR(CLASS) EIGEN_DEVICE_FUNC CLASS(const CLASS&) = default;
| ^~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64,
from ../src/Unittests/../Unittests/unittests_common.hh:7,
from ../src/Unittests/unittests_eigen3_type.cc:5:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh: In instantiation of ‘OpenMesh::PolyMeshT<Kernel>::Normal OpenMesh::PolyMeshT<Kernel>::calc_halfedge_normal(OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle, double) const [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>; OpenMesh::PolyMeshT<Kernel>::Normal = Eigen::Matrix<double, 3, 1>; OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle = OpenMesh::HalfedgeHandle]’:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:355:29: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_halfedge_normals(double) [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:324:41: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_normals() [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/unittests_eigen3_type.cc:235:25: required from here
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:21: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
407 | return normalize(n);
| ~~~~~~~~~^~~
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/73Bug in PropertyT<bool> restore function2021-01-25T14:58:48ZJan Möbiusmoebius@cs.rwth-aachen.deBug in PropertyT<bool> restore functionI stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs...I stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs at the beginning of the for loop where the bit packing happens (around
line 313). The problematic statement is `_istr >> bits;`
The problem is `std::istream` by default skips white space characters
(https://en.cppreference.com/w/cpp/io/manip/skipws), so if one of the bytes in the stream
being restored happens to be 0x20 (32 - 'space' character), it will be skipped,
leading to the stream getting out of sync with the bytes read (I was able to track this
down using lots of `_is.tellg();` calls).
I've made a minimal change in Property.hh to ensure white space characters aren't
skipped: `_istr >> std::noskipws;` right before the for loop. There might be a
better more central place to enable this setting but it resolves the bug for us for now.
If anyone has any feedback on the best place for this fix I'd love to know!Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/74Eigen3 Finder not included anymore and no global finder available2021-01-15T14:30:32ZJan Möbiusmoebius@cs.rwth-aachen.deEigen3 Finder not included anymore and no global finder availableMartin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/75QT Apps not build on Linux/Mac?2021-02-15T11:37:14ZJan Möbiusmoebius@cs.rwth-aachen.deQT Apps not build on Linux/Mac?Seems to me that we are not compiling the qt apps in OpenMesh anymore. Might be related to the docker changes.
We should build the qt apps again. As in OF, we need one config file/option to specify the version and map it to the locatio...Seems to me that we are not compiling the qt apps in OpenMesh anymore. Might be related to the docker changes.
We should build the qt apps again. As in OF, we need one config file/option to specify the version and map it to the location of the installed qt versions.
Currently we should test on linux against 5.15.1 and 6.0.0
/ACG/acgdev/gcc-x86_64/qt/6.0.0/gcc_64/
/ACG/acgdev/gcc-x86_64/qt-5.15.1/5.15.1/gcc_64/OpenMesh 9.0Johannes LenzenJohannes Lenzenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/76Is that save?2021-01-29T11:08:24ZJan Möbiusmoebius@cs.rwth-aachen.deIs that save?src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save w...src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save while adding Edges / Faces to the underlying vector?Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/78missing #include for calc_centroid(MeshHandle)2021-03-17T09:37:13ZJanis Bornmissing #include for calc_centroid(MeshHandle)The implementation of `calc_centroid(MeshHandle)` in `PolyMeshT_impl.hh` uses `getPointsProperty`, which is defined in `PropertyManager.hh` but not included.
When you instantiate `calc_centroid(MeshHandle)` without having `PropertyManag...The implementation of `calc_centroid(MeshHandle)` in `PolyMeshT_impl.hh` uses `getPointsProperty`, which is defined in `PropertyManager.hh` but not included.
When you instantiate `calc_centroid(MeshHandle)` without having `PropertyManager.hh` included, you get a compile error.Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/79Several warnings for FilteredIterator2022-01-18T11:04:07ZJan Möbiusmoebius@cs.rwth-aachen.deSeveral warnings for FilteredIteratorhttps://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/jobs/128780https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/jobs/128780OpenMesh 9.0Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/81Decimater/Subdivider seem not compatible with Eigen-bases meshes2022-05-05T13:57:18ZSven-Kristofer PilzDecimater/Subdivider seem not compatible with Eigen-bases meshesFor example
```cpp
template<class MeshT>
float ModEdgeLengthT<MeshT>::collapse_priority(const CollapseInfo& _ci) {
typename Mesh::Scalar sqr_length = (_ci.p0 - _ci.p1).sqrnorm();
return ( (sqr_length <= sqr_edge_length_) ? sqr_leng...For example
```cpp
template<class MeshT>
float ModEdgeLengthT<MeshT>::collapse_priority(const CollapseInfo& _ci) {
typename Mesh::Scalar sqr_length = (_ci.p0 - _ci.p1).sqrnorm();
return ( (sqr_length <= sqr_edge_length_) ? sqr_length : float(Base::ILLEGAL_COLLAPSE));
}
```
from: https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/d50cad4640d6d3657c4d0188fbf27ff38e4bfdca/src/OpenMesh/Tools/Decimater/ModEdgeLengthT_impl.hh#L75.
Calls `.sqrnorm()` which is not available, whereas `Core/GeometryEigenVectorT.hh` provides those function in the `Eigen` namespace (for argument-dependent lookup?).
Should that line be `sqrnorm(_ci.p0 - _ci.p1)`?https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/84Make OpenMesh build without prev halfedge again.2023-11-14T08:05:07ZJan Möbiusmoebius@cs.rwth-aachen.deMake OpenMesh build without prev halfedge again.For memory conservation purposes I would like to utilize the documented option to not store the previous halfedge handle in the Halfedge struct. Removing the above trait doesn't accomplish this, and ArrayItems.hh is hard-coded to use the...For memory conservation purposes I would like to utilize the documented option to not store the previous halfedge handle in the Halfedge struct. Removing the above trait doesn't accomplish this, and ArrayItems.hh is hard-coded to use the version with the previous handle:
```
//TODO: should be selected with config.h define
typedef Halfedge_with_prev Halfedge;
typedef GenProg::Bool2Type<true> HasPrevHalfedge;
```
This code is the same at the start of the Git repo from around 10 years ago. Does anyone know why this option was removed, or if there are any fundamental reasons it wouldn't still work?
As an aside, I was surprised to see there is no specialization for triangle meshes for the non-stored previous handle, since for triangle meshes it is just two next dereferences. I guess this option was never really used.Daniel SavchenkoDaniel Savchenkohttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/85OBJ export stores (often bogus) texture coordinates of boundary halfedges2023-03-01T11:02:52ZMartin HeistermannOBJ export stores (often bogus) texture coordinates of boundary halfedgesWhen exporting a mesh as OBJ, unused boundary halfedge-texcoords are stored. They are not used anywhere and the resulting file seems valid.
However if those stem from uninitialized memory, the number of different texture coords can signi...When exporting a mesh as OBJ, unused boundary halfedge-texcoords are stored. They are not used anywhere and the resulting file seems valid.
However if those stem from uninitialized memory, the number of different texture coords can significantly bloat the .obj file size.
Example .obj excerpt
```
vt -76500107434139575140676561222651346944.000000 1.970980
vt -4950073864930567497435155906561048576.000000 -1.834825
vt -1931694947632209777361309154513256448.000000 -1.832364
vt -1238546134728614397081714835220070400.000000 1.814589
vt -707588858575282684185056046137475072.000000 2.654118
vt -73317830722383046556445364377878528.000000 2.735005
vt -19543880572954837544928206655586304.000000 1.928249
vt -3437403581334206476565834471833600.000000 1.928330
```Martin HeistermannMartin Heistermann