OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2019-04-09T14:18:48Zhttps://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/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/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/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/61OpenMesh Assignment Problem2018-12-10T08:49:06ZJan Möbiusmoebius@cs.rwth-aachen.deOpenMesh Assignment ProblemDear OpenMesh maintainers, When assigning a mesh as follows meshB.assign_connectivity(meshA); with meshA comprising a vertex status property, meshB.release_vertex_status(); makes OpenMesh crash. The reason seems to be that meshB has a "v...Dear OpenMesh maintainers, When assigning a mesh as follows meshB.assign_connectivity(meshA); with meshA comprising a vertex status property, meshB.release_vertex_status(); makes OpenMesh crash. The reason seems to be that meshB has a "valid" vertex status property handle, but not a vertex status property. I attached a minimal example to reproduce. I suspect this bug to have been introduced by this commit https://graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/commit/29cbe820484... best regards, SimonOpenMesh 8.0https://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/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/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/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/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/55add the TriangleBSPTree to OpenMesh2018-06-05T11:48:45ZJanis Bornadd the TriangleBSPTree to OpenMeshSpatial queries on meshes seem to be a common task [(see question here)](https://stackoverflow.com/questions/50696430/find-neighbours-inside-query-in-openmesh).
ACG provides a TriangleBSPTree which seems to work well for this purpose, b...Spatial queries on meshes seem to be a common task [(see question here)](https://stackoverflow.com/questions/50696430/find-neighbours-inside-query-in-openmesh).
ACG provides a TriangleBSPTree which seems to work well for this purpose, but ACG is not bundled with OpenMesh. Should we migrate the TriangleBSPTree from ACG to OpenMesh?https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/54get_property inconsistent return value over build configs2020-04-02T07:39:21ZMatthias Möllerget_property inconsistent return value over build configsHi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(pro...Hi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(prop_vec, name); //<-- request handle with wrong type
```
The output in result depends on the Build Configuration.
- In Debug mode, following holds: `result==false`
- In Release mode, following holds: `result==true`
It is because in "PropertyContainer.h", the type check is disabled in Release mode (line 126-128).
The function should return the same value over the different
build configurations.
(I would prefer the type check enabled, because it seems to be complex, checking outside of the PropertyContainer if the type of your prophandle is the correct one
__edit__ or provide an additional member-function "has_type", or something like this, skipping the dynamic_cast in get_property)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/53swap_*_indices methods2018-05-03T14:28:04ZJanis Bornswap_*_indices methodsOpenVolumeMesh provides [methods](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/blob/master/src/OpenVolumeMesh/Core/TopologyKernel.hh#L528) to reorder the indices of mesh elements (e.g. `swap_vertex_indices`) wit...OpenVolumeMesh provides [methods](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/blob/master/src/OpenVolumeMesh/Core/TopologyKernel.hh#L528) to reorder the indices of mesh elements (e.g. `swap_vertex_indices`) without affecting the geometry or structure of the mesh in any other way. This is quite useful for reindexing mesh data when working in matrix form in order to achieve a certain block structure.
It would be useful to have the same feature in OpenMesh.https://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/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/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/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/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/47Binary STL Files are recogniced as ASCII2017-09-26T13:42:04ZMartin SchultzBinary STL Files are recogniced as ASCII```
[...] in the function _STLReader_::check_stl_type() (STLReader.cc file) you assume that a STL is encoded in ASCII format by looking for the keyword solid, i.e., line 476:
//check for ascii keyword solid
if(strnicmp("solid",&l...```
[...] in the function _STLReader_::check_stl_type() (STLReader.cc file) you assume that a STL is encoded in ASCII format by looking for the keyword solid, i.e., line 476:
//check for ascii keyword solid
if(strnicmp("solid",&line[firstChar],5) == 0)
{
return STLA;
}
The problem is that also some binary STL files start with the "solid" keyword, and it seems the standard allows it, at least looking at the first references I've found:
https://people.sc.fsu.edu/~jburkardt/data/stla/stla.html
https://people.sc.fsu.edu/~jburkardt/data/stlb/stlb.html
[...]
a workaround solution could be to look for the keyword "facet" in place of the keyword "solid" [...]
by Alberto Pretto
```
Related to: https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/merge_requests/83
example file to trigger this issue:
[sportellino.stl](/uploads/7a3200439fbb8bff53dad0527d10a5f0/sportellino.stl)https://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 Schultz