- OpenMesh - lists.rwth-aachen.de

openmesh-python: OpenMesh submodule version
by Philipp Auersperg-Castell 18 Aug '21

18 Aug '21

Hi OpenMeshers, currently the OpenMesh submodule is at db8c0608830ae7324b2b2e1d91e4db565b2d3eae dated from Apr 23. I wanted to bump to OpenMesh master, but there are serveral incompatibilities in the build. as the git log tells, there are serveral changes to Openmesh, so it would be fine to have the new version bundled. So I wanted to ask if there are plans to bump to a newer OpenMesh version? Best regards in advance Philipp

2 1

Ignore shared objects
by Robert Niederreiter 24 Jun '21

24 Jun '21

Hi, Attached you find a patch for ignoring shared objects in openmesh-python. I added this to avoid unneccesary terminal overhead with git submodules. Is it possible to apply this patch upstream? BTW - what's the preferred way you want to receive possible patches/contributions? Thanks - Robert

1 0

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