Clipper2
Clipper2 copied to clipboard
(C++, USINGZ) InflatePaths with negative delta sets Z value to 0
Hi,
when I use InflatePaths with a positive delta, the Z values in the points are conserved, but with a negative delta, the Z values are set to 0. Is this intended?
Paths64 subject64;
subject64.push_back(MakePathZ({ 800, 800, 1006, 1200, 800, 1006, 1000, 1200, 1006 }));
Paths64 test64inflated = InflatePaths(subject64, 10, JoinType::Miter, EndType::Polygon);
Paths64 test64deflated = InflatePaths(subject64, -10, JoinType::Miter, EndType::Polygon);
subject64:
x = 800, y = 800, z = 10006
x = 1200, y = 800, z = 10006
x = 1000, y = 1200, z = 10006
test64inflated:
x = 1006, y = 1210, z = 10006
x = 994, y = 1210, z = 10006
x = 784, y = 790, z = 10006
x = 1216, y = 790, z = 10006
test64deflated:
x = 1184, y = 810, z = 0
x = 1000, y = 1178, z = 0
x = 816, y = 810, z = 0
Can anyone reproduce this and/or explain that behaviour to me please?
Yes, i agree
I'll fix it shortly. I've been away on holidays.
Also if the original Z < 0 it always become 0 after offset
OK, I've now had a very good look at this issue - where concave joins will always lose their Z values. Unfortunately, it's almost impossible to fix this without introducing very complex code. Even explaining why this is problematic isn't easy (but you'll get the general idea here). Basically, concave joins create negative areas in the offset polygons that are later removed in a Union operation. And it's extremely difficult to associate intersection points in this Union op with vertices in the original paths. IOW, this won't be fixed and I'll flag this to document it as a library limitation.
On 14.02.24 г. 2:11 ч., Angus Johnson wrote:
OK, I've now had a very good look at this issue - where concave joins will always lose their Z values. Unfortunately, it's almost impossible to fix this without introducing very complex code. Even explaining why this is problematic isn't easy. Basically, concave joins create negative areas in the offset polygons that are later removed in a Union operation. And it's extremely difficult to associate intersection points in this Union op with vertices in the original paths. IOW, this won't be fixed and I'll flag this to document it as a library limitation.
If Z=nan in such cases it will be easier to fix by postprocessing.
Niki
I've found a way to (mostly) solve this issue of not assigning Z values at concave offsets.