[Help!] Curve length mismatch: Rhino 8 → Grasshopper → Tekla Live Link

[Jingzhou]

Hi everyone,
I’m running into a serious chainage/length consistency issue when transferring curves from Rhino + Grasshopper into Tekla via Tekla Live Link (Construct Object). The same curve ends up reporting different lengths at different stages, and the difference can be very large, which breaks chainage-based positioning and any downstream modeling.

• Rhino: Rhino 8.0

• Tekla: Tekla Structures 2025

• Plugin: Tekla Live Link (using Construct Object)

---

1) Issue: length is not consistent (can be a big difference)

I drew a simple test curve in Rhino (just to reproduce the problem), then:

• In Grasshopper, I referenced the curve and measured its length using Length

• I sent the curve into Tekla Live Link → Construct Object and created the curve object in Tekla

• Back in Grasshopper, I measured the length again on the Construct Object output

• In Tekla, I checked the imported curve object’s displayed length (the 3rd screenshot is from Tekla)

Result: all three lengths differ (GH curve length vs GH length after Construct Object vs Tekla’s displayed length). In some cases, the length shown in Tekla is far from Rhino/GH (not just mm-level tolerance).

---

2) Related issue in GH: “1000 m point” differs by method

On the same curve in GH, I tried to locate the point at 1000 m along the curve using two common methods:

• Evaluate Length (input = 1000 m)

• Divide Distance (Distance = 1000 m, then select the corresponding division point)

Result: the “1000 m” point from these two methods is not the same (points do not coincide on the curve).

This makes me suspect that somewhere in the pipeline (or even inside GH depending on curve type/settings) there’s some combination of curve rebuilding, polyline approximation, projection, tolerance handling, or unit/scale conversion that changes the effective length/chainage logic.

---

3) Minimal reproduction steps

• Rhino: draw any curve (PolyCurve / NurbsCurve, etc.)

• GH: reference the curve

• GH: measure with Length

• GH: compare “1000 m point” from Evaluate Length(1000) vs Divide Distance(1000)

• Tekla Live Link: import via Construct Object

• GH: measure Length on the Construct Object output

• Tekla: check the imported curve object length (3rd screenshot is Tekla)

---

4) Questions

1. Does Tekla Live Link (Construct Object) rebuild / discretize / project the curve during import?
   For example, converting to a polyline with some chord tolerance, refitting, or projecting to a plane?

2. Why would GH’s Evaluate Length and Divide Distance produce different locations for the same “1000 m” distance on a single curve?
   What common causes should I check (PolyCurve segments, curve domain, tolerance, rebuild/refit, discontinuities, etc.)?

3. What’s the recommended workflow to ensure consistent length/chainage across Rhino/GH/Tekla?
   Examples: pre-convert to a high-resolution polyline in GH before import, enforce specific tolerances, unify unit settings, or transfer only chainage points and reconstruct the curve inside Tekla.

---

I’ve attached three screenshots (again: the 3rd one is from Tekla). Any insights into the underlying cause or a robust workaround would be greatly appreciated. Thank you

[Oskar_Scherdin]

Hi,

Can you add some sample files, scripts etc for us to test with since we all help here using our own time.

Oskar

[Jingzhou]

Hi Oskar,

Sure — I’ve added the Rhino and Grasshopper files I used for the curve/length experiments in the appendix, so you can reproduce the exact setup.

Just a quick reminder: the Construct Object component I’m using in Grasshopper is from Tekla Live Link. To run the definition as-is, you’ll need Tekla Structures installed and the Tekla Live Link plugin installed as well.

Thanks again for taking a look and for your time.

Jingzhou

Test.gh (11.3 KB)

alignment test.3dm (8.1 MB)

[sebastian.lindholm]

@Jingzhou

4) Questions

1. Does Tekla Live Link (Construct Object) rebuild / discretize / project the curve during import?
   For example, converting to a polyline with some chord tolerance, refitting, or projecting to a plane?
2. Why would GH’s Evaluate Length and Divide Distance produce different locations for the same “1000 m” distance on a single curve?
   What common causes should I check (PolyCurve segments, curve domain, tolerance, rebuild/refit, discontinuities, etc.)?
3. What’s the recommended workflow to ensure consistent length/chainage across Rhino/GH/Tekla?
   Examples: pre-convert to a high-resolution polyline in GH before import, enforce specific tolerances, unify unit settings, or transfer only chainage points and reconstruct the curve inside Tekla.

Hi Jingzhou,

Yes, because there’s no general mathematical curve type in Tekla, it will make any smooth curves into polylines (except pure arcs and circles). This means their length will usually be a little less than the mathematical curve. You can increase the number of control points to mitigate this somewhat:

Or then turn the curve into a polyline already in Grasshopper. As long as it doesn’t have more than the allowed number of control points it will be transferred as-is to Tekla.

Evaluate Length and Divide Distance are measuring different things, “Distance” gives the straight distance between points rather than the length along the curve. There’s a Divide Length that should give you the same result as the Evaluate Length.