- OpenMesh - lists.rwth-aachen.de

Exposing subdivision tools via openmesh-python
by Robert Niederreiter 23 Jun '21

23 Jun '21

Hi, are there any plans to expose subdivision API (https://www.graphics.rwth-aachen.de/media/openmesh_static/Documentations/Op…) in openmesh-python? Thanks -Robert

3 4

Read texcoord and texnumber in PLY files
by Gregoire Grzeczkowicz 11 Jun '21

11 Jun '21

Hello, For my research, I need to open with OpenMesh PLY files generated by MeshLab whose faces contain a texture index (texnumber) and texture coordinates (texcoord). So I implemented these features for both ascii PLY and binary PLY. You will find in attachment the patch that corresponds to these modifications. Best regards, GRÉGOIRE GRZECZKOWICZ Doctorant en modélisation 3D de milieux urbain Laboratoire en Sciences et Technologies de l'Information Géographique (LASTIG<https://www.umr-lastig.fr>) Acquisition et Traitment de données Image/Lidar/Radar (ACTE<https://www.umr-lastig.fr/acte>) DIRECTION DES SCIENCES ET TECHNOLOGIES DE L'INFORMATION ECOLE NATIONALE DES SCIENCES GÉOGRAPHIQUES 73, AVENUE DE PARIS, 94165 ST MANDE CEDEX 01.43.98.70.72. - ign.fr<https://ign.fr/> - geoportail.gouv.fr<https://www.geoportail.gouv.fr/> [République Française / IGN]

1 0

inf values in texture coordinates when writing obj file
by Vladimir Privalov 05 Mar '21

05 Mar '21

Hi. I have problem with UV texture coordinates of vertices stored in obj file after writing mesh to obj file. I set UV coordinates for a vertex using method set_texcoord2D(). When explore the resultant obj file I see some inf values in 'vt' lines of the file. The UV values I set from code have no inf values. What could be the problem? Thanks, Vladimir Privalov

2 1

Feature Request: Make export precision a mesh trait
by Alexander Schier 11 Feb '21

11 Feb '21

Hello, I have a feature request. The write_mesh method has a precision parameter, that is by default 6, which controls how many decimal places of vertex coordinates are written when exporting the mesh. When using double precision coordinates, 6 decimal places is little. In fact, I had several times algorithms that did not converge when float was used in the export function (I think it was fixed in 8.1) and now require to set the precision to a larger value when exporting the mesh. It would be good to add the precision to the mesh traits classes and increase it in the DefaultTraitsDouble class. One note on the new DefaultTraitsDouble class, but probably hard to change now that people are using it: Why does it use Vec4f Color, making it incompatible with the DefaultTraits class that uses Vec4uc Color? It would be really nice to have a DefaultTraitsDouble class included that is identical to the DefaultTraits class except for the precision of the floating-point vectors. with kind regards, Alexander Schier

1 0

Issue with saving texture coordinates in obj file
by Vladimir Privalov 09 Feb '21

09 Feb '21

Hi. I have a problem with saving texture coordinates in obj file. I am using Python version of OpenMesh for manipulating with texture coordinates in 3D mesh stored in obj file. I save the result mesh using method write_mesh. When I open the resultant obj file there is no texture coordinates information, only list of vertices and faces. The same happens if I read the mesh from obj file. What could be the problem? Thanks. Kind regards, Vladimir Privalov

1 1

IO::write - concurrent writing
by btyukodi＠brandeis.edu 01 Feb '21

01 Feb '21

Dear OpenMesh Devs, It appears now to me that there is a problem when using IO::write concurrently, from different threads even though these write operations should be independent as they operate on separate meshes and separate streams. When I move the writing operations outside my parallel section, it works fine. When inside the parallel section, I'm getting the double free error quite randomly so I assume that whenever writing is attempted at the same time from multiple threads, it fails. Any idea about why this is happening or any fix would be greatly appreciated. Thank you, Botond

3 4

IO::write in parallel
by btyukodi＠brandeis.edu 26 Jan '21

26 Jan '21

Hi All, I have a code which uses OpenMP to run in parallel, using multiple mesh instances. From time to time, I'm dumping those instances into separate binary .om files, using separate ostream objects with the function bool OpenMesh::IO::write_mesh ( const Mesh & _mesh, std::ostream & _os, const std::string & _ext, Options _opt = Options::Default, std::streamsize _precision = 6 ) Unfortunately, the execution seem to randomly fail with the error "double free or corruption (fasttop)". This is a backtrace: ======= Backtrace: ========= /lib64/libc.so.6(+0x81489)[0x2b63bd384489] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_Z5omlogv+0x558)[0x2b63bc128488] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_12write_binaryERSoRNS0_12BaseExporterENS0_7OptionsE+0x49)[0x2b63bc10aaf9] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_5writeERSoRNS0_12BaseExporterENS0_7OptionsEl+0xe7)[0x2b63bc10aa67] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZN8OpenMesh2IO11_IOManager_5writeERSoRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_12BaseExporterENS0_7OptionsEl+0xd9)[0x2b63bc0adea9] ./Assembly(_Z7dump_omN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEElRSo+0x11c)[0x44e33c] ./Assembly(_Z9propagateRN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEEll13RunParametersRSoS5_R14UmbrellaWindowRSt23mersenne_twister_engineImLm32ELm624ELm397ELm31ELm2567483615ELm11ELm4294967295ELm7ELm2636928640ELm15ELm4022730752ELm18ELm1812433253EE+0x36e)[0x4f89ee] ./Assembly(_Z31run_umbrella_parallel_temperingNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x7c4)[0x4f3b84] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(__kmp_invoke_microtask+0x93)[0x2b63bc556563] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa93ea)[0x2b63bc51e3ea] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa8aab)[0x2b63bc51daab] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xe19c0)[0x2b63bc5569c0] /lib64/libpthread.so.0(+0x7dd5)[0x2b63bc854dd5] /lib64/libc.so.6(clone+0x6d)[0x2b63bd400ead] As you can see, it traces back to OMWriter and indeed, the error seems to come up upon writing. I was therefore wondering if there is anything that prevents such parallel writing (to separate, binary files, via separate ostream objects) or this is expected to work properly? Thanks a lot for your help, Botond

1 0

IO::write in parallel
by btyukodi＠brandeis.edu 26 Jan '21

26 Jan '21

Hi All, I have a code which uses OpenMP to run in parallel, using multiple mesh instances. From time to time, I'm dumping those instances into separate binary .om files, using separate ostream objects with the function bool OpenMesh::IO::write_mesh ( const Mesh & _mesh, std::ostream & _os, const std::string & _ext, Options _opt = Options::Default, std::streamsize _precision = 6 ) Unfortunately, the execution seem to randomly fail with the error "double free or corruption (fasttop)". This is a backtrace: ======= Backtrace: ========= /lib64/libc.so.6(+0x81489)[0x2b63bd384489] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_Z5omlogv+0x558)[0x2b63bc128488] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_12write_binaryERSoRNS0_12BaseExporterENS0_7OptionsE+0x49)[0x2b63bc10aaf9] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_5writeERSoRNS0_12BaseExporterENS0_7OptionsEl+0xe7)[0x2b63bc10aa67] /home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZN8OpenMesh2IO11_IOManager_5writeERSoRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_12BaseExporterENS0_7OptionsEl+0xd9)[0x2b63bc0adea9] ./Assembly(_Z7dump_omN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEElRSo+0x11c)[0x44e33c] ./Assembly(_Z9propagateRN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEEll13RunParametersRSoS5_R14UmbrellaWindowRSt23mersenne_twister_engineImLm32ELm624ELm397ELm31ELm2567483615ELm11ELm4294967295ELm7ELm2636928640ELm15ELm4022730752ELm18ELm1812433253EE+0x36e)[0x4f89ee] ./Assembly(_Z31run_umbrella_parallel_temperingNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x7c4)[0x4f3b84] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(__kmp_invoke_microtask+0x93)[0x2b63bc556563] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa93ea)[0x2b63bc51e3ea] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa8aab)[0x2b63bc51daab] /opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xe19c0)[0x2b63bc5569c0] /lib64/libpthread.so.0(+0x7dd5)[0x2b63bc854dd5] /lib64/libc.so.6(clone+0x6d)[0x2b63bd400ead] As you can see, it traces back to OMWriter and indeed, the error seems to come up upon writing. I was therefore wondering if there is anything that prevents such parallel writing (to separate, binary files, via separate ostream objects) or this is expected to work properly? Thanks a lot for your help, Botond

1 0

Re: Reporting issues not possible
by Fabian Kessler 25 Jan '21

25 Jan '21

Dear OpenMesh Devs, currently it is impossible to report bugs or feature requests, since this only works for registered users on your private gitlab server. It would be nice, if you migrate to the global git-server of the RWTH (https://git.rwth-aachen.de). Then nearly every student and every GitHub user could participate. For the latest release I have an issue, which is only partially fixed in the current master: The hole cmake-project has some if-branches which are only triggered, when the project is build as external-project. Those depend on a the same check: ``` # Disable package building when built as an external library if(${CMAKE_PROJECT_NAME} MATCHES "OpenMesh") ``` This only worked, because you don't set the project when OpenMesh is build as subproject. But this had the issue, that OpenMesh is not compileable when the parent project did not defined to use `C` as language. In version 9.0.0~dev you decided to define the project every time which sticks to the conventions. Good so far! But the LANGUAGE parameter is still not set there. And the project is not buildable anymore as subproject. To solve this I propose to add `CXX C` to the LANGUAGE parameter of the project command. Also all checks to the ` CMAKE_PROJECT_NAME ` variable should be replaced by a cache-variable `OPENMESH_BUILD_STANDALONE`, which is defined before the project command. Generally all CMake files are outdated and should be overhauled to use newer conventions: - [ ] use more CMake targets - [ ] export targets correctly (should be exported to the same namespace as they are installed) - [ ] update CMake version to e.g. 3.15 - [ ] ... King regards, Fabian Keßler -- Fabian Keßler | Studentischer Beschäftigter Optomet GmbH | Pfungstädter Straße 92 | 64297 Darmstadt | Deutschland Fax: +49 6151 3688460 | https://www.optomet.com/de<https://www.optomet.com/de/>

2 1

cmake CMakeLists.txt Qt 5.15.1
by Thomas Diebels 12 Jan '21

12 Jan '21

usr/include/qt5/QtCore/qstring.h:2135:18: error: no declaration matches ‘qsizetype QStringView::count(QChar, Qt::CaseSensitivity) const’ 2135 | inline qsizetype QStringView::count(QChar c, Qt::CaseSensitivity cs) const noexcept | ^~~~~~~~~~~ Mfg th.diebels

1 0