Thank you for providing a more detailed example. Capturing intent is always a challenge in an edge-case scenario like the one you provided. It is tempting to suggest a tolerance and while that may work for your case it may have shortcomings in other respects. Users may attempt to use large tolerances and the notion of convexity is no longer valid. The Alpha-shape may be a more appropriate construct for addressing computations like yours. This is basically a generalization of a convex hull that admits concavities. Imagine the 2D convex hull as the boundary defined by a ruler as it traverses tightly around your point set. In contrast, the 2D Alpha Shape is the boundary defined a disk of radius R rather than a ruler. By varying R you can get a family of different shapes. Conceptually, this would appear to be more appropriate, but I cannot comment on how well it would work with your data set. It is a more worthwhile enhancement to consider as opposed to adding a tolerance to convhull.

You may be able to use other computational geometry tools to solve your problem. Here’s an example I came up with based on a triangulation of the dataset. The function triangulates the data and then “peels away” the sliver triangles that (typically) lie on the boundary, revealing the interior points that lie in close proximity. This function may not work for your particular data set; for example, the distribution of points may give rise to slivers in the interior. It any case, it’s something to consider.

function k = myconvhull(x,y,rtol)
s1 = warning('off','MATLAB:delaunay:DupPtsDelaunayWarnId');
s2 = warning('off','MATLAB:TriRep:PtsNotInTriWarnId');
tri = delaunay(x(:),y(:));     % Triangulate the points
tr = TriRep(tri,x(:),y(:));   % Use a TriRep to represent the triangulation
[~, ccrad] = tr.circumcenters(); % Compute the radius of circumcenters
idx = find(ccrad > rtol);     % Remove sliver triangles (assumed to be on the boundary)
tri(idx,:) = [];
tr = TriRep(tri,x(:),y(:));   % Create a new TriRep and use it to compute
fb = tr.freeBoundary();       % the free boundary; this is an approximation
k = fb(:,1);                  % of the convex hull
k(end+1) = k(1);

Example usage

x = [double(1/3) double(1/2) double(2/3) double(1) double(1/3)]
y = [double(2/3) double(1/2) double(1/3) double(1) double(2/3)]
>> k = myconvhull(x,y,10e10)

k =

     1
     2
     3
     4
     1

Sorry for the confusion, I was not sure if convhull includes points on the hull that are not extremal, but it seems to do so from the following example:

x = [double(0) double(1) double(2) double(0) double(0)]

x =

0 1 2 0 0

>> y = [double(0) double(1) double(2) double(1) double(0)]

y =

0 1 2 1 0

k = convhull(x,y)

k =

1
2
3
4
1

The point i’m having trouble with is as follows:

x = [double(1/3) double(1/2) double(2/3) double(1) double(1/3)]

x =

0.3333 0.5000 0.6667 1.0000 0.3333

>> y = [double(2/3) double(1/2) double(1/3) double(1) double(2/3)]

y =

0.6667 0.5000 0.3333 1.0000 0.6667

k = convhull(x,y)

k =

1
3
4
1

convhulln([x',y'])

ans =

3 4
4 1
1 3

I fully expected the point (0.5,0.5) to be on the hull but both convhull and convhulln don’t include it. With inpolygon I get:

[inP onP] = inpolygon(double(1/2),double(1/2), x(k), y(k))

inP =

1

onP =

1

Of course, inpolygon and convhull might be completely different algorithms and hence the disparity, which was why I felt that if there were a tolerance parameter included in convhull it could be easier to detect points on the hull boundary that are not extremal. In my particular application, the assumption of general position of points is not valid, which is why the non-extremal points also matter in the computation.

Once again, thanks for getting back, please do let me know if I can provide more information.

Thank you,

Raghu

Did you try convhulln instead on convhull? It is not clear what you mean by “Is it then not a good idea to expect such points to be included in the Convex Hull”. One can view this as included in the output definition of the convex hull or included in the interior of the convex hull. Either way, why is it not a good idea? If you have compelling reasons why the function should behave in a specific manner then we can consider filing an enhancement, but you have to justify your reasoning.

Thanks,

Damian

Thank you,

Raghu

Geometric computations in floating point arithmetic typically use internal tolerances to offset the loss of precision in the computation. This may capture intent more favorably in the presence of inaccurate input, but it’s a double edge sword. This approach is inherently fragile in degenerate and near coincidence scenarios and can lead to failure of the algorithm. If you wish to try the floating point computation you can call convhulln([x’ y’]) instead of convhull.

1.0000 1.0000 0.6667 0.3333 0.5000

y =

0 1.0000 0.3333 0.6667 0.5000

It seems that with all this literature about EGC it would compute the hull, but the point (0.5,0.5) is always left out. Is there any way to include tolerances in convhull computations? e.g., if a point is 1e-8 or closer to the hull, include it in the hull, maybe…
Thank you,
Raghu

This is an interesting question and I’m sure it’s one that most scientific-minded people have pondered on. Unfortunately, working for a math software company doesn’t give me any greater insight than anyone else who appreciates the beauty of math and science. To find answers to questions like these I subscribe to New Scientist magazine, but it often leaves me with more questions than answers and it appears in my mailbox faster than I can read it. Here’s an interesting and somewhat related article that appeared in last week’s edition:

http://www.newscientist.com/article/mg20527535.100-mind-over-matter-how-your-body-does-your-thinking.html

Damian

You could potentially use a 3D DelaunayTri to compute the intersection. But the implementation may not be simple. I can’t say how it would perform relative to the functions you are currently using as I have not tried or looked at geom3d. But if you were performing the intersection computation repeatedly on the same pair of polyhedra, you may be able to make some gains.

Here’s the approach… Given two polyheda P and Q construct a DelaunayTri Tp and Tq representing each. Test the boundary edges of Tp against Tq (and vice versa). You have have 3 scenarios;
1) Both edge vertices are contained in Tq.
2) One vertex contained in Tq the other is not – compute the intersection point.
3) Both edge vertices are not contained in Tq – the edge could potentially pass through Tq or lie completely outside Tq. More analysis, e.g. ray intersection to qualify. The intersection volume would be given by the convex hull of the interior points and intersection points.

OK, you get the idea. It’s not too difficult to get an approximate implementation up and running, but the real effort involves detecting and handling step 3 efficiently. DelaunayTri has a fast pointLocation test that will handle steps 1 and 2 very efficiently. But whether you can ignore step 3 depends on your accuracy requirements and the “shape” of your polyhedra.

For more ideas see Christer Ericson’s excellent book “Real-Time Collision Detection”. If you want to have a shot at implementing a Delaunay-based algorithm feel free to contact me off-line with any questions.

Damian