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]
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
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
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
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
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
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
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/>
Hi All,
I have implemented a simulation as an OpenMesh app. In general, I have calculations on n separate meshes and occasionally a joint calculation which affects all of the meshes. I was trying to parallelize the simulation via OpenMP, assigning a separate core to each of the meshes. For testing, I am running in a regime where there are no joint calculations so all the calculations should be completely independent. Yet, none of my CPUs run at 100%, they are at around 80%. When I run it on a single core, it's constantly near 100%.
I was wondering whether there are any global shared variables which prevent such parallelization or what needs to be modified in the cmake file. Currently, I do
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -fopenmp")
and it seems to compile and use the defined number of cores. Is there anything else to be done? Note that I do not want to parallelize OpenMesh itself, I just want to parallelize my own little app, a single for loop.
Thank you,
Botond
