- OpenMesh - lists.rwth-aachen.de

Build failure on armhf, armel
by Dima Kogan 13 May '24

13 May '24

Hi. I'm the openmesh Debian maintainer. The was a build failure building openmesh for 32-bit arm architectures: https://buildd.debian.org/status/fetch.php?pkg=openmesh&arch=armel&ver=9.0-… https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067954 I just patched the sources to fix this problem: https://salsa.debian.org/science-team/openmesh/-/blob/master/debian/patches… It would be great if you merge this patch into your tree. Thanks!

1 0

Non const qualified mesh type in getProperty
by bastian.abt＠dlr.de 30 Apr '24

30 Apr '24

Hello, The function getProperty<https://www.graphics.rwth-aachen.de/media/openmesh_static/Documentations/Op…>() throws an exception if no property with the name exist. As such, it could be const qualified like the old property()<https://www.graphics.rwth-aachen.de/media/openmesh_static/Documentations/Op…> function. So far I had only limited time to look into this, but as get_property_handle<https://www.graphics.rwth-aachen.de/media/openmesh_static/Documentations/Op…> is const qualified, perhaps this only requires a new PropertyManager constructor similar this? ``` PropertyManager(const PolyConnectivity& mesh, const char *propname) : mesh_(mesh), retain_(true), name_(propname) { if (!mesh_.get_property_handle(prop_, propname)) { throw std::runtime_error("Property Handle does not exist") } } ``` Kind regards Bastian Abt

1 0

Non-monotonic/broken OM_VERSION
by Simon Flöry 16 Feb '24

16 Feb '24

Dear OpenMesh maintainers, Changing OM_VERSION to 0xA000 for 10.0.0 broke the OM_GET_VER / OM_GET_MAJ macros and monotonicity of OM_VERSION in general. I assume 0xA0000 was the intended value. Any chance to get this fixed for 11.0, which has 0x0B000 instead of 0x0B0000 in current git? thanks, Simon

1 1

Hole filling in OpenMesh?
by Clifford Yapp 25 Jan '24

25 Jan '24

Hi - I had a general question about OpenMesh's scope for geometry processing algorithms. I noticed that OpenFlipper's plugins have a Hole Filling capability using the Liepa algorithm, but as far as I can determine this algorithm isn't available in OpenMesh - I'm only able to locate the subdivision, decimation, smoothing, etc. in Tools. It would be convenient for us to be able to use the Liepa algorithm programmatically via OpenMesh without needing to also incorporate OpenFlipper, and a naive look at the code makes me think it might be possible to take the core hole filling aspects of the algorithm and incorporate them into OpenMesh as another Tools option. Is that something that the upstream OpenMesh project would consider doing, or would such an expansion be considered out of scope? Cheers, CY

1 0

[bug] UVs serialization broken (superfluous edges) when using .obj
by mandasartur＠gmail.com 15 Dec '23

15 Dec '23

Hi, As the title suggests. Tried with ready builds for 10.0 as well as compiled 11.0. I do not have access to GitLab, otherwise I would have posted there. The situation occurs both for quad (which are auto triangulated since I am using TriMesh) and tri meshes, for mesh of any kind of complexity, when using .obj as input (for instance monkey Suzanne from Blender), and when parametrized with OpenMesh::IO::Options::VertexTexCoord. Thank you in advance

1 0

Unable to set OpenMesh::Vec3f Color trait using OM 10.0
by mandasartur＠gmail.com 14 Dec '23

14 Dec '23

Hi, I want to parametrize my mesh with custom traits. I have added typedef OpenMesh::Vec4f Color trait and it works fine - I am able to set colors, read and write them, using .ply file format. The problem is my target is .obj which does not support alpha channel for vertex colors. When I try to add OpenMesh::Vec3f Color to my traits I get the following error during compilation: Severity Code Description Project File Line Suppression State Error C2027 use of undefined type 'OpenMesh::GenProg::AssertCompile<false>' nodeller I:\nodeller\Libraries\OpenMesh\include\OpenMesh\Core\Utils\vector_cast.hh 83 It seems to me I need to implement it myself, or is there a workaround? Thank you in advance

1 0

How use mesh.set_color with iterators and not smart handles?
by mandasartur＠gmail.com 13 Dec '23

13 Dec '23

Hi, Like in the subject of the thread. Also, how can I get a handle on the current vertex when using iterators, so that I can use set_color() with that? Thank you in advance

1 1

OpenMesh with OpenMP
by LuWang (Jack) 13 Dec '23

13 Dec '23

Hello Madam or Sir, I am the user of OpenMesh, and I want ask some questions about the parallel code with OpenMesh, exactly, the parallel code is based on OpenMP on the VS2013. The first question: When I use the OpenMP on the VS2013 to speed up the program which write with OpenMesh, for example, I add the code: #pragma omp parallel for num_threads(7) , just like the following: and the errors follow, and I do not know why. and the second question: Could the code with iterator of OpenMesh be paralleled by OpenMP just like " for (TriMesh::FaceIter f_it = mesh.faces_begin(); f_it != mesh.faces_end(); f_it++) " in the above picture? or How can I parallel the code with iterator of OpenMesh? Thank you for your time! And I am looking forward to your reply. Sincerely LuWang

3 2

[OpenFlipper] Building only the backend part of OpenFlipper
by mandasartur＠gmail.com 11 Dec '23

11 Dec '23

Hi, First of all, thank you for making this great software (both OM and OF) free. My question is OF related, since I cannot joing OF mailing list. Can I build and use the backend only (math helpers + algorithms) or extract them to avoid including the Qt and ACG parts in my project? A more important question is: does the license allow that at all? Best regards

1 0

Is there a way to test whether adding a new face would result in
by btyukodi＠brandeis.edu 26 Oct '23

26 Oct '23

The function add_face uses 3 ordered VertexHandle to add a face to the mesh. If the order of vertices is incompatible with the existing mesh (so that the face would be wrongly oriented) or a triangle already exists with those 3 vertices, this is the typical warning OpenMesh gives: PolyMeshT::add_face: complex edge I was wondering if it is possible to test whether a face addition would result in such complex edge warning and skip the addition if it would? I'm thinking some kind of try-catch block. Alternatively, how can I remove the face that caused such an incompatibility? Note that here my aim is not to properly orient the new face. I simply do not want to add it if it causes incompatibilities. Thank you and all the best, Botond

3 2