offseter leading to different results between v1 and v2

[gjaegy]

I've converted our code to rely on Clipper2Lib rather than on the original ClipperLib (6.4.2).

I've noticed a few difference in the results of an offset operation, and I can't really figure out what's causing this. In the example below, we individually offset the green polygons (which is made of numerous points, as we have different Z values for each of these points), twice in the interior, and twice in the exterior. We use the result of the first offset (interior or exterior) operation as the input for the second one in the same direction.

The main difference is visible in the corners (using a square joint type, polygon end type), where the offset polygon doesn't look as round/regular as in v1.

Also, there are a few points that get removed on the second offset (rather being interior or exterior), despite "preserve colinear" being set to true (I've also tried modifying the offseter code to have colinear points being preserved by the two Clipper64 objects using in that class - didn't make any difference).

I noticed the "ArcTolerance" value was set to 0.0 (vs 0.25 in the original ClipperLib), so I tried using 0.25 but that didn't help either.

Any idea what is causing the difference ?

Thanks a lot for that great library by the way ;)

ClipperLib:

Clipper2Lib:

ClipperLib:

Clipper2Lib:

[gjaegy]

Interestingly, I can get rid of the mentionned issues by not using the result of the previous offset operation as source for the outer-most polygon creation, but by using the original (green) one.

Still, this is what I was initially doing until now, so I don't understand why Clipper2Lib behaves differently in this regards. I'll further investigate next week.

[gjaegy]

I couldn't find what is causing that discrepancy :/ If anyone has any clue...

[gjaegy]

I've found out that I can get a similar result by reducing the magnitude of my points coordinates.

Basically, the original code transforms double coordinates (in the range 0..1000) to int64 by multiplying by 1e4. Using 1e2 instead gives results similar to what I got using Clipper1Lib.

Still, I don't understand why. In any case, (1000 * 1e4 = 1e7 max) is largely in both the int64 and double ranges (by far), so this puzzles me a bit at this stage...

[gjaegy]

Reducing the density of the points (was really dense) in the initial contour fixed the issue.

[AngusJohnson]

The main difference is visible in the corners (using a square joint type, polygon end type), where the offset polygon doesn't look as round/regular as in v1.

I'd need to see a (small) code example to understand what's going on. The images do look strange but without code I can't really help.