OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/groups/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/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-python/-/issues/23Integrate OpenMesh 8.1 SmartHandles properly.2020-06-29T10:19:19ZIsaak LimIntegrate OpenMesh 8.1 SmartHandles properly.This requires some rework of the python bindings to properly integrate the new SmartHandles introduced in OpenMesh 8.1.This requires some rework of the python bindings to properly integrate the new SmartHandles introduced in OpenMesh 8.1.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-python/-/issues/21Host full documentation online2018-06-11T15:23:10ZMartin HeistermannHost full documentation onlineI can't find an online version of the documentation, except for a download from the not easily discoverable CI artifacts. Maybe on openmesh.org or readthedocs.org?I can't find an online version of the documentation, except for a download from the not easily discoverable CI artifacts. Maybe on openmesh.org or readthedocs.org?https://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-python/-/issues/19saving custom properties2018-05-24T11:23:15ZJanis Bornsaving custom propertiesAccording to [this question on StackOverflow](https://stackoverflow.com/questions/50413319/how-to-save-custom-vertex-properties-with-openmesh-in-python), it's currently not possible to save custom properties.
Is that something we would ...According to [this question on StackOverflow](https://stackoverflow.com/questions/50413319/how-to-save-custom-vertex-properties-with-openmesh-in-python), it's currently not possible to save custom properties.
Is that something we would want to support? Would this cause any issues with array-based properties?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-python/-/issues/18set_points method (etc.)2018-04-06T11:56:54ZJanis Bornset_points method (etc.)Maybe we should have `m.set_points(p)` as an alias for `m.points()[:] = p` since the latter is not discoverable.
We would probably also need corresponding methods for normals, uvs, etc., then.Maybe we should have `m.set_points(p)` as an alias for `m.points()[:] = p` since the latter is not discoverable.
We would probably also need corresponding methods for normals, uvs, etc., then.Alexander DielenAlexander Dielenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/openmesh-python/-/issues/16convenience features for set_*_property_array methods2018-05-09T07:20:26ZJanis Bornconvenience features for set_*_property_array methodsYou need to call `set_*_property_array` in order to initialize a property as a 'numpy property', e.g.:
```python
m.set_vertex_property_array('test', np.zeros(m.n_vertices(), 3))
```
Constructing the second argument can be a bit tedious ...You need to call `set_*_property_array` in order to initialize a property as a 'numpy property', e.g.:
```python
m.set_vertex_property_array('test', np.zeros(m.n_vertices(), 3))
```
Constructing the second argument can be a bit tedious and I'd like to simplify it by broadening the interface of the `set_*_property_array` methods a bit, allowing the following calls:
```python
# the old interface: explicitly setting all values at once;
# data.shape[0] must be equal to the number of elements
m.set_vertex_property_array('test', data)
# setting the same value for each element, e.g. the vector [1,2,3]
m.set_vertex_property_array('test', element_value=[1,2,3])
# setting the same value for each element with a specific shape
# e.g. a 3x3 matrix filled with 4's
# (4 is broadcasted to the 3x3 shape to fill the matrix)
m.set_vertex_property_array('test', element_shape=(3,3), element_value=4)
# creating an uninitialized data array with a specific shape for each element:
m.set_vertex_property_array('test', element_shape=(3,3))
# creating an uninitialized data array with space for a scalar value for each element:
# (common use case)
m.set_vertex_property_array('test')
```
You can try out this interface by applying the following monkeypatch snippet:
```python
orig_set_vertex_property_array = om.TriMesh.set_vertex_property_array
def svpa(self, prop_name, array=None, element_shape=None, element_value=None):
if element_shape is None:
if element_value is None:
element_shape = ()
else:
element_shape = np.shape(element_value)
if array is None:
if element_value is None:
orig_set_vertex_property_array(self, prop_name, np.empty((self.n_vertices(), *element_shape)))
else:
orig_set_vertex_property_array(self, prop_name, np.array(np.broadcast_to(element_value, (self.n_vertices(), *element_shape))))
else:
assert element_value is None, 'both array and element_value are set'
orig_set_vertex_property_array(self, prop_name, np.reshape(array, (self.n_vertices(), *element_shape)))
om.TriMesh.set_vertex_property_array = svpa
```
I'm currently not sure whether it's better to implement this on the C++ or Python side. Python code likely makes it easier to use numpy features like `broadcast_to` and `reshape` but I don't know how to deduplicate the code for the different mesh types and mesh elements.Alexander DielenAlexander Dielenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/openmesh-python/-/issues/13complete and check existing documentation2018-06-11T15:23:04ZIsaak Limcomplete and check existing documentationAlexander DielenAlexander Dielenhttps://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/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/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-07https://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/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.