Skip to content

Curve.HorizontalFrameAtParameter bug #17105

Description

@JacobSmall

Dynamo Version

4.0 and prior

Host

Core / Sandbox

Operating System

Windows 11

What did you do?

Used Curve.HorizontalFrameAtParameter on a circle

What did you expect to see?

The generated coordinate systems following the tangent and normal of the circle.

What did you see instead?

Coordinate systems with the X Y and Z axis following the global coordinate system.

Image

Two lines of designscript to reproduce:
crv = Circle.ByCenterPointRadius(Point.Origin(),10); coords = crv.HorizontalFrameAtParameter(0..1..#32);

What packages or external references (if any) were used?

None

Stack Trace

n/a

Details

none needed


Research Findings

Summary

Curve.HorizontalFrameAtParameter is not implemented in the DynamoDS/Dynamo repository. It is a method on Autodesk.DesignScript.Geometry.Curve defined inside the binary ProtoGeometry.dll, which ships from the closed-source LibG/ASM-based geometry library and is consumed here as a NuGet dependency (DynamoVisualProgramming.LibG_232_0_0, version 4.0.0.4841). The bug must therefore be fixed upstream in the LibG repository (or, less ideally, via a wrapper in Dynamo).

Per Dynamo's own in-repo documentation, the documented contract for HorizontalFrameAtParameter is:

The resulting coordinate system will have its z-axis in the world Z direction, and the y-axis in the direction of the tangent of the curve at the specified parameter.

For Circle.ByCenterPointRadius(Point.Origin(), 10) (a circle in the world XY plane), every sampled tangent is horizontal and the world Z direction is well-defined, so the node should produce 32 coordinate systems with rotating Y axes (tangent) and constant Z axes (world up). The reported output — every frame identical to the world basis — indicates LibG is degenerating to an identity rotation for circles (likely a special-case path that returns the curve's underlying plane axes instead of computing the per-parameter tangent).

The bug is reproducible on Dynamo 4.0 and prior, all of which reference LibG 4.0.0.4841 (or earlier LibG_231_0_0 / LibG_232_0_0_debug variants tracked in src/DynamoCore/DynamoCore.csproj:35-37 and src/Config/CS_SDK.props:11).

Key Discoveries

  • HorizontalFrameAtParameter has no C# source in this repo. Grep across the entire tree found 36 hits — all in documentation, icons, resx, and Lucene/test JSON fixtures. None define or implement the method.
  • The Curve class itself (Autodesk.DesignScript.Geometry.Curve) is declared in ProtoGeometry.dll shipped by NuGet. There is no class Curve declaration in this repo, and no this Curve extension methods either.
  • Documented contract (English markdown at doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.md:2): Z-axis = world Z, Y-axis = curve tangent, X-axis = perpendicular completion. The XML summary in doc/distrib/xml/en-US/ProtoGeometry.XML:1029-1036 is sparser ("axis-aligned CoordinateSystem at the point") — both should be reviewed if behavior is corrected upstream.
  • Sibling method CoordinateSystemAtParameter has a different, documented behavior (doc/distrib/xml/en-US/ProtoGeometry.XML:1020-1027): XAxis = curve normal, YAxis = curve tangent, ZAxis = binormal. The user's expectation in the issue body ("following the tangent and normal") more closely matches CoordinateSystemAtParameter, but the reported failure (axes locked to world) is still a clear bug regardless of which contract one applies — HorizontalFrameAtParameter should still produce a rotating Y axis.
  • LibG is delivered as a binary NuGet package; this repo only holds glue artifacts: icons, resx, customization XML, migration XML, localized XML docs, and node-help Markdown/.dyn files. Any fix in this repo would have to be either (a) bump the LibG package version after upstream fix, or (b) author a Dynamo-side wrapper that intercepts/overrides the call (uncommon for ProtoGeometry methods — no precedent for such wrappers was found in src/Libraries/CoreNodes/ProtoGeometryHelper.cs, which only contains an unrelated boundary-condition helper).

Detailed Findings

Where the implementation actually lives (external)

  • src/DynamoCore/DynamoCore.csproj:35-37 — Pulls DynamoVisualProgramming.LibG_231_0_0, LibG_232_0_0 (Release), and LibG_232_0_0_debug (Debug), all at version 4.0.0.4841.
  • src/DynamoCore/DynamoCore.csproj:120-131,210-218 — Copies LibG.Interface.dll, ProtoGeometry.dll, ProtoGeometry.XML, asm_deps, and locale resources from the NuGet package into the build output.
  • src/Config/CS_SDK.props:11<LIBGVer>libg_232_0_0</LIBGVer> is the preferred LibG version for CI.
  • extern/ProtoGeometry/ — Only ships config (ProtoGeometry.config), migrations (ProtoGeometry.Migrations.xml), and customization XML (ProtoGeometry_DynamoCustomization.xml). No DLL source.
  • extern/.gitignore — Indicates the actual LibG_* ASM binary folders are gitignored and restored from NuGet.
  • src/Libraries/GeometryColor/ImportHelpers.cs:11 — The only file in the repo declaring namespace Autodesk.DesignScript.Geometry; comments explicitly note that the closed-source assembly is separate ("Geometry Import nodes that have dependencies we don't want to introduce into Protogeometry").

Documented behavior of HorizontalFrameAtParameter

  • doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.md:2 — Authoritative description: "z-axis in the world Z direction, and the y-axis in the direction of the tangent of the curve at the specified parameter."
  • doc/distrib/xml/en-US/ProtoGeometry.XML:1029-1036 — XML summary: "Get a CoordinateSystem with origin at the point at the given parameter / The axis-aligned CoordinateSystem at the point." Search tags: frame,axisaligned,aa,coordcurve,framecurve,curveframe,coordoncurve.
  • 13 localized variants of both files exist under doc/distrib/xml/<locale>/ and doc/distrib/NodeHelpFiles/<locale>/.

What changes if the upstream LibG fix lands

If LibG ships a fix in a new build of ProtoGeometry.dll, the in-repo change required would be a version bump only:

  • src/DynamoCore/DynamoCore.csproj:35-37 — bump Version="4.0.0.4841" on the three DynamoVisualProgramming.LibG_* package references.
  • src/Config/CS_SDK.props:11 — update <LIBGVer> if the LibG major bumps (e.g., libg_232_0_0libg_233_0_0).

No other source-code change should be required to consume the corrected behavior.

Test coverage in this repo (sparse, indirect)

Behavioral coverage of HorizontalFrameAtParameter does not exist in this repo because the implementation is external. Only indirect references were found:

  • test/ViewExtensionLibraryTests/resources/libraryItems.json:708 — library catalog entry for the node (also pins the icon source as path=ProtoGeometry.dll).
  • test/Tools/docGeneratorTestFiles/sampledictionarycontent/Dynamo_Nodes_Documentation.json:1022 — doc-generator fixture.
  • test/DynamoCoreTests/NodesJsonDatasets/LuceneIndexedNodesRevit.json:1582, LuceneIndexedInfoSandboxTSplines.json:2506, LuceneIndexedInfoC3D.json:2402 — Lucene search-index fixtures referencing ProtoGeometry.Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.
  • Sibling sanity-check graphs exist for related Curve frame methods: test/core/GeometrySanityCheck/Curve.PlaneAtDistance.Simple.dyn, Curve.PlaneAtEqualArcLength.dyn, CoordinateSystem.AtParameter.Surface.dyn, plus visualization graphs test/core/visualization/Planes.dyn and imageComparison/CoordinateSystems.dyn. None target HorizontalFrameAtParameter specifically.

Node help / sample graph

  • doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.dyn — sample graph used in the documentation (uses a NurbsCurve, not a circle — so the bug is not visible there).
  • doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter_img.jpg — preview image (shared across locales).
  • 14 localized .md files exist under doc/distrib/NodeHelpFiles/<locale>/.

Icons / resx

  • src/Libraries/GeometryUIWpf/ProtoGeometryImages.resx:781-786 — maps Large/Small icons.
  • src/Resources/ProtoGeometry/LargeIcons/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.Large.png
  • src/Resources/ProtoGeometry/SmallIcons/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.Small.png

Files Requiring Changes

The implementation that produces the wrong output is not in this repository. The fix belongs in the external LibG/ProtoGeometry codebase. Once that fix ships a new package version, the only in-repo edits required are:

File Lines Change
src/DynamoCore/DynamoCore.csproj 35-37 Bump DynamoVisualProgramming.LibG_231_0_0, LibG_232_0_0, and LibG_232_0_0_debug Version="4.0.0.4841" to the patched LibG build.
src/Config/CS_SDK.props 11 Update <LIBGVer>libg_232_0_0</LIBGVer> if upstream rolls the LibG major (e.g., to libg_233_0_0).

Optionally — if regression coverage is desired so this doesn't silently recur:

File Lines Change
test/core/GeometrySanityCheck/ new file Add a .dyn sanity graph that calls Curve.HorizontalFrameAtParameter on a Circle.ByCenterPointRadius and asserts that frames at parameters 0, 0.25, 0.5, 0.75 have distinct Y axes (or at minimum that the Y-axis tangent rotates around the circle).

A pure in-repo workaround (e.g., a Dynamo-side wrapper that re-implements HorizontalFrameAtParameter on top of PointAtParameter + TangentAtParameter) is technically possible but has no precedent for ProtoGeometry methods and would introduce a divergent code path; we do not recommend it as the primary fix.

Open Questions

  1. Which axis is the bug in? The reported failure says all of X, Y, Z follow the world axes. The documented contract guarantees Z is world Z by design, so the actual bug is that the Y axis (tangent) is not being computed/applied for circles. Confirming via a debug build of LibG would isolate whether ProtoGeometry's circle special-case is short-circuiting tangent evaluation or whether the (tangent × worldZ) orthonormalization is collapsing.
  2. Does the bug affect non-circle planar curves whose plane equals the world XY plane? (e.g., NurbsCurve.ByControlPoints lying flat.) If yes, the root cause is broader than a Circle-specific special case and likely lives in the orthonormalization step for any horizontal-plane curve.
  3. Should HorizontalFrameAtParameter's XML summary in ProtoGeometry.XML be tightened to match the Markdown doc? The current XML summary "axis-aligned CoordinateSystem at the point" is misleadingly suggestive of the buggy output and could be improved upstream regardless of the bug fix.
  4. Is there an existing LibG ticket for this issue? The fix lives in a separate repo; a cross-reference from this issue to the corresponding LibG ticket would help track resolution.

Implementation Plan

Curve.HorizontalFrameAtParameter Bug Fix — Implementation Plan

Overview

Curve.HorizontalFrameAtParameter produces coordinate systems with all axes aligned to the world basis (identity rotation) when called on circles, instead of producing frames whose Y-axis follows the curve tangent at each parameter. The root cause is in ProtoGeometry.dll, shipped as the closed-source LibG NuGet package (DynamoVisualProgramming.LibG_232_0_0 v4.0.0.4841). This repo cannot fix the underlying logic, but it must: (1) coordinate the upstream fix, (2) consume the patched version once available, (3) improve in-repo documentation clarity, and (4) add a regression sanity-check graph so the bug cannot silently recur.

Current State Analysis

Key Discoveries:

  • HorizontalFrameAtParameter has no C# source in this repo — all 36 references are docs, icons, resx, and Lucene fixtures. Implementation is entirely in ProtoGeometry.dll from LibG.
  • LibG is pinned at DynamoVisualProgramming.LibG_232_0_0 v4.0.0.4841 in src/DynamoCore/DynamoCore.csproj:35-37 (three package references: Release, Debug, and LibG_231 for compatibility).
  • src/Config/CS_SDK.props:11 carries <LIBGVer>libg_232_0_0</LIBGVer> used by CI to resolve the preferred LibG folder.
  • The documented contract (doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.md:2): Z-axis = world Z, Y-axis = curve tangent, X-axis = cross-product completion. The bug: for circles the Y-axis (tangent) is never applied, every frame is identity.
  • doc/distrib/xml/en-US/ProtoGeometry.XML:1029-1036 — XML summary is misleadingly vague: "axis-aligned CoordinateSystem at the point" — could be read as describing the buggy output.
  • The sample .dyn (doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.dyn) uses a NurbsCurve.ByControlPoints with random 3D points, not a circle — so the bug is invisible in the current documentation example.
  • No test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter*.dyn exists — there is no regression guard for this node.

Desired End State

After this plan is complete:

  1. Curve.HorizontalFrameAtParameter on a circle produces 32 coordinate systems with distinct Y-axes (tangent direction rotating around the circle) and constant Z-axes (world up). Verifiable with the DesignScript snippet: crv = Circle.ByCenterPointRadius(Point.Origin(),10); coords = crv.HorizontalFrameAtParameter(0..1..#32);
  2. The LibG version referenced in src/DynamoCore/DynamoCore.csproj:35-37 is updated to the patched build.
  3. doc/distrib/xml/en-US/ProtoGeometry.XML:1029-1036 clearly describes the axis contract (Z=worldZ, Y=tangent) matching the Markdown documentation.
  4. The sample .dyn and preview image in doc/distrib/NodeHelpFiles/en-US/ use a circle as the input curve, showing rotating frames.
  5. test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter.Circle.dyn exists as a regression sanity-check graph for this node.

What We're NOT Doing

  • Implementing a Dynamo-side wrapper or monkey-patch for HorizontalFrameAtParameter. No precedent exists for overriding ProtoGeometry methods in this codebase, and it would create a divergent maintenance burden.
  • Updating the 13 non-English localized ProtoGeometry.XML variants — only doc/distrib/xml/en-US/ProtoGeometry.XML exists in-repo; the localized XMLs ship from the LibG NuGet package and are not editable here.
  • Updating the 14 localized .md files under doc/distrib/NodeHelpFiles/<locale>/ — localized documentation changes are out of scope for a bug fix.
  • Changing any node behavior, ports, search tags, icons, or resx files.

Implementation Approach

This is a three-phase effort: (1) do all in-repo pre-work that is independent of the upstream fix; (2) wait for LibG to ship a patched build; (3) land the version bump + sample graph update in a single Dynamo PR.


IMPORTANT: Checkboxes are for implementation steps only. Steps requiring manual human verification (browser testing, manual QA, visual inspection, staging verification, human review) MUST NOT be checkboxes — place them in the numbered "Manual Testing Steps" section at the bottom of the plan instead.


TASK 1: Fix the Bug Upstream in LibG [HIGH PRIORITY]

Status: NOT STARTED
Milestone: A patched ProtoGeometry.dll NuGet package (e.g. DynamoVisualProgramming.LibG_232_0_0 at a version higher than 4.0.0.4841) is available that correctly computes the Y-axis (tangent) for HorizontalFrameAtParameter on circles and other horizontal-plane curves.

  • File or locate an existing bug report in the LibG/ASM upstream repository describing the HorizontalFrameAtParameter circle regression (axes collapsing to identity for horizontal-plane curves).
  • Add a cross-reference comment on this GitHub issue (Curve.HorizontalFrameAtParameter bug #17105) linking to the upstream LibG ticket, so downstream tracking is clear.
  • Confirm with the LibG team whether the root cause is (a) a circle-specific special-case that bypasses tangent evaluation, or (b) an orthonormalization collapse in the (tangent × worldZ) step for any horizontal-plane curve — document the finding in the upstream ticket.
  • Verify the fix covers the broader case: test HorizontalFrameAtParameter on a flat NurbsCurve lying in the world XY plane in addition to a circle.

Validation: crv = Circle.ByCenterPointRadius(Point.Origin(),10); coords = crv.HorizontalFrameAtParameter(0..0.75..#4); produces 4 coordinate systems whose Y axes are distinct (approximately [1,0,0], [0,1,0], [-1,0,0], [0,-1,0]) and whose Z axes are all [0,0,1].

Requirements from spec:

  • Z-axis of each returned CoordinateSystem must equal world Z (0,0,1).
  • Y-axis of each returned CoordinateSystem must equal the curve tangent at the given parameter.
  • X-axis must be the cross-product completion (perpendicular to both Y and Z).

Files to Modify:

  • (External — LibG repository, not this repo)

TASK 2: Update ProtoGeometry.XML Documentation [LOW PRIORITY]

Status: NOT STARTED
Milestone: The in-repo XML summary for HorizontalFrameAtParameter accurately describes the axis contract and cannot be mistaken for the buggy (identity) behavior. This task is independent of the upstream fix and can land before it.

  • Open doc/distrib/xml/en-US/ProtoGeometry.XML at lines 1029–1036.
  • Replace the vague <summary> text ("Get a CoordinateSystem with origin at the point at the given parameter") and <returns> text ("The axis-aligned CoordinateSystem at the point") with precise descriptions matching the Markdown contract: summary should state the method returns a CoordinateSystem with Z-axis aligned to world Z and Y-axis aligned to the curve tangent at the parameter; <returns> should read "CoordinateSystem with ZAxis = world Z, YAxis = curve tangent at param".
  • Verify the updated XML is well-formed (no unclosed tags, valid XML entities).

Validation: grep -A 10 "HorizontalFrameAtParameter" doc/distrib/xml/en-US/ProtoGeometry.XML shows the updated summary mentioning "world Z" and "tangent".

Requirements from spec:

  • XML summary must not describe the output in terms that could be read as "axis-aligned" in the world sense (which is what the bug produces).
  • Must match the contractual description in the corresponding .md file.

Files to Modify:

  • doc/distrib/xml/en-US/ProtoGeometry.XML — update <summary> and <returns> within the M:Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter(System.Double) member element (lines 1029–1036).

TASK 3: Bump LibG NuGet Package Version [HIGH PRIORITY — depends on TASK 1]

Status: NOT STARTED (blocked on upstream fix from TASK 1)
Milestone: src/DynamoCore/DynamoCore.csproj references the patched LibG version, and a local Dynamo build uses the corrected ProtoGeometry.dll.

  • Obtain the patched LibG NuGet package version string from the upstream team (e.g., 4.0.0.XXXX or 4.1.0.XXXX).
  • In src/DynamoCore/DynamoCore.csproj:35, update Version="4.0.0.4841" on DynamoVisualProgramming.LibG_231_0_0 to the patched version.
  • In src/DynamoCore/DynamoCore.csproj:36, update Version="4.0.0.4841" on DynamoVisualProgramming.LibG_232_0_0 to the patched version.
  • In src/DynamoCore/DynamoCore.csproj:37, update Version="4.0.0.4841" on DynamoVisualProgramming.LibG_232_0_0_debug to the patched version.
  • If the LibG major version changed (e.g., libg_232_0_0libg_233_0_0): update <LIBGVer> in src/Config/CS_SDK.props:11 and rename/update any PackageReference Include= identifiers in DynamoCore.csproj:35-37 to match the new package name.
  • Run dotnet restore src/DynamoCore.sln (or Dynamo.All.sln) to confirm the new package resolves without errors.
  • Run dotnet build src/DynamoCore.sln -c Release to confirm the build succeeds with the updated LibG.

Validation: dotnet build src/DynamoCore.sln -c Release exits with code 0. Running Curve.HorizontalFrameAtParameter on a circle in Dynamo Sandbox produces rotating Y-axis frames.

Requirements from spec:

  • All three LibG package references (Release, Debug, LibG_231 compat) must be bumped consistently.
  • CI config (CS_SDK.props) must stay in sync with the package name used.

Files to Modify:

  • src/DynamoCore/DynamoCore.csproj — lines 35–37, bump Version attribute on all three LibG PackageReference elements.
  • src/Config/CS_SDK.props — line 11, update <LIBGVer> only if the LibG major package name changes.

TASK 4: Update Sample Documentation Graph and Preview Image [MEDIUM PRIORITY — depends on TASK 1]

Status: NOT STARTED (blocked on upstream fix from TASK 1 so preview image shows correct output)
Milestone: The node help sample for HorizontalFrameAtParameter uses a circle as the input curve, demonstrating the correct rotating-frame behavior, with an updated preview image.

  • Open doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.dyn.
  • Replace the current graph (NurbsCurve from random points + single slider) with a graph that: creates Circle.ByCenterPointRadius(Point.Origin(), 10) via a Code Block, feeds it into Curve.HorizontalFrameAtParameter with a range input 0..1..#8 (or a Number Slider 0–1), and outputs the resulting CoordinateSystems.
  • Keep the Number Slider as the published input (so the example stays interactive in the docs viewer).
  • Save the updated .dyn in the same JSON format (schema version matching other recent NodeHelpFiles .dyn files).
  • Regenerate doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter_img.jpg by running the updated .dyn in Dynamo with the patched LibG, capturing a background-preview screenshot showing the 8 rotating frames on the circle, and saving it as the replacement JPG.

Validation: Opening the updated .dyn in Dynamo Sandbox (with patched LibG) shows 8 CoordinateSystems evenly spaced on a circle, each with a distinct Y-axis direction tangent to the circle, and a consistent Z-axis pointing up.

Requirements from spec:

  • Sample must demonstrate the correct contract: rotating Y-axis (tangent), constant Z-axis (world up).
  • Preview image must show correct output (not the buggy identity frames).

Files to Modify:

  • doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter.dyn — replace NurbsCurve graph with circle-based graph.
  • doc/distrib/NodeHelpFiles/en-US/Autodesk.DesignScript.Geometry.Curve.HorizontalFrameAtParameter_img.jpg — replace with new preview image captured from the updated graph.

TASK 5: Add Regression Sanity-Check Graph [MEDIUM PRIORITY]

Status: NOT STARTED
Milestone: test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter.Circle.dyn exists and, when run against a patched LibG build, produces CoordinateSystem outputs whose Y-axis components are distinct across the sampled parameters — preventing silent regression.

  • Create test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter.Circle.dyn as an XML Workspace .dyn file matching the format of neighboring sanity check graphs (e.g., Curve.PlaneAtDistance.Simple.dyn).
  • The graph should: define a Circle.ByCenterPointRadius(Point.Origin(), 10) via a Code Block, sample HorizontalFrameAtParameter at parameters {0, 0.25, 0.5, 0.75}, extract the YAxis of each returned CoordinateSystem, and feed all 4 Y-axis vectors into Watch nodes.
  • Add CoordinateSystem.YAxis and CoordinateSystem.Origin extraction nodes so the output is inspectable/verifiable by a test runner.
  • Set RunType="Manual" and HasRunWithoutCrash="False" as initial state (matching the convention in sibling sanity-check files).
  • The graph must reference ProtoGeometry.dll in its NamespaceResolutionMap for Circle and CoordinateSystem.

Validation: Running the .dyn in Dynamo with the patched LibG produces 4 Vector outputs for the Y-axes: approximately (1,0,0), (0,1,0), (-1,0,0), (0,-1,0) (or their negatives, depending on circle orientation convention). None should be (0,0,1) or (1,0,0) for all four (which would indicate the regression is back).

Requirements from spec:

  • Must use Circle.ByCenterPointRadius as the test curve (the exact reproducer from the bug report).
  • Must sample at 4 distinct parameters to verify the Y-axis rotates.

Files to Create:

  • test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter.Circle.dyn — new XML Workspace sanity-check graph.

Testing Strategy

Unit Tests:

  • No new NUnit tests are required: the implementation lives in ProtoGeometry.dll, not in testable C# in this repo.
  • The sanity-check .dyn in TASK 5 serves as the behavioral regression guard.

Integration Tests:

  • Run test/core/GeometrySanityCheck/Curve.HorizontalFrameAtParameter.Circle.dyn in Dynamo Sandbox after the version bump (TASK 3) to confirm correct frame outputs.
  • Run the existing geometry sanity-check suite (test/core/GeometrySanityCheck/) to confirm no regressions in neighboring Curve frame methods (Curve.PlaneAtDistance, Curve.PlaneAtEqualArcLength, CoordinateSystem.AtParameter).

Manual Testing Steps:

  1. Open Dynamo Sandbox with the patched LibG build and run: crv = Circle.ByCenterPointRadius(Point.Origin(),10); coords = crv.HorizontalFrameAtParameter(0..1..#32); — verify 32 coordinate-system glyphs visible in the background preview, each rotated tangentially around the circle, Z-axes all pointing up.
  2. Verify the same script on a flat NurbsCurve.ByPoints lying in the world XY plane produces analogous rotating-frame output (regression check for the broader horizontal-plane curve case).
  3. Verify CoordinateSystemAtParameter (sibling method) still produces its own distinct output (XAxis = normal, ZAxis = binormal) — confirm no cross-contamination from the fix.
  4. Open the updated sample .dyn (TASK 4) in Dynamo Sandbox and confirm the circle-based graph runs without errors and the background preview matches the new _img.jpg.

Performance Considerations

None. This is a bug fix in a geometry evaluation method — there are no new allocations, loops, or data structures introduced in this repo. The version bump consumes the same NuGet restore path as the current build.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kilnCreated by kilnplan_readyplan_ready completepr_readyPR is ready for reviewresearch_readyresearch_ready complete

    Type

    No type

    Projects

    Status
    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions