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…>
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.
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/nicholasyuehttps://vimeo.com/channels/naiadtools
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
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
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
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
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
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
