OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2017-10-27T14:34:54Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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