OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2017-06-30T13:25:18Zhttps://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/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/43Cannot compile OpenMesh with unittests enabled2017-06-29T08:32:21ZMartin SchultzCannot compile OpenMesh with unittests enabledI can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
``...I can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
```
The default gtest library is selected by cmake as
/ACG/acgdev/gcc-4.7-x86_64/gtest/
but since the lab machines have been updated the gcc --version command states the compiler version is 6.3.0. I tried using the gtest library from /ACG/acgdev/gcc-4.9-x86_64/gtest/ but it gives the same error.
Is this caused by incompatibilities of the older gcc versions / libraries built with it?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/42Decimater ModRoundness alway collapses2017-05-05T14:26:01ZDaniel GotzenDecimater ModRoundness alway collapsesIn ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.In ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.Daniel GotzenDaniel Gotzenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/41Check Clear/Clean2018-06-19T07:11:23ZJan Möbiusmoebius@cs.rwth-aachen.deCheck Clear/CleanClear should remove all additional properties. Clean should keep the properties.Clear should remove all additional properties. Clean should keep the properties.OpenMesh 8.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/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/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/38Vector11T ctor refactoring2022-01-07T14:41:02ZJanis BornVector11T ctor refactoringIdeally, there would be a constructor accepting a mixture of arguments which can be converted to `Scalar` as well as `Scalar` rvalues which are then moved to the appropriate location.Ideally, there would be a constructor accepting a mixture of arguments which can be converted to `Scalar` as well as `Scalar` rvalues which are then moved to the appropriate location.https://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/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 Schultz