Polyline nodes and bulges change after saving

Discussion forum for C++ and script developers who are using the QCAD development platform or who are looking to contribute to QCAD (translations, documentation, etc).

Moderator: andrew

Forum rules

Always indicate your operating system and QCAD version.

Attach drawing files, scripts and screenshots.

Post one question per topic.

Post Reply
CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Polyline nodes and bulges change after saving

Post by CVH » Wed Sep 08, 2021 4:20 pm

Andrew,
Polyline specific values change after saving and reloading a dxf file.

Differences occur between the polyline initial creation and after saving and reloading the file a first time.
Not occurring after any next successive save and reload.
Again occuring when for example a polyline is exploded and simply re-combined.

One would expect that vertices data is simply stored in textual format ... :!: :?:

Values were exported as text with value.toString()
Firts lines details are after initial creation, second lines details are after reload.
Observations are rather similar using value.toPrecision(21) what is an overkill.

e.g. Node coordinates:
(356.152540484957, 40.8631180197124)
(356.152540484958, 40.8631180197124)
Change: (+18ulps , equal)

(373.439183443961, 49.7244719768246)
(373.439183443961, 49.7244719768247)
Change: (equal , +14ulps)

e.g. Bulge factors:
-0.036392572262741 ... with 14 significant digits
-0.0363925722627411 ... with 15 significant digits
Change: -14ulp

0.00667844975655044 ... with 15 significant digits
0.0066784497565504 ... with 14 significant digits
Change: -46ulp

0.0536138838844993
0.0536138838844994
Change: +14ulp

That nodes change has a minute effect on the chord length.
There the chord and the bulge may alter has an effect on the arc radius.
Radius = chord / 4 * (1 / bulge + bulge) what is a exponential relation for bulge.
There the chord, the bulge and thus the radius may alter has a more pronounced effect on the arc center point location.
Height of the triangle Node1-Center-Node2 = sqrt(radius² - halfChord²)

Because of these changes after reloading,
two successive bulging segments their actual intersection point may differ even more with the joining node.

e.g. Shapes intersection point and differences with joining node:
(369.875542362287, 58.4544759808236) ... (+888ulp, +240ulp)
(369.875542362265, 58.4544759808229) ... (+518ulp, +139ulp)
Change: (-387ulp; -99ulp)
Here all rather minute but I have also recorded differences up to several hundred of thousands ulps and even up to 0,099... units.
All are moderate coordinates ... The larger the distance to the origin, the larger the influence will be.

Altough It is not yet fully clear where the very huge floating point differences occur ...
... it already explains more and more the issues I have with polylines with bulging segments.
Offsets ... Rounding Corners ... Pocketing ...

For some it also explains why self-intersections may pop up with huge differences with the nodes.
And also that a good self-intersections filtering threshold needs to be revised once the file is saved and reloaded.
See: https://qcad.org/rsforum/viewtopic.php?t=8526

Bottom line: Save & revert after creating a polyline with bulging segments.

Regards,
CVH
Last edited by CVH on Tue Aug 15, 2023 8:33 pm, edited 1 time in total.

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Polyline nodes and bulges change after saving

Post by CVH » Tue Sep 14, 2021 4:39 pm

Numbers in a textual dxf saved by QCAD never exceed 16 significant digits.
While Number.toPrecision(21) may export:
  • " 2.33839437375732450000" = 0x4002B5081C03813F = 2.33839437375732428492369763262e0
    " -1.15463194561016270000e-14" = 0xBD09FFFFFFFFFFFF = -1.15463194561016264426839589061e-14
With each 17 significant digits disregarding the trailing zeros.

Known is that the binary to decimal conversion or vice verse can not be utterly correct.
They are that correct when QCAD stores them in a variable or memory register.

Storing these values textual with fixed 16 significant decimal digits:
  • " 2.338394373757324" = 0x4002B5081C03813E = 2.33839437375732384083448778256e0
    "-1.154631945610163e-14" = 0xBD0A000000000001 = -1.15463194561016295981275797902e-14
Although the differences, if any, are very minor up to 10-100 ULPs, this may reflect in some
floating point Maths on entities with such numbers more than in other.

Explaining why things can be just that little different after reloading a file. :wink:

Regards,
CVH

Post Reply

Return to “QCAD Programming, Script Programming and Contributing”