Replies: 6 comments 7 replies
-
Firstly, the purpose of the arc tolerance parameter (with offsetting) is to allow users to specify what they consider a sensible compromise between achieving curve quality (with rounded offsets) while avoiding generating excessive numbers of vertices. And in your example above you are generating a huge (and arguably excessive) numbers of vertices. These will seriously degrade performance (eg in offsetting, in rendering, an in storage), and almost certainly won't achieve any detectable improvement in arc quality. Further, arc precision is premised on the assumption that arcs will be starting exactly where they're meant to start. And that's not the case here, so the imprecision that you are seeing is unrelated to arc quality. The offset imprecision is very small - less than 0.03% of the offset delta. And setting join_type = JoinType::Bevel, where offsetting should always be less than or equal delta, still somehow causes some offsetting to exceed delta (though again by about 0.03%). So I am still investigating why there is even this small amount of offsetting imprecision, and it's unlikely just due to rounding errors. More info on arc tolerance here. |
Beta Was this translation helpful? Give feedback.
-
Replace: Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp Lines 412 to 415 in 9299eb6 with:
and replace: Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp Lines 422 to 424 in 9299eb6 with:
|
Beta Was this translation helpful? Give feedback.
-
I'm confident that this is now fixed. Thank you for your patience and persistence. |
Beta Was this translation helpful? Give feedback.
-
I'm always happy for constructive criticism, though I do appreciate the warning 😜😁.
You are right that both input and output paths should be assessed for segment proximity rather than vertex proximity. And I agree that my GetOffsetQuality() function was only measuring output vertex distances from input segments, not output segments from input segments. And indeed this needs fixing as you've proposed. I modified your original offset testing code because I was focusing on why there were these unexplained discrepancies in offsetting, though I was confident it wasn't coming from my arc approximation code. So my focus was on where rounding started and ended. And as it turned out the discrepancies I've found weren't coming from arcs but from where I tried to avoid creating segments of almost no length (and improve performance). I had assumed (incorrectly) that these tweaks would have no measurable effect on offset quality. I'm keen, of course, to ensure that Clipper2 is at least as good as Clipper1 in offsetting precision. Until now I had assumed that it was (notwithstanding the various bugs I introduced and fixed while trying to improve performance). So could you please post examples where Clipper2 offsetting still isn't right? |
Beta Was this translation helpful? Give feedback.
-
Replace: Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp Lines 412 to 423 in 906bc1d with:
|
Beta Was this translation helpful? Give feedback.
-
Thanks for your fix. This discussion can now be closed. |
Beta Was this translation helpful? Give feedback.
-
Its me again :)
Some of polygonized arc segments in the offset output are violating offset distance significantly.
Clipper1 on the same input was not violating it for more than 1.5 units of distance.
Clipper2 violates it on 14470.2 units of distance.
Red is input, green is output, blue points on arcs is where polygonization violates distance.
Somehow only subset of arcs has these problems.
Test (As always, add this to your unit tests please):
Beta Was this translation helpful? Give feedback.
All reactions