ClipperOffset output path may disappear under certain conditions

[tkhisak]

In the code below, the output of ClipperOffset will be empty.

#include <iostream>
#include "clipper2/clipper.h"
#include "clipper2/clipper.offset.h"

int main( void )
{
    Clipper2Lib::Path64 pathTest;
    pathTest.push_back( Clipper2Lib::Point64 { 0, 0 } );
    pathTest.push_back( Clipper2Lib::Point64 { 10000, 0 } );
    pathTest.push_back( Clipper2Lib::Point64 { 5000, 5000 } );

    Clipper2Lib::ClipperOffset offsetTest( 0.0 );
    offsetTest.AddPath( pathTest, Clipper2Lib::JoinType::Bevel, Clipper2Lib::EndType::Polygon );
    Clipper2Lib::Paths64 result;
    offsetTest.Execute( -1050, result );

    std::cout << result.size() << std::endl; // "0"
}

The cause seems to be that the inverted area resulting from the offset is not excluded when calculating the area of path_out in the section below.

void ClipperOffset::OffsetPolygon(Group& group, const Path64& path, bool is_shrinking, double area)
{
	path_out.clear();
	for (Path64::size_type j = 0, k = path.size() - 1; j < path.size(); k = j, ++j)
		OffsetPoint(group, path, j, k);

	// make sure that polygon areas aren't reversing which would indicate
	// that the polygon has shrunk too far and that it should be discarded.
	// See also - #593 & #715
	if (is_shrinking && area // area == 0.0 when JoinType::Joined
		&& ((area < 0) != (Area(path_out) < 0))) return;
	
	solution.push_back(path_out);
}

[AngusJohnson]

Thanks for the feedback. And yes this is definitely a bug that needs fixing.

[AngusJohnson]

Unfortunately, there isn't an easy fix, and the explanation is complicated 😱.

Paths 'shrink' usually when offsets are negative, but holes will also shrink when offsets are positive. Anyhow, when paths are shrinking it's possible to 'over-shrink' them, and when this happens path orientations reverse. In order to remove these over-shrunk paths, Clipper checks path orientation both before and after offsetting. But this needs to be done before the final Union operation that cleans up the offset paths. (And why this Union operation is needed will be explained below.) Unfortunately after this Union operation, there's no simple way to associate the resulting paths with paths prior to this operation. (Yes, Clipper could enable and use the Z field in paths to do this, but that would prevent Z being used for other purposes when offsetting.) So currently Clipper checks for path reversal before the final Union operation.

Why is checking for path orientation reversal before the final Union occasionally a problem? And why is a Union operation needed? Usually, determining where negative offset joins occur is fairly simple - just offset the adjacent edges and find where these intersect. But sometimes this approach won't work.

For example, when negative offsetting (-25) the path - 335,79, 211,180, 28,177, 22,183, 87,29 - using the above approach: This will produce:

To get around this, Clipper uses a different approach when offsetting produces concave joins. Instead of finding the intersect point of the offset adjacent edges, Clipper offsets vertices at concave joins by (temporarily) inserting 3 points there as illustrated in the following image: This creates negative areas at these concave joins which the final Union operation removes:

Unfortunately, on occasions (as indicated at the start of this thread), the (temporary) negative areas produced at these concave joins will be greater than the non-negative areas - and this will flag path reversal and trick Clipper into removing these paths (believing that the path has shrunk too much).

So, in short, I'm still contemplating how best to address this problem.

[AngusJohnson]

This should now be fixed in the latest revision. (I'm no longer performing area checking pre-and post offsetting to exclude excessive offsetting.)