- OpenMesh - lists.rwth-aachen.de

OpenMesh Beginner Questions
by Billy Zinser 18 Feb '19

18 Feb '19

Hello, I am an undergraduate student at Arizona State University and I'm trying to do research using OpenMesh. I am just starting to learn how to compile and build projects and I had a few questions I was hoping you could answer. 1.) Do I need to compile OpenMesh first using Cmake or can I start with the tutorial, "OpenMesh: How to create your own project using OpenMesh"? They both seem to be doing the same thing. 2.) When I follow the steps to build a cube and use cmake it converts the source file into a bunch of vcxproj.filters files. Is this normal? 3.) How can I actually view the output of the cube? Is it possible to open the cube in visual basic, and compile it in there? Thanks in advance, William <https://www.openmesh.org/media/Documentations/OpenMesh-Doc-Latest/a01176.ht…>

1 0

Can't contact GIT server
by Andrew Cunningham 07 Jan '19

07 Jan '19

Ir seems that it’s not possible to access the GIT repos from outside. For example, this link just “times out”. https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh.git

2 1

[PATCH] PolyConnectivity::is_collapse_ok fails
by Simon Flöry 10 Dec '18

10 Dec '18

Dear OpenMesh maintainers, We encountered a configuration where PolyConnectivity::is_collapse_ok fails to return a correct result for a triangle mesh, while TriConnectivity::is_collapse_ok does. We attach code to reproduce the problem (openmesh_bug_is_collapse_ok.cpp). See the comments in that file for more details on the bug. Moreover, we attach a patch against OpenMesh-7.1 to fix the problem (openmesh_patch_is_collapse_ok.patch). The patch basically reproduces the logic of TriConnectivity::is_collapse_ok for this special case. Not related, but did you have time to look at this issue https://lists.rwth-aachen.de/hyperkitty/list/openmesh@lists.rwth-aachen.de/… we reported some time ago? thanks, Simon -- Dr. Simon Flöry Rechenraum e.U. Stutterheimstraße 16-18/2/20a, 1150 Wien, Austria phone: +43 (0)1 789061269 mobile: +43 (0)681 81502316 skype: simon.floery Commercial Register No. FN 385715d (Handelsgericht Wien) This e-mail contains confidential information. If you are not the intended recipient, you must not disclose nor use the contents of this e-mail. In case you have received this e-mail in error, we ask you to inform us and delete this e-mail.

2 1

Getting geometry information from file read
by Nicholas Yue 27 Nov '18

27 Nov '18

Hi, After loading a file (e.g. an OBJ file) v 0 1 0 v -0.942810297 -0.333329707 0 v 0.471405149 -0.333329707 0.816497624 v 0.471405149 -0.333329707 -0.816497624 vn 1.19208849e-07 1 0 vn -0.942809761 -0.333331376 0 vn 0.47140494 -0.333331257 0.816497147 vn 0.47140494 -0.333331257 -0.816497147 vt .... vt .... vt .... I queried the properties via _vprop() size_t n_vprops = mesh.n_vprops(); for (size_t prop_index=0;prop_index<n_vprops;prop_index++) { std::cout << boost::format("prop[%1%] is %2% ") % prop_index % mesh._vprop(prop_index).name() << std::endl; } I get the following which I am trying to understand. prop[0] is v:points prop[1] is <vprop> I was expecting a string containing "n" or "normals" for prop[1] My quest is to find out the different type of attributes are found in the file I read in. In my case, the normals are "shared" i.e. number of points is same as number of normals whereas for texture coordinates, they are not shared at all i.e. each face texcoord are "island" Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools

3 2

OBJ Writer TexCoord Issue
by Jan-Michael Tressler 27 Nov '18

27 Nov '18

Hi all, I found an issue regarding the OBJ writer and saving Face TexCoords. Basically, what I'm seeing is that the OBJ writer is adding extra vt entries into the OBJ file. The file still works in Meshlab if I add the missing MTL header to the top of the OBJ file, but I'm unable to reopen the file using OpenMesh. The error I'm getting is "Only single 2D or 3D texture coordinate per vertexallowed!". From what I'm seeing, the new OBJ file has (in my case) an additonal 983 VT entries. To open the mesh, I'm doing: OpenMesh::IO::Options ropt; ropt += OpenMesh::IO::Options::FaceTexCoord; _mesh.request_vertex_normals(); _mesh.request_face_normals(); _mesh.request_halfedge_texcoords2D(); if (!OpenMesh::IO::read_mesh(_mesh, path, ropt)) { return false; } _mesh.update_normals(); To save the mesh, I'm doing: OpenMesh::IO::Options wopt; if (_mesh.has_vertex_normals()) { wopt += OpenMesh::IO::Options::VertexNormal; } if (_mesh.has_halfedge_texcoords2D()) { std::cout << "has 2d" << std::endl; wopt += OpenMesh::IO::Options::FaceTexCoord; } if (!OpenMesh::IO::write_mesh(_mesh, path, wopt)) return true; There have been no modifications to the file. Thanks for your help, Jan-Michael

2 1

Vertex split on a polygonal mesh
by Rastko Sknepnek (Staff) 26 Nov '18

26 Nov '18

Dear OpenMesh developers, I am working on a Vertex Model code. Vertex Model is one of the standard models for epithelial tissue mechanics. The tissue is modelled as a polygonal tessellation of the plane making the half-edge data structure ideal for implementing it. One of the key ingredients in modelling tissue mechanics is describing the so-called T1- transition. Briefly, for a quadruplet of cells labelled as 1,2,3 and 4, cells 1 and 2 are neighbours (share an edge). During the T1 transition, this edge shrinks and collapses to a point (a four-vertex). This vertex is then resolved (split) in the opposite direction, such that cells 3 and 4 now share an edge and cells 1 and 2 are no longer in contact. T1 can also be seen as what happens to the dual of a Delaunay triangulation when an edge is flipped due to the angle criterion being violated. If I am not mistaken, at the moment vertex split is supported only for triangular meshes. How hard would it be to implement it for a general polygonal mesh? (Unfortunately, it is not possible to work with triangular meshes as it would lead to very serious complications with force calculations.) At the moment I have my own light-weight C++11 implementation of the half-edge data structure that does this. However, using OpenMesh would be far more appealing due to its many powerful features. Many thanks, Rastko ________________________________________ Rastko Sknepnek Senior Lecturer in Physics School of Science and Engineering School of Life Sciences University of Dundee Discovery Centre, Room 2.28 Dundee DD1 5EH, UK +44 (0) 1382 385699 The University of Dundee is a registered Scottish Charity, No: SC015096

1 0

mesh subdivision
by Matthieu Deveau 20 Nov '18

20 Nov '18

Hi OpenMesh contributors! My first post here: I am trying to subdivide some face into 4 faces using the adaptive composite subdivision framework provided through OpenMesh/Tools/Subdivider/Adaptive/Composite/CompositeT.hh I am having a hard time setting the rule. I would like to use a one-to-four subdivision, and to do so, set a new rule (OpenMesh::Subdivider::Adaptive::Tvv4). Currently, I am trying the following: using openmesh = OpenMesh::TriMesh_ArrayKernelT<CompositeTraits>; OpenMesh::Subdivider::Adaptive::CompositeT<openmesh> subdivider(mesh); subdivider.cleanup(); subdivider.add<OpenMesh::Subdivider::Adaptive::Tvv4<openmesh>>(); std::cout << "subdivision type " << subdivider.subdiv_type() << std::endl; auto faceHandle = m_openMesh->face_handle(faceIdx); subdivider.refine(faceHandle); Subdivision type is 0, while I am expecting 3. Can you help on this issue please? Best regards, Matthieu

1 0

How to modify the vertices of a face
by 6528620 05 Nov '18

05 Nov '18

Regard, There have some faces in a mesh. I want to modify the vertices (vertex handle) of a face. But it may not change face handle. How to do it ? Thanks. shaozhuo 6528620(a)qq.com

1 0

Patch: PLY face color I/O support
by demlow＠gmail.com 15 Oct '18

15 Oct '18

Please find attached a patch for PLY face color support in the PLY reader and writer, including unit testing. The .ply file should be added to src/UnitTests/TestFiles. Happily, this patch is enough to enable color face support from PLYs in OpenFlipper as well. I did not bother to update PLYWriter::binary_size() since that method is already incorrect (it must be unused, or not matter). Also attached is a small patch to FindGoogleTest.cmake for Fedora/CentOS/RHEL compatibility. Steve

2 1

Patch: PLY face color I/O support
by Steve and Barb Demlow 15 Oct '18

15 Oct '18

Please find attached a patch for PLY face color support in the PLY reader and writer, including unit testing. The .ply file should be added to src/UnitTests/TestFiles. Happily, this patch is enough to enable color face support from PLYs in OpenFlipper as well. I did not bother to update PLYWriter::binary_size() since that method is already incorrect (it must be unused, or not matter). Also attached is a small patch to FindGoogleTest.cmake for Fedora, etc. compatibility. Steve

1 0