I have a 3D mesh which represents a surface with some rough boundaries which I would like to smooth:
I am using a half edge data structure for storing the geometry so I can easily iterate over the boundary edges, vertices and faces. I can also quite easily determine whether a given pair of edges is a convex/concave using a dot and cross product.
What would be the best approach for smoothing the edges out, so they form a continuous, curvy line, rather then the sharp pattern seen in the pictures?
compute angle between two neighboring faces
I call it ada as abs delta angle. If it is bigger then threshold it means this point is edge. You can compute it as max of all angles between all edge lines. In 2D it looks like this:
in 3D mesh there is more then 2 lines per point so you have to check all combinations and select the biggest one
ada=max(abs(acos(n(i).n(j)))
where n(i),n(j) are normal vectors of neighboring faces where i != j
identify problematic zones
so find points where ada > threshold and create a list of these points
filter this list
if this point is too far from any other (distance>threshold) then remove it from list to preserve geometric shape
smooth points
you have to tweak this step to match your needs I would do this:
find a group of points in the list which are close together and apply some averaging geometric or numeric on them for example:
pnt(i)=0.5*pnt(i)+0.25*pnt(i-1)+0.25*pnt(i+1)
this can be applied repetitive
blue and red dots are original points, green dots are smoothed points
Related
I'm trying to write an algorithm for cutting tessellated mesh with the given plane (plane defined with the point on the plane and unit normal vector). Also, this algorithm should triangulate all polygons and fill the hole after split.
I faced with a problem to find a polygon that lies on the plane (like the orange plane on the image)
I tried to process all edges of all triangles and find those that lies on the plane and stored them in an array. After that, I formed an array of vertices by searching next suitable edge.
Can someone explain an easier and faster way to find this polygon?
All vertices must be stored in CCW order.
Identify all edges that you cut by the indexes (or labels) of the endpoints. Make sure that every edge belongs to exactly two faces and is cut twice. Also make sure to orient the edge that results from the intersection consistently with the direction of the face normal.
Now the intersection edges form a chain that you can reconstruct by sorting: store the indexes of the endpoints separately, each with a link to the originating edge. After sorting on the indexes, the common vertices will appear in pairs in the sorted array. Using this structure, you can trace the polygon(s).
In the example below, from the faces aebf, bcgf, cdgh and dhea, you generate the edges ae-dh, bf-ae, cg-bf and dh-cg in some order. After splitting the endpoints and sorting, ae-, -ae, dh-, -dh, cg-, -cg, bf-, -bf, which generate the cycle ae-dh, dh-cg, cg-bf, bf-ae.
Good day.
I have the task of finding the set of points in 2D space for which the sum of the distances to the rectangles is minimal. For example, for two rectangles, the result will be the next area (picture). Any point in this area has the minimum sum of lengths to A and B rectangles.
Which algorithm is suitable for finding a region, all points of which have the minimum sum of lengths? The number of rectangles can be different, they are randomly located. They can even overlap each other. The sides of the rectangles are parallel to the coordinate axes and cannot be rotated. The region must be either a rectangle or a line or a point.
Hint:
The distance map of a rectangle (function that maps any point (x,y) to the closest distance to the rectangle) is made of four slanted planes (slope 45°), four quarter of cones and the rectangle itself, which is at ground level, forming a continuous surface.
To obtain the global distance map, it "suffices" to sum the distance maps of the individual rectangles. A pretty complex surface will result. Depending on the geometries, the minimum might be achieved on a single vertex, a whole edge or a whole face.
The construction of the global map seems more difficult than that of a line arrangement, due to the conic patches. A very difficult problem in the general case, though the axis-aligned constraint might ease it.
Add on Yves's answer.
As Yves described, each rectangle 'divide' plane into 9 parts and adds different distance method in to the sum. Middle part (rectangle) add distance 0, side parts add coordinate distance to that side, corner parts add point distance to that corner. With that approach plan has to be divided into 9^n parts, and distance sum is calculated by adding appropriate rectangle distance functions. That is feasible if number of rectangles is not too large.
Probably it is not needed to calculate all parts since it is easy to calculate some bound on part min value and check is it needed to calculate part at all.
I am not sure, but it seems to me that global distance map is convex function. If that is the case than it can be solved iteratively by similar idea as in linear programming.
I have a set of point cloud, and I would like to test if there is a corner in a 3D room. So I would like to discuss my approach and if there is a better approach or not in terms of speed, because I want to test it on mobile phones.
I will try to use hough tranform to detect lines, then I will try to see if there are three lines that are intersecting and they make a two plane that are intersecting too.
If the point cloud data comes from a depth sensor, then you have a relatively dense sampling of your walls. One thing I found that works well with depth sensors (e.g. Kinect or DepthSense) is a robust version of the RANSAC procedure that #MartinBeckett suggested.
Instead of picking 3 points at random, pick one point at random, and get the neighboring points in the cloud. There are two ways to do that:
The proper way: use a 3D nearest neighbor query data structure, like a KD-tree, to get all the points within some small distance from your query point.
The sloppy but faster way: use the pixel grid neighborhood of your randomly selected pixel. This may include points that are far from it in 3D, because they are on a different plane/object, but that's OK, since this pixel will not get much support from the data.
The next step is to generate a plane equation from that group of 3D points. You can use PCA on their 3D coordinates to get the two most significant eigenvectors, which define the plane surface (the last eigenvector should be the normal).
From there, the RANSAC algorithm proceeds as usual: check how many other points in the data are close to that plane, and find the plane(s) with maximal support. I found it better to find the largest support plane, remove the supporting 3D points, and run the algorithm again to find other 'smaller' planes. This way you may be able to get all the walls in your room.
EDIT:
To clarify the above: the support of a hypothesized plane is the set of all 3D points whose distance from that plane is at most some threshold (e.g. 10 cm, should depend on the depth sensor's measurement error model).
After each run of the RANSAC algorithm, the plane that had the largest support is chosen. All the points supporting that plane may be used to refine the plane equation (this is more robust than just using the neighboring points) by performing PCA/linear regression on the support set.
In order to proceed and find other planes, the support of the previous iteration should be removed from the 3D point set, so that remaining points lie on other planes. This may be repeated as long as there are enough points and best plane fit error is not too large.
In your case (looking for a corner), you need at least 3 perpendicular planes. If you find two planes with large support which are roughly parallel, then they may be the floor and some counter, or two parallel walls. Either the room has no visible corner, or you need to keep looking for a perpendicular plane with smaller support.
Normal approach would be ransac
Pick 3 points at random.
Make a plane.
Check if each other point lies on the plane.
If enough are on the plane - recalculate a best plane from all these points and remove them from the set
If not try another 3 points
Stop when you have enough planes, or too few points left.
Another approach if you know that the planes are near vertical or near horizontal.
pick a small vertical range
Get all the points in this range
Try and fit 2d lines
Repeat for other Z ranges
If you get a parallel set of lines in each Z slice then they are probably have a plane - recalculate the best fit plane for the points.
I would first like to point out
Even though this is an old post, I would like to present a complementary approach, similar to Hough Voting, to find all corner locations, composed of plane intersections, jointly:
Uniformly sample the space. Ensure that there is at least a distance $d$ between the points (e.g. you can even do this is CloudCompare with a 'space' subsampling)
Compute the point cloud normals at these points.
Randomly pick 3 points from this downsampled cloud.
Each oriented point (point+plane) defines a hypothetical plane. Therefore, each 3 point picked define 3 planes. Those planes, if not parallel and not intersecting at a line, always intersect at a single point.
Create a voting space to describe the corner: The intersection of the 3 planes (the point) might a valid parameterization. So our parameter space has 3 free parameters.
For each 3 points cast a vote in the accumulator space to the corner point.
Go to (2) and repeat until all sampled points are exhausted, or enough iterations are done. This way we'll be casting votes for all possible corner locations.
Take the local maxima of the accumulator space. Depending on the votes, we'll be selecting the corners from intersection of the largest planes (as they'll receive more votes) to the intersection of small planes. The largest 4 are probably the corners of the room. If not, one could also consider the other local maxima.
Note that the voting space is a quantized 3D space and the corner location will be a rough estimate of the actual one. If desired, one could store the planes intersection at that very location and refine them (with iterative optimization similar to ICP or etc) to get a very fine corner location.
This approach will be quite fast and probably very accurate, given that you could refine the location. I believe it's the best algorithm presented so far. Of course this assumes that we could compute the normals of the point clouds (we can always do that at sample locations with the help of the eigenvectors of the covariance matrix).
Please also look here, where I have put out a list of plane-fitting related questions at stackoverflow:
3D Plane fitting algorithms
Hello,
I am trying to find the grid points which are outside from my data and at least 2cm close to grid data. The grid data is shown in red col and data is shown in blue. I can find the point inside if dist(cubeGridPoint < SampleDataPoint). I am interested in finding the points which are 2 cm close to sample. Any algorithm or help will def help me.
In summary, I want to find only grid points which are at least 2 cm from sample and lying outside the sample.
the data looks not too convex to me (more concave like)
so the convex hull will create not what you want ...
I would use different approach similar to this find holes in 2D point set
create space for your grid map
3D voxel map for each 2x2x2 cm voxel
and clear it with zeroes
loop through all points of your data
compute the voxel table coordinate for it
and increment its element value in voxel map
if you have too many points that also handle increment overflow
so you will not go to zero or negative values ...
now
all voxels with zero are outside your object
or in some local hole of it
filter the anomalies
you can use dilatation/erosion for that
or count neigbour voxels with zero and if lover then treshold clear it with 1
find the boundary
handle table as set of 2D layers
in each layer process or horizontal lines
detect / replace it like this:
find -> replace
?????0000000000????? -> ?????0111111110?????
000000000000000????? -> 111111111111110?????
?????000000000000000 -> ?????011111111111111
you can do this separate in 3 directions
and combine the results together to avoid projection related holes
now all the voxels holding zero are your boundary points
[notes]
you can improve this by additional filtering like smooth or whatever
I'm asking this question out of curiosity, having first tried to implement such an algorithm before using GLU's for performance reasons.
I've looked into common algorithms (Delaunay, Ear Clipping are often mentioned), but I can't seem to understand how GLU does its job so well all the time.
Do any of you have interesting papers or articles on that subjects?
There are some notes alongside the source:
This is only a very brief overview. There is quite a bit of
additional documentation in the source code itself.
Goals of robust tesselation
The tesselation algorithm is fundamentally a 2D algorithm. We
initially project all data into a plane; our goal is to robustly
tesselate the projected data. The same topological tesselation is
then applied to the input data.
Topologically, the output should always be a tesselation. If the
input is even slightly non-planar, then some triangles will
necessarily be back-facing when viewed from some angles, but the goal
is to minimize this effect.
The algorithm needs some capability of cleaning up the input data as
well as the numerical errors in its own calculations. One way to do
this is to specify a tolerance as defined above, and clean up the
input and output during the line sweep process. At the very least,
the algorithm must handle coincident vertices, vertices incident to an
edge, and coincident edges.
Phases of the algorithm
Find the polygon normal N.
Project the vertex data onto a plane. It does not need to be perpendicular to the normal, eg. we can project onto the plane
perpendicular to the coordinate axis whose dot product with N is
largest.
Using a line-sweep algorithm, partition the plane into x-monotone regions. Any vertical line intersects an x-monotone region in at
most one interval.
Triangulate the x-monotone regions.
Group the triangles into strips and fans.
Finding the normal vector
A common way to find a polygon normal is to compute the signed area
when the polygon is projected along the three coordinate axes. We
can't do this, since contours can have zero area without being
degenerate (eg. a bowtie).
We fit a plane to the vertex data, ignoring how they are connected
into contours. Ideally this would be a least-squares fit; however for
our purpose the accuracy of the normal is not important. Instead we
find three vertices which are widely separated, and compute the normal
to the triangle they form. The vertices are chosen so that the
triangle has an area at least 1/sqrt(3) times the largest area of any
triangle formed using the input vertices.
The contours do affect the orientation of the normal; after computing
the normal, we check that the sum of the signed contour areas is
non-negative, and reverse the normal if necessary.
Projecting the vertices
We project the vertices onto a plane perpendicular to one of the three
coordinate axes. This helps numerical accuracy by removing a
transformation step between the original input data and the data
processed by the algorithm. The projection also compresses the input
data; the 2D distance between vertices after projection may be smaller
than the original 2D distance. However by choosing the coordinate
axis whose dot product with the normal is greatest, the compression
factor is at most 1/sqrt(3).
Even though the accuracy of the normal is not that important (since
we are projecting perpendicular to a coordinate axis anyway), the
robustness of the computation is important. For example, if there are many vertices which lie almost along a line, and one vertex V
which is well-separated from the line, then our normal computation
should involve V otherwise the results will be garbage.
The advantage of projecting perpendicular to the polygon normal is
that computed intersection points will be as close as possible to
their ideal locations. To get this behavior, define TRUE_PROJECT.
The Line Sweep
There are three data structures: the mesh, the event queue, and the
edge dictionary.
The mesh is a "quad-edge" data structure which records the topology of
the current decomposition; for details see the include file "mesh.h".
The event queue simply holds all vertices (both original and computed
ones), organized so that we can quickly extract the vertex with the
minimum x-coord (and among those, the one with the minimum y-coord).
The edge dictionary describes the current intersection of the sweep
line with the regions of the polygon. This is just an ordering of the
edges which intersect the sweep line, sorted by their current order of
intersection. For each pair of edges, we store some information about
the monotone region between them -- these are call "active regions"
(since they are crossed by the current sweep line).
The basic algorithm is to sweep from left to right, processing each
vertex. The processed portion of the mesh (left of the sweep line) is
a planar decomposition. As we cross each vertex, we update the mesh
and the edge dictionary, then we check any newly adjacent pairs of
edges to see if they intersect.
A vertex can have any number of edges. Vertices with many edges can
be created as vertices are merged and intersection points are
computed. For unprocessed vertices (right of the sweep line), these
edges are in no particular order around the vertex; for processed
vertices, the topological ordering should match the geometric
ordering.
The vertex processing happens in two phases: first we process are the
left-going edges (all these edges are currently in the edge
dictionary). This involves:
deleting the left-going edges from the dictionary;
relinking the mesh if necessary, so that the order of these edges around the event vertex matches the order in the dictionary;
marking any terminated regions (regions which lie between two left-going edges) as either "inside" or "outside" according to
their winding number.
When there are no left-going edges, and the event vertex is in an
"interior" region, we need to add an edge (to split the region into
monotone pieces). To do this we simply join the event vertex to the
rightmost left endpoint of the upper or lower edge of the containing
region.
Then we process the right-going edges. This involves:
inserting the edges in the edge dictionary;
computing the winding number of any newly created active regions. We can compute this incrementally using the winding of each edge
that we cross as we walk through the dictionary.
relinking the mesh if necessary, so that the order of these edges around the event vertex matches the order in the dictionary;
checking any newly adjacent edges for intersection and/or merging.
If there are no right-going edges, again we need to add one to split
the containing region into monotone pieces. In our case it is most
convenient to add an edge to the leftmost right endpoint of either
containing edge; however we may need to change this later (see the
code for details).
Invariants
These are the most important invariants maintained during the sweep.
We define a function VertLeq(v1,v2) which defines the order in which
vertices cross the sweep line, and a function EdgeLeq(e1,e2; loc)
which says whether e1 is below e2 at the sweep event location "loc".
This function is defined only at sweep event locations which lie
between the rightmost left endpoint of {e1,e2}, and the leftmost right
endpoint of {e1,e2}.
Invariants for the Edge Dictionary.
Each pair of adjacent edges e2=Succ(e1) satisfies EdgeLeq(e1,e2) at any valid location of the sweep event.
If EdgeLeq(e2,e1) as well (at any valid sweep event), then e1 and e2 share a common endpoint.
For each e in the dictionary, e->Dst has been processed but not e->Org.
Each edge e satisfies VertLeq(e->Dst,event) && VertLeq(event,e->Org) where "event" is the current sweep line
event.
No edge e has zero length.
No two edges have identical left and right endpoints. Invariants for the Mesh (the processed portion).
The portion of the mesh left of the sweep line is a planar graph, ie. there is some way to embed it in the plane.
No processed edge has zero length.
No two processed vertices have identical coordinates.
Each "inside" region is monotone, ie. can be broken into two chains of monotonically increasing vertices according to VertLeq(v1,v2)
a non-invariant: these chains may intersect (slightly) due to
numerical errors, but this does not affect the algorithm's operation.
Invariants for the Sweep.
If a vertex has any left-going edges, then these must be in the edge dictionary at the time the vertex is processed.
If an edge is marked "fixUpperEdge" (it is a temporary edge introduced by ConnectRightVertex), then it is the only right-going
edge from its associated vertex. (This says that these edges exist
only when it is necessary.)
Robustness
The key to the robustness of the algorithm is maintaining the
invariants above, especially the correct ordering of the edge
dictionary. We achieve this by:
Writing the numerical computations for maximum precision rather
than maximum speed.
Making no assumptions at all about the results of the edge
intersection calculations -- for sufficiently degenerate inputs,
the computed location is not much better than a random number.
When numerical errors violate the invariants, restore them
by making topological changes when necessary (ie. relinking
the mesh structure).
Triangulation and Grouping
We finish the line sweep before doing any triangulation. This is
because even after a monotone region is complete, there can be further
changes to its vertex data because of further vertex merging.
After triangulating all monotone regions, we want to group the
triangles into fans and strips. We do this using a greedy approach.
The triangulation itself is not optimized to reduce the number of
primitives; we just try to get a reasonable decomposition of the
computed triangulation.