Unify normal estimation using PCL - c++

I used PCL (Point-cloud library) to triangulate a 3D point cloud. But the triangulation I got is not consistent. I get a similar situation as at question: How to unify normal orientation.
But this code does not work well, I can't compile it. I get an exception within a function call:
vcg::tri::UpdateNormal<MyMesh>::PerFace(m)
Beside,VCG has been updated to a newer edition, and the original author edited the source code, so it won't work now.

Related

C++ library for mesh to mesh intersection: what is available?

I need to calculate volume intersection and penetration depth between 3D triangular meshes (e.g. in .obj format), but I am quite new to computational geometry.
In a previous post (Mesh to mesh intersections) and from my google search, I found a few C++ libraries which might be appropriate to do the job:
CGAL
PQP
libigl
SWIFT
Though, I am not sure which one could be the most appropriate for a beginner. Any suggestion?
libigl as of version 1.1 has robust mesh boolean operations in igl/boolean/mesh_boolean.h. This uses either an implementation using CGAL's exact arithmetic kernel or a wrapper of cork (another option for you).
For now, libigl also contains a patched version of cork in libigl/external/cork, which greatly improves robustness.
While implementing libigl's boolean ops, I found that cork is faster but does not always produce the correct result (specifically, it fails to resolve all intersections).
Libigl, using CGAL as a backend, is the most robust and still fast compared to converting a mesh to CGAL's Nef_polyhedron, conducting CSG operations and converting back to a mesh. This final conversion would be possible only if the result is manifold. Instead, libigl only uses CGAL for exact triangle-triangle intersection and 2D meshing. Correct, non-manifold output is no problem.
Libigl's interface is very simple and familiar to users of Eigen. For example, to find the intersection between a solid mesh with vertices in the rows of VA and triangles indices in the rows of FA and another mesh (VB,FB) and store the output in a new mesh (VC,FC):
#include <igl/boolean/mesh_boolean.h>
...
igl::mesh_boolean(VA,FA,VB,FB,MESH_BOOLEAN_TYPE_UNION,VC,FC);
One additional possibility is to use open-source C++ library MeshLib. It can read and write meshes in Wavefront format (.obj) and robustly perform Boolean operations (intersection, union, difference) on meshes: documentation of the appropriate functions.
As far as I know, Boolean operations in MeshLib are faster than in CGAL and libigl, see video of MeshInspector application based on MeshLib.

An algorithm for inflating/deflating (offsetting, buffering) polylines

Related Question:
An algorithm for inflating/deflating (offsetting, buffering) polygons
The difference is that I'm searching for a way to inflate a given polyline into a polygon:
I've got the following input:
List of 2D Points which form the polyline (bright green in the sketch)
Width of the line
The output should be a polygon which shows how the line looks expanded by the width.
I originally thought I could use Boost::Geometry::buffer for that, unfortunately it just seems to support boxes for now. A solution using Boost::Geometry or GDAL/OGR would be preffered.
UPDATE:
I chose to use the Clipper Library and its OffsetPolyLines function. As soon as Boost Geometry is released with Polyline-Buffer support I'll switch to Boost (as everything else runs with Boost in my software).
I understand that the OP was preferring a solution in Boost::Geometry or GDAL/OGR but, in case others are following this thread, my Clipper library can also do polyline offsetting. (The soon to be released version 6 that's already in the SourceForge repository simplifies this and it now supports open path (polyline) clipping too.)
Boost.Geometry extension (from Trunk) can do this. It is not yet released. It can buffer around polygons, polygons, points, and multi-geometries. You can specify sharp corners (miter) or rounded corners. It is not yet perfect, but lines as your sample above should not give any problems.
The released version (1.54) does not have this yet, and also the next one will not have it yet. So for now you have to use the Trunk (from SVN)

Using mesh gradients in Cairo for coloring a path

I'm a newbie in this type of approach to programming since I really doesn't care for hardcore graphics generation. I design, write, run, and study parametrized climate models with python. But, at last, I have encountered myself with a visualization issue.
I was looking for something in Cairo library that allows me to map a linear gradient onto an arbitrary curve (not necessarily a circumference) such that there is a more or less smooth variation of colour (or shade) across my path. Then I have been looking for some pattern and I finally found that maybe mesh gradients in Cairo are the solution.
However, I can't create a new mesh gradient from my python script with cairo.pattern_create_mesh()!
Therefore, my questions are: How I use mesh gradients in Cairo? Is there any other simple way to do what I want with Cairo (I don't know, like a simple mapping from a line segment to a curve via parametrization, I know I ask too much)?
Mesh patterns were added in cairo 1.12 which is the latest release. Thus, most language bindings likely don't support them yet. I don't know anything about the combination of python and cairo and thus don't know any workaround.
I don't know any simple way to simulate what you need with other patterns, sorry. (Although I am not really sure how you want to do your mapping via mesh gradients either...)

Normal estimation in C++ with CGAL framework

I have been using CGAL to estimate the normals of a set of points with the CGAL::mst_orient_normals function, but it is too slow. I even tried the example in the documentation. It estimates normals in a set of points corresponding to a sphere and it takes more than 1 hour. I want to know if this is normal or if I am doing something wrong.
If you using Visual C++/Studio for compilation, make sure you running in Release mode. It is a lot faster than Debug mode for template code that is built upon STL.
Make sure you are using the simplest kernel that will estimate the normals. For example, the Exact_predicates_exact_constructions_kernel will be slower than Exact_predicates_inexact_constructions_kernel

Finding convex defects? in OpenCV 2.3, c++ with MS Visual Studio2010

I am currently attempting to use OpenCV 2.3 and c++ to detect a hand (wearing a green glove), and distinguish between different hand gestures.
At this very moment, my next step is to acquire specific features of the hand (convex defects).
So far I've used these functions in my process:
mixChannels(); //to subtract non-green channels from green.
threshold(); //to convert to binary
erode(); dialate(); //to get rid of any excess noise
findContours(); //to find contours of course
these have worked splendidly and I have been able to output findContours() through the use of drawContours().
Next step, and this is where I'm at, is using convexHull(), which also works in OpenCV 2.3. I have however yet to find out how the vector results of convexHull() actually look (what features they contains).
But this is where the tricky part comes.
I found that the older version of OpenCV (using c which uses IplImage), has a neat little function called cvConvexityDefects() which can give a set of deficiencies on the convex hull. These are what I need, but there seems to be no such function for the OpenCV 2.3 and I don't see how I can use the old syntax to get these results.
Here's a link to Open CV documentation on cvConvextDefects.
What I'm asking for, is either a similar OpenCV 2.3 function, or a selfwritten piece of code or algorithm for finding these defects. Or a method to use the old 2.1 syntax for a vector result or something like that.
(I know that I can use other features, rectangular bounding boxes, and fitted circles. But I'm sure that convex defects yield the most distinguishable features.)
Solution - I ended up using a c++ wrapper from this post
The only thing not working for this wrapper seems to be a leek of the defects vector, which should be easily solvable.
Next step is getting some usable data from these defects. (At first glance. the data seems to be single points on the convexHull or the Contour or the count of these. I had at first expected a set of two points, or a single point and a length, which it does not seem to be. If I'm hitting 'brick wall' with this, I'll make another post)
The new C++ interface does not (yet) support all the functions in C. And the opposite is true, also (not everything in cpp is in c). The reasons are various, but the good news is that you can easily use whatever function you want. By example, here you have to convert contours to sequences (CvSeq) and send them to your function.
Moreover, the FindContours method is a wrapper over cvFindContours. You can call it
cvFindContours((IplImage*)matImage, ...);
and then use directly the result.
Another way would be to create a nice, clean C++ wrapper over cvConvexDefects() and submit it to OpenCV. In the findContours source you will find some help for that (the opposite transform)
I would like to attempt to convert my convexHull vector from the c++ syntax to the sequence which you mentioned, but I don't know where to start. Could you perhaps shed some light on this?
Check out this question here, I beleive it goes into it.
Convexity defects C++ OpenCv