- OpenMesh - lists.rwth-aachen.de

Question Regarding Access to GitLab Repositories
by 황수일 30 Jul '25

30 Jul '25

Dear Computer Graphics Group at RWTH Aachen University, I hope this message finds you well. I am writing because I am unable to clone the OpenMesh repository (and other related projects such as OpenVolumeMesh and CoMISo) from the VCI GitLab instance. When I run: git clone --recursive https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/ OpenMesh.git I receive the following error: fatal: unable to access 'https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/ OpenMesh.git/': Failed to connect to gitlab.vci.rwth-aachen.de port 9000 after 21100 ms: Couldn't connect to server Additionally, I am unable to access the GitLab web pages such as https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh. The connection times out when trying to reach these URLs. Could you please advise on: 1. Whether there are any access restrictions or if the GitLab server is currently experiencing issues? 2. If registration or special permissions are required to access these repositories? Thank you for your time and assistance. Best regards, Suil Hwang

1 0

HoleFiller Missing from OpenMesh Tools include folder
by Jan-Michael Tressler 27 Jul '25

27 Jul '25

Hi, I wanted to test out the new HoleFiller class. Unfortunately, it appears to be missing from the cmake list? Is it possible to update OpenMesh to add it? I tried creating a bug, but I couldn't log into GitLab. Much appreciated. Jan-Michael PS OpenMesh is great!

1 0

Fix for ClangCL 19.1.5 in Timer.cc
by conrad.poelman+rwthaachende＠gmail.com 25 Mar '25

25 Mar '25

Hi, thanks for building OpenMesh! I just built OpenMesh using ClangCL 19.1.5 on Windows and only encountered one problem. The symptom was strange - deep inside Microsoft header file <Unknwnbase.h>, it complained about core Windows API functions QueryInterface and QueryService not being resolvable, as _GUID was forward declared but not defined. The problem is Timer.cc #includes several system headers from within the OpenMesh::Utils namespace, which generally a discouraged practice and likely just an oversight. The fix is to open and close the namespace in each #if branch, so the #include statements occur at file scope, outside of any namespace. I'm on a slightly older version of OpenMesh but if the following patch doesn't apply cleanly, the general point should be clear. Thanks again for maintaining OpenMesh! -- Conrad diff --git "a/src/OpenMesh/Tools/Utils/Timer.cc" "b/src/OpenMesh/Tools/Utils/Timer.cc" index e3fca04b..715bc856 100644 --- "a/src/OpenMesh/Tools/Utils/Timer.cc" +++ "b/src/OpenMesh/Tools/Utils/Timer.cc" @@ -80,14 +80,19 @@ public: virtual double seconds(void) const = 0; }; + +} // END_NS_UTILS +} // END_NS_OPENMESH + // compiler and os dependent implementation // ------------------------------------------------------------- windows 32 ---- #if defined(WIN32) && (defined(_MSC_VER) || defined(__INTEL_COMPILER) || defined (__MINGW32__) ) -#ifndef DOXY_IGNORE_THIS #include <windows.h> -#endif + +namespace OpenMesh { +namespace Utils { class TimerImplWin32 : public TimerImpl { @@ -146,12 +151,16 @@ double TimerImplWin32::seconds(void) const return (double)count_.QuadPart/(double)freq_.QuadPart; } +} // END_NS_UTILS +} // END_NS_OPENMESH + // ------------------------------------------------------------- posix time ---- #elif defined(__GNUC__) && defined(__POSIX__) -#ifndef DOXY_IGNORE_THIS # include <time.h> -#endif + +namespace OpenMesh { +namespace Utils { template <clockid_t N> class TimerImplPosix : public TimerImpl @@ -184,6 +193,9 @@ protected: timespec start_; }; +} // END_NS_UTILS +} // END_NS_OPENMESH + // ----------------------------------------------------------- gettimeofday ---- #elif (defined(__GNUC__) && !defined(__FreeBSD__) || (defined(__INTEL_COMPILER) && !defined(WIN32))) && !defined(__MINGW32__) @@ -191,6 +203,9 @@ protected: # include <sys/resource.h> # include <unistd.h> +namespace OpenMesh { +namespace Utils { + class TimerImplGToD: public TimerImpl { public: @@ -223,11 +238,16 @@ private: double seconds_; }; +} // END_NS_UTILS +} // END_NS_OPENMESH #else // ---------------------------------------- standard implementation ---- #include <time.h> +namespace OpenMesh { +namespace Utils { + static const unsigned long clockticks = CLOCKS_PER_SEC; class TimerImplStd : public TimerImpl @@ -254,10 +274,16 @@ void TimerImplStd::stop(void) count_ += stop_-start_; } +} // END_NS_UTILS +} // END_NS_OPENMESH + #endif // ----------------------------------------------------------------- Timer ---- +namespace OpenMesh { +namespace Utils { + Timer::Timer(void) : state_(Stopped) { @@ -433,7 +459,6 @@ std::string Timer::as_string(double seconds, Timer::Format format) return string; } -// ============================================================================ } // END_NS_UTILS } // END_NS_OPENMESH // ----------------------------------------------------------------------------

1 0

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