QPolygonF error
-
@Christian-Ehrlicher still not what you need?
low.united(high).united(high)?Why the second call? What does calling it only once produce?
-
low.united(high).united(high)?Why the second call? What does calling it only once produce?
@kshegunov I have an application that combines graphs of changing values, nothing prevents different "scenes" with same graphs that can combined more times. now I have 3 scenes, on 3 lines, the top two scenes have exactly the same graph, and if i combine them all, this leads to this error
-
@kshegunov I have an application that combines graphs of changing values, nothing prevents different "scenes" with same graphs that can combined more times. now I have 3 scenes, on 3 lines, the top two scenes have exactly the same graph, and if i combine them all, this leads to this error
Okay, this answers the first question, what about the second? Does calling
.uniononly once produce the correct result?Read and abide by the Qt Code of Conduct
-
Okay, this answers the first question, what about the second? Does calling
.uniononly once produce the correct result?@kshegunov said in QPolygonF error:
Does calling .union only once produce the correct result?
Yes, but with slightly different numbers (not visible in a plain debug output). I would guess somewhere in the clipping logic a rounding error triggers this bug (e.g. 314.87615740 / 43.51943745 <-> 314.87600000 / 43.51940000)
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
Okay, this answers the first question, what about the second? Does calling
.uniononly once produce the correct result?@kshegunov yes, but I cant check top polygons are equal, because they must be combined in order in the loop and can have different overlay types, and checking high by points before united is not entirely correct, because a polygon can contain a point, but not a union
-
@kshegunov said in QPolygonF error:
Does calling .union only once produce the correct result?
Yes, but with slightly different numbers (not visible in a plain debug output). I would guess somewhere in the clipping logic a rounding error triggers this bug (e.g. 314.87615740 / 43.51943745 <-> 314.87600000 / 43.51940000)
@Christian-Ehrlicher said in QPolygonF error:
Yes, but with slightly different numbers (not visible in a plain debug output). I would guess somewhere in the clipping logic a rounding error triggers this bug (e.g. 314.87615740 / 43.51943745 <-> 314.87600000 / 43.51940000)
Looks truncated more than a rounding error.
@Daniil-S said in QPolygonF error:
yes, but I cant check top polygons are equal, because they must be combined in order in the loop and can have different overlay types, and checking high by points before united is not entirely correct, because a polygon can contain a point, but not a union
I was asking to discern whether the problem is that the two unions apply the same polygon only, there's a lot of edge cases whenever you're dealing with lines which are almost parallel (e.g. https://codereview.qt-project.org/c/qt/qtbase/+/292807).
Please search the tracker and if this isn't reported, do so. Attach the minimal code to reproduce as well. Whenever I finish with that
QLineFthing, given time I'll take a look.Read and abide by the Qt Code of Conduct
-
@Christian-Ehrlicher said in QPolygonF error:
Yes, but with slightly different numbers (not visible in a plain debug output). I would guess somewhere in the clipping logic a rounding error triggers this bug (e.g. 314.87615740 / 43.51943745 <-> 314.87600000 / 43.51940000)
Looks truncated more than a rounding error.
@Daniil-S said in QPolygonF error:
yes, but I cant check top polygons are equal, because they must be combined in order in the loop and can have different overlay types, and checking high by points before united is not entirely correct, because a polygon can contain a point, but not a union
I was asking to discern whether the problem is that the two unions apply the same polygon only, there's a lot of edge cases whenever you're dealing with lines which are almost parallel (e.g. https://codereview.qt-project.org/c/qt/qtbase/+/292807).
Please search the tracker and if this isn't reported, do so. Attach the minimal code to reproduce as well. Whenever I finish with that
QLineFthing, given time I'll take a look.@kshegunov said in QPolygonF error:
Looks truncated more than a rounding error.
No error - qDebug() prints not the complete double value, I guess the values are taken from there. Mine are the exact ones :)
So basically a polygon is united with a polygon which nearly matches parts of the first polygon which fails sometimes.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@kshegunov said in QPolygonF error:
Looks truncated more than a rounding error.
No error - qDebug() prints not the complete double value, I guess the values are taken from there. Mine are the exact ones :)
So basically a polygon is united with a polygon which nearly matches parts of the first polygon which fails sometimes.
@Christian-Ehrlicher said in QPolygonF error:
So basically a polygon is united with a polygon which nearly matches parts of the first polygon which fails sometimes.
Yes, what I imagine happens. Probably somewhere in the clip/intersection code there's some numerical instability that breaks it silently.
-
@Christian-Ehrlicher said in QPolygonF error:
Yes, but with slightly different numbers (not visible in a plain debug output). I would guess somewhere in the clipping logic a rounding error triggers this bug (e.g. 314.87615740 / 43.51943745 <-> 314.87600000 / 43.51940000)
Looks truncated more than a rounding error.
@Daniil-S said in QPolygonF error:
yes, but I cant check top polygons are equal, because they must be combined in order in the loop and can have different overlay types, and checking high by points before united is not entirely correct, because a polygon can contain a point, but not a union
I was asking to discern whether the problem is that the two unions apply the same polygon only, there's a lot of edge cases whenever you're dealing with lines which are almost parallel (e.g. https://codereview.qt-project.org/c/qt/qtbase/+/292807).
Please search the tracker and if this isn't reported, do so. Attach the minimal code to reproduce as well. Whenever I finish with that
QLineFthing, given time I'll take a look. -
@kshegunov yes, it only happens if two identical polygons are combine.
here i think, is what is neededlol. "Out of scope" ... what can I say ...
I suggest you open a new one, attach the reproducing code (the minimal one that @Christian-Ehrlicher insisted on), and put in the:
"Relates to ..." field in JIRAQTBUG-38037, as it does indeed seem related. -
-
As I was looking into this, I also opened:
-
As I was looking into this, I also opened:
@kshegunov I noticed it, but thought that I did something wrong
-
As I was looking into this, I also opened:
-
@kshegunov probably, as advised in one of the reports, I will use the clipper library
@Daniil-S said in QPolygonF error:
@kshegunov probably, as advised in one of the reports, I will use the clipper library
Yes, that's prudent as even if I have the time and will to fix at least some of this, assuming it gets accepted to begin with, it can be a long time.
