Conversation
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RadToDegtakes anabsoluteparameter and never reads it, so every conversion is normalised: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 become180, so a 360° span is written as the same number twice, and a reader that only callsDegToRadcannot 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):
EXTMIN..EXTMAX(60, 100)..(60, 100)— a single pointabsolute: false(60, 60)..(140, 140)— the circleNote 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
π..3πshape also occurs in those drawings and writes180and540, 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