OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2023-02-28T11:45:48Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/83Moveable ctor in OpenMesh2023-02-28T11:45:48ZJan Möbiusmoebius@cs.rwth-aachen.deMoveable ctor in OpenMeshMoveable ctor in OpenMeshMoveable ctor in OpenMeshhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/82Inconsistent capitalization2022-09-09T07:16:14ZMax Lyonlyon@cs.rwth-aachen.deInconsistent capitalization[PropertyManager](https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/master/src/OpenMesh/Core/Utils/PropertyManager.hh) uses `camelCase` instead of the usual `snake_case`.[PropertyManager](https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/blob/master/src/OpenMesh/Core/Utils/PropertyManager.hh) uses `camelCase` instead of the usual `snake_case`.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/80PLY reader fails with face properties before `vertex_indices`2022-05-10T15:03:17ZSven-Kristofer PilzPLY reader fails with face properties before `vertex_indices`It seems the PLY parser forgets to actually skip face properties before `vertex_indices`, resulting in a misread file.
For example:
```
ply
format ascii 1.0
element vertex 3
property float x
property float y
property float z
element fac...It seems the PLY parser forgets to actually skip face properties before `vertex_indices`, resulting in a misread file.
For example:
```
ply
format ascii 1.0
element vertex 3
property float x
property float y
property float z
element face 1
property int bad_property
property list uchar int vertex_indices
end_header
```
For me, the following (removing `elements_.back().properties_.clear();`) worked:
```diff
diff --git a/src/OpenMesh/Core/IO/reader/PLYReader.cc b/src/OpenMesh/Core/IO/reader/PLYReader.cc
index 5ab21b74..8ba7abc3 100644
--- a/src/OpenMesh/Core/IO/reader/PLYReader.cc
+++ b/src/OpenMesh/Core/IO/reader/PLYReader.cc
diff --git a/src/OpenMesh/Core/IO/reader/PLYReader.cc b/src/OpenMesh/Core/IO/reader/PLYReader.cc
index 5ab21b74..8ba7abc3 100644
--- a/src/OpenMesh/Core/IO/reader/PLYReader.cc
+++ b/src/OpenMesh/Core/IO/reader/PLYReader.cc
@@ -529,7 +529,7 @@ bool _PLYReader_::read_ascii(std::istream& _in, BaseImporter& _bi, const Options
omerr().enable();
if (complex_faces)
- omerr() << complex_faces << "The reader encountered invalid faces, that could not be added.\n";
+ omerr() << "The reader encountered invalid faces (" << complex_faces << "), that could not be added.\n";
// File was successfully parsed.
return true;
@@ -783,7 +783,7 @@ bool _PLYReader_::read_binary(std::istream& _in, BaseImporter& _bi, bool /*_swap
omerr().enable();
if (complex_faces)
- omerr() << complex_faces << "The reader encountered invalid faces, that could not be added.\n";
+ omerr() << "The reader encountered invalid faces (" << complex_faces << "), that could not be added.\n";
return true;
@@ -1298,7 +1298,6 @@ bool _PLYReader_::can_u_read(std::istream& _is) const {
if (!elements_.back().properties_.empty())
{
omerr() << "Custom face Properties defined, before 'vertex_indices' property was defined. They will be skipped" << std::endl;
- elements_.back().properties_.clear();
}
} else {
options_ += Options::Custom;
diff --git a/src/Unittests/TestFiles/property_before_face_vertex_list.ply b/src/Unittests/TestFiles/property_before_face_vertex_list.ply
new file mode 100644
index 00000000..f0dff8f9
--- /dev/null
+++ b/src/Unittests/TestFiles/property_before_face_vertex_list.ply
@@ -0,0 +1,14 @@
+ply
+format ascii 1.0
+element vertex 3
+property float x
+property float y
+property float z
+element face 1
+property int bad_property
+property list uchar int vertex_indices
+end_header
+-1.0 0.0 0.0
+1.0 0.0 0.0
+0.0 1.0 0.0
+0 3 0 1 2
diff --git a/src/Unittests/unittests_read_write_PLY.cc b/src/Unittests/unittests_read_write_PLY.cc
index 9cb614d7..ac797998 100644
--- a/src/Unittests/unittests_read_write_PLY.cc
+++ b/src/Unittests/unittests_read_write_PLY.cc
@@ -633,6 +633,21 @@ TEST_F(OpenMeshReadWritePLY, LoadSimplePLYWithCustomProps) {
}
+TEST_F(OpenMeshReadWritePLY, LoadWithFacePropertyBeforeVertexList) {
+ PolyMesh mesh;
+
+ OpenMesh::IO::Options options;
+ options += OpenMesh::IO::Options::Custom;
+
+ bool ok = OpenMesh::IO::read_mesh(mesh, "property_before_face_vertex_list.ply", options);
+
+ EXPECT_TRUE(ok) << "Unable to load property_before_face_vertex_list.ply";
+
+ EXPECT_EQ(3u , mesh.n_vertices()) << "The number of loaded vertices is not correct!";
+ EXPECT_EQ(3u , mesh.n_edges()) << "The number of loaded edges is not correct!";
+ EXPECT_EQ(1u , mesh.n_faces()) << "The number of loaded faces is not correct!";
+}
+
/*
* Just load a ply with custom properties, binary mode
*/
```https://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/77Create nuget packages?2021-02-15T11:36:59ZJan Möbiusmoebius@cs.rwth-aachen.deCreate nuget packages?There is an old unoffical nuget package available.
https://github.com/mworchel/openmesh-nuget
Bad news is, that the tools used seem to be deprecated.There is an old unoffical nuget package available.
https://github.com/mworchel/openmesh-nuget
Bad news is, that the tools used seem to be deprecated.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/70Vertex Split not implemented?2020-03-17T13:13:25ZJan Möbiusmoebius@cs.rwth-aachen.deVertex Split not implemented?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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/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/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/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/10Mark the circulators without direction indicator as deprecated e.g. with the ...2017-06-30T14:05:35ZJan Möbiusmoebius@cs.rwth-aachen.deMark the circulators without direction indicator as deprecated e.g. with the given info belowThe circulator without orientation is deprecated and you should use the new implementation with the given directions. This change was in the OpenMesh 4.0 changelog.
To not break existing code, we still have the old one in place. But ...The circulator without orientation is deprecated and you should use the new implementation with the given directions. This change was in the OpenMesh 4.0 changelog.
To not break existing code, we still have the old one in place. But it has some problems such as visiting entities twice when using the decrement operator.
If you use the ones with the direction specified, you are safe and get slightly better performance.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/15Create a more usefull example for the mesh decimater2017-06-30T14:05:35ZJan Möbiusmoebius@cs.rwth-aachen.deCreate a more usefull example for the mesh decimaterThe current doc only contains how to setup the decimation order without any constraint on the quality. We should extend the example with a module controlling the decimation quality.The current doc only contains how to setup the decimation order without any constraint on the quality. We should extend the example with a module controlling the decimation quality.Daniel GotzenDaniel Gotzenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/33Triangulation via Ear Clipping2017-06-30T14:05:35ZMax Lyonlyon@cs.rwth-aachen.deTriangulation via Ear ClippingCurrently `PolyConnectivity` only implements a naive triangulation by creating a triangle fan. These kind of triangulations can cause bad, overlapping triangle configurations. Therefore, a triangulation method is needed that can reliably...Currently `PolyConnectivity` only implements a naive triangulation by creating a triangle fan. These kind of triangulations can cause bad, overlapping triangle configurations. Therefore, a triangulation method is needed that can reliably produce triangulations without overlaps, eg. via ear clipping.Daniel GotzenDaniel Gotzen2016-10-07