Measuring diameters

[asp1972]

Is there an existing issue for this problem?

• I have searched the existing issues

OrcaSlicer Version

2.3.0-dev

Operating System (OS)

Windows

OS Version

Windows 10

Additional system information

No response

Printer

Bambu X1C

How to reproduce

1. Сreate a primitive cylinder.
2. Measure the diameter.
3. Get an unclear result
   

Actual results

Incorrect diameter measurement

Expected results

Сorrect diameter measurement.

p.s. In Bambustudio where did you get the measurement block, the diameter size is shown correctly

Project file & Debug log uploads

Cylinder.zip

Checklist of files to include

• Log file
• Project file

Anything else?

No response

[limited660]

Also seeing this on Windows 11, 2.3.0-dev build 658c4f0.

[LJKraus]

Ditto, Windows 11, 2.3.0-dev, build 06c809c. Works correctly in 2.2.0.
Affects measurements of all curves, tubes, etc.
Measures very thin discs correctly - 0.02mm height, 100 mm diameter.

Diameter error grows with height of the cylinder:
dia 100mm, height 10 mm, measures 162.432mm
dia 100mm, height 25 mm, measures 335.261mm
dia 100mm, height 50 mm, measures 647.765mm
dia 100mm, height 100mm, measures 1283.900mm

[kvikindi]

Similar issue seen here on linux mint debian, flatpak release 4d762c4, as well as Win 10 portable release f11eb34

edit
The flatpak version actually shows diameter value "0" for most cylinders, while the Win10 one seems to follow the weird pattern LJKraus has.

Still apparent in Windows (10) 2.3.0-beta build ae5d7ea
And the Linux Flatpak as well.

[LJKraus]

Still broken
Windows 11
2.3.0 - beta build 2bba98d

[kvikindi]

edit
I may be utterly wrong about this all, and the problem might even lie in /src/libslic3r/Measure... etc instead...
edit

Using my limited understanding of C++, with the help of Claude, and o3 mini, It seems that the culprit might be on line 123:

Vec2d TransformHelper::ndc_to_ss(const Vec3d &ndc, const std::array<int, 4> &viewport)
{
    const double half_w = 0.5 * double(viewport[2]);
    const double half_h = 0.5 * double(viewport[3]);
    return { half_w * ndc.x() + double(viewport[0]) + half_w, half_h * ndc.y() + double(viewport[1]) + half_h };
};

The implication here is that half_w is being added twice - once as part of the scaling (half_w * ndc.x()) and again at the end (+ half_w). This effectively doubles the transformation offset, leading to the consistent scaling factor you're seeing in the measurements (~11.5932x).

Vec2d TransformHelper::ndc_to_ss(const Vec3d &ndc, const std::array<int, 4> &viewport)
{
    const double half_w = 0.5 * double(viewport[2]);
    const double half_h = 0.5 * double(viewport[3]);
    // Remove the extra half_w/half_h offset at the end
    return { half_w * ndc.x() + double(viewport[0]), half_h * ndc.y() + double(viewport[1]) };
}

This modification should fix the scaling issue and return correct diameter measurements. The scaling factor of approximately 11.5932 that you're seeing is roughly 2π × 1.85, which suggests the extra offset was causing a geometric scaling effect in the measurement calculations.

Thus spoke AI.

I'd happily try and pummel through these code changes myself, but child minding and sleep deprivation is kicking in hard.