QPolygonF error
-
@Daniil-S said in QPolygonF error:
or a smaller example?
Do you really need about 100 lines of code to draw a polygon to illustrate whatever your problem is? Have you reduced this to some minimum which exemplifies the problem? Any example to illustrate a point which is longer than about 20 lines is suspect....
-
I will not debug your code, as @JonB said (and also me some time ago) a simple list with the polygons as input and the (wrong) and correct output is the way to go.
-
QVector<QPointF> high, low; high << QPointF(293,0) << QPointF(406.102, 225) << QPointF(556,0); low << QPointF(79,-1) << QPointF(182.303, 57) << QPointF(673,-1); qDebug() << HtpType(HtpType(low, high), high); QVector<QPointF> high1, low1; high1 << QPointF(293,0) << QPointF(406.102, 225) << QPointF(556,0); low1 << QPointF(79,-1) << QPointF(182.303, 60) << QPointF(673,-1); qDebug() << HtpType(HtpType(low1, high1), high1);
first qDebug() (second point of low Y = 57) bad result
QVector(QPointF(79,-1), QPointF(182.303,57), QPointF(293,44), QPointF(293,0), QPointF(293,44), QPointF(313.881,41.5388), QPointF(293,0), QPointF(313.881,41.5388), QPointF(406.102,225), QPointF(546.601,14.1078), QPointF(556,13), QPointF(556,0), QPointF(406.102,225), QPointF(313.881,41.5388), QPointF(556,-1), QPointF(673,-1))
second qDebug() (second point of low Y = 60) right result
QVector(QPointF(79,-1), QPointF(182.303,60), QPointF(293,46), QPointF(314.79,43.3487), QPointF(406.102,225), QPointF(545.85,15.2349), QPointF(556,14), QPointF(556,-1), QPointF(673,-1))
to combine two plots, I need to use this method, because graphs has flags that cannot be changed during combine, so the intersection is first searched and it is combined to the top
-
This is a testcase similar to what we want to see:
int main(int argc, char **argv) { QCoreApplication app(argc, argv); QPolygonF p1 = QVector<QPointF>({{1., 0.}, {2., 1.}, {3., 1.}, {4., 1.}}); QPolygonF p2 = QVector<QPointF>({{2., 2.}, {3., 2.}, {4., 5.}, {3., 2.}}); QPolygonF united = p1.united(p2); QPolygonF expected = QVector<QPointF>({{1., 0.}, {2., 1.}, {3., 1.}, {4., 1.}, {1., 0.}, {2., 2.}, {3., 2.}, {4., 5.}, {3., 2.}, {2., 2.}, {1., 0.}}); qDebug() << (united == expected); qDebug() << united; qDebug() << expected; return 0; }
-
int main(int argc, char *argv[]) { QPolygonF high, low; high << QPointF(293, 0) << QPointF(406.102, 225) << QPointF(556, 0); low << QPointF(79, -1) << QPointF(182.303, 60) << QPointF(673, -1); QPolygonF low1(low.united(high).united(high)) , expected({ QPointF(79,-1), QPointF(182.303,60), QPointF(314.876,43.5194), QPointF(406.102,225), QPointF(546.162,14.7677), QPointF(673,-1), QPointF(79,-1) }); qDebug() << low1; qDebug() << expected; qDebug() << (expected == low1); return 0; }
qDebug()
QPolygonF(QPointF(79,-1)QPointF(182.303,60)QPointF(314.876,43.5194)QPointF(293,0)QPointF(556,0)QPointF(406.102,225)QPointF(314.876,43.5194)QPointF(182.303,60)QPointF(79,-1)QPointF(314.876,43.5194)QPointF(406.102,225)QPointF(546.162,14.7677)QPointF(673,-1)QPointF(79,-1)QPointF(182.303,60)QPointF(314.876,43.5194)QPointF(293,0)QPointF(556,0)QPointF(406.102,225)QPointF(314.876,43.5194)QPointF(79,-1)) QPolygonF(QPointF(79,-1)QPointF(182.303,60)QPointF(314.876,43.5194)QPointF(406.102,225)QPointF(546.162,14.7677)QPointF(673,-1)QPointF(79,-1)) false
-
@Christian-Ehrlicher still not what you need?
-
@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 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)
-
@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
-
@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
QLineF
thing, 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.
-
@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.
-
lol. "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: