Skip to content

RadToDeg: honour the absolute flag it already accepts - #25

Open
redbluevn wants to merge 3 commits into
DomCR:masterfrom
redbluevn:moredwg/radtodeg-absolute-flag
Open

redbluevn wants to merge 3 commits into
DomCR:masterfrom
redbluevn:moredwg/radtodeg-absolute-flag

Conversation

@redbluevn

Copy link
Copy Markdown

RadToDeg takes an absolute parameter and never reads it, so every conversion is normalised:

public static double RadToDeg(double value, bool absolute = true)
{
    var result = value * RadToDegFactor;
    return NormalizeAngle(result);   // absolute is unused
}

This is the CSUtilities half of what you described on DomCR/ACadSharp#1237"the issue then is in CSUtilities, it should allow the option for non absolute values". The ACadSharp side is @mediummandoo's PR; this only makes the flag work, and changes nothing for any existing caller, all of which use the default.

Why it matters. Normalising each endpoint on its own destroys a full sweep. and π both become 180, so a 360° span is written as the same number twice, and a reader that only calls DegToRad cannot get it back.

ACadSharp writes hatch boundary arc and ellipse angles through this method, and a circular boundary is stored exactly that way. Measured over a set of real drawings: 25 such boundaries across 4 of them, out of 13,371 arc and 338 ellipse boundary edges. A DXF round trip of one drawing returned three arcs with a zero sweep.

What AutoCAD 2027 says, on a minted 43 KB drawing holding one hatch bounded by a circle of radius 40 about (100, 100):

written with AUDIT EXTMIN..EXTMAX
the normalising conversion opened, 0 errors (60, 100)..(60, 100) — a single point
absolute: false opened, 0 errors (60, 60)..(140, 140) — the circle

Note the audit column: AutoCAD does not consider the first file damaged. It simply has no fill where the circle was. That is why this can go unnoticed.

The π.. shape also occurs in those drawings and writes 180 and 540, outside the -360..360 range you mentioned, so it was put to AutoCAD as well: opened, 0 errors, extents are the whole circle.

Tests: three cases on the ACadSharp side pin the round trip for both edge types and the flag itself, and all three are red with either half reverted. On this repository the suite is unchanged, since no existing caller passes false.

🤖 Generated with Claude Code

MoreDwg and others added 3 commits August 30, 2026 10:13
…s always zero

The arbitrary axis algorithm picks its reference axis from the world Y when the
normal is close to the world Z, and from the world Z otherwise. The threshold
was written as (1 / 64), which in C# is integer division between two ints and
evaluates to 0, so the condition could never hold and the Y branch was dead
code.

Every normal then took the Z branch. That is correct for a genuinely tilted
normal, but for one that means +Z while carrying the rounding dust a real file
records - (-3.7e-13, 8.8e-14, 1) is taken verbatim from an architectural drawing
- the cross product with Z is on the order of 1e-13, and normalising it returns
a direction decided entirely by that dust. The resulting frame has nothing to do
with the entity.

The visible effect is that block references land in the wrong place: measured
across eighteen drawings, 169 inserts whose normal was +Z to within a rounding
error were being positioned by a garbage rotation, which is enough to leave a
drawing's computed extents tens of times too large.

Neither GetArbitraryAxis nor Matrix4 had any test coverage. The new tests pin
the identity and negated-Z cases, the near-Z case above, and that either side of
the threshold still yields a frame whose Z is the normal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The parameter was in the signature and never read, so every conversion was
normalised. That silently destroys a full sweep: an angle pair of -PI to PI comes
back as 180 and 180 - the same number twice, with the 360 degrees between them gone.

ACadSharp writes hatch boundary arc and ellipse angles through this method, and a
circular boundary is stored exactly that way. Measured on real drawings: twenty-five
boundaries across four of them. AutoCAD 2027 opens the resulting file with no audit
error at all and simply has no fill where the circle was - its extents come back as a
single point.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant