One sided offset

[LarsSkiba]

Hi @AngusJohnson,

i know currently Clipper2 does not support this and you currently do not plan to implement it. (#882)

• Would you see this as valueable contribution to your library? Otherwise i'd implement it externally.
• Could you maybe assist with your knowledge a bit? First just a general assesment, no need for details. But if i implement this, i might have some very specific, detailed, followup questions.

I have some rough overview about your offsetting algorithm. Afaik you currently do two-sided offset and then resolve the self-intersection by applying a union. I don't see a reason why this approach would not work the same for a one-sided offset, would you agree?

Currently my idea is to extent ClipperOffset::OffsetOpenPath so that it produces a one sided offset. This seems doable, but i guess there will be some details i'm currently not aware of.

Do you think this approach in general can end up with the desired result or could there be some (big) pitfalls you are already aware of?

Would be really helpful if you could give a few comments related to this.

Thanks, Lars

[AngusJohnson]

I have some rough overview about your offsetting algorithm. Afaik you currently do two-sided offset and then resolve the self-intersection by applying a union.

Correct.

I don't see a reason why this approach would not work the same for a one-sided offset, would you agree?

Yes.

Currently my idea is to extent ClipperOffset::OffsetOpenPath so that it produces a one sided offset. This seems doable, but i guess there will be some details i'm currently not aware of. Do you think this approach in general can end up with the desired result or could there be some (big) pitfalls you are already aware of?

I think you're well on the way, and I don't see any pitfalls.

[mariuszhermansdorfer]

@LarsSkiba,
Did you make any progress on this topic? I’d be willing to join forces on this one if you needed any help.

[mariuszhermansdorfer]

Here is my first attempt at this:

The results shown above are before this step. Performing a Union operation results in a big mess :) Any suggestions on how to remove self-intersections from the results @AngusJohnson?

Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp

Lines 599 to 623 in ed98928

	Clipper64 c;
	c.PreserveCollinear(false);
	//the solution should retain the orientation of the input
	c.ReverseSolution(reverse_solution_ != paths_reversed);
	#ifdef USINGZ
	auto fp = std::bind(&ClipperOffset::ZCB, this, std::placeholders::_1,
	std::placeholders::_2, std::placeholders::_3,
	std::placeholders::_4, std::placeholders::_5);
	c.SetZCallback(fp);
	#endif
	c.AddSubject(*solution);
	if (solution_tree)
	{
	if (paths_reversed)
	c.Execute(ClipType::Union, FillRule::Negative, *solution_tree);
	else
	c.Execute(ClipType::Union, FillRule::Positive, *solution_tree);
	}
	else
	{
	if (paths_reversed)
	c.Execute(ClipType::Union, FillRule::Negative, *solution);
	else
	c.Execute(ClipType::Union, FillRule::Positive, *solution);
	}

[LarsSkiba]

I did make progress and have a 90% done solution and realized the solution is correct, but not what i expect.

Consider this open path:

This is result with boost buffer and similiar implementation, most are based on GEOS and CGAL. They all show a similiar behavior.

And if you think about this more detailed you will understand it's not just a problem local at angles with less than 90 degree. The same "self intersection" can occur "non-locally".

I have an implementation which behaves like this in most cases, still a few bugs to fix. I currently follow a different approach, i'll try to contribute my solution early next year.

[mariuszhermansdorfer]

Hmm, this is definitely not what I'd expect either. Here is an example of how Rhino (a CAD modelling suite) handles a similar case:

2024-11-18.11-38-34.mp4

Not sure why your results have these:

[LarsSkiba]

Yes, that's what i need too, but Rhino will fail horrible in some scenarios.

E.g. construct a shape like this.

The interior result looks good. Now further increase the offset.

[LarsSkiba]

Most buffer implementation seem to follow this concept:

A one sided offset is the union of all offsetted line segments and the arc / miter end at convex vertices. This explains the result at angles less than 90 degree.

[mariuszhermansdorfer]

A one sided offset is the union of all offsetted line segments and the arc / miter end at convex vertices.

But this should be true only for the resulting part, the input polyline should not be altered. Wouldn't this work?

1. Offset edges
2. Union results
3. Stitch with input

[LarsSkiba]

3. is not well defined

Think abut this polyline.

[mariuszhermansdorfer]

What would be your preferred result of an offset operation on such an input polyline?

[mariuszhermansdorfer]

imho Rhino does a good job here:

[EDIT] Offsetting inwards is less successful, but I'm not sure what to expect either :)

[LarsSkiba]

i was thinking about the "inwards" offset, but keep in mind that there is no "inwards". Just left and right relative to the direction.

I'm not sure what to expect either

Exactly, but an algorithm should follow some formal defintion.

[mariuszhermansdorfer]

@AngusJohnson,

is there an existing part of Clipper, which would allow us to remove self intersections from a single open path like the green one in the following example?

[LarsSkiba]

Just another idea for an algorithm, that probably provides something close to the expected result will be the following.

1. Connect the end points of your open line offset with the input to form a closed polygon.
2. Simplify / union this polygon as is done already in Execute() currently. This will remove the self-intersections.
3. Identify the two offsetted end points and only preserve the path inbetween, to get the desired open path. You can do this geometrically or by using the Z coordinates to mark these points.