[Problem] AdditiveLoft generates invalid geometry (not an issue in mainline 0.21.2)

mh-dm commented 3 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Version

0.21 (Development)

Full version info

[code]
OS: Ubuntu 20.04.6 LTS (Unity:Unity7:ubuntu/unity)
Word size of FreeCAD: 64-bit
Version: 2024.409.0.14555 (Git shallow) AppImage
Build type: Release
Branch: (HEAD detached at 20240407stable)
Hash: 973e4821bcd19a5a1af9ae3e1d2ed961aad0a8ab
Python 3.11.6, Qt 5.15.8, Coin 4.0.1, Vtk 9.2.5, OCC 7.7.1
Locale: English/United Kingdom (en_GB)
[/code]

Subproject(s) affected?

PartDesign

Problem description

Here's a simple file using an additive loft that's supposed to result in a tube-like shape (remove .zip extension): broken-additive-loft.FCStd.zip

This is the invalid geometry: broken-addive-loft-geometry

The issue is more clearly seen in a slicer: broken-additive-loft

The two sketches used have at least 2 axes of symmetry so the expectation is that the the resulting additive loft geometry keeps said symmetry.

Anything else?

This issue does not happen if the AdditiveLoft is created in the latest mainline FreeCAD 0.21.2 release.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

realthunder commented 3 months ago

What version of mainline FreeCAD are you using. I tried the latest Linux AppImage release and it has the same problem.

mh-dm commented 3 months ago

Using this 0.21.2

OS: Ubuntu 20.04.6 LTS (Unity:Unity7:ubuntu/unity)
Word size of FreeCAD: 64-bit
Version: 0.21.2.33771 (Git)
Build type: Release
Branch: (HEAD detached at 0.21.2)
Hash: b9bfa5c5507506e4515816414cd27f4851d00489
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, Vtk 7.1.1, OCC 7.6.3
Locale: English/United Kingdom (en_GB)

To have it working you just have to reopen the file then delete the AdditiveLoft and recreate it. I'm attaching a working version: working-in-21.2-additive-loft.FCStd.zip

If you however open this file in Link version it will ask to recompute which will break the geometry.

mh-dm commented 3 months ago

The mainline 0.21.2 version I was using was from freecad stable PPA.

$ apt info freecad-python3
Package: freecad-python3
Version: 2:0.21.2+dfsg1~202403021917~ubuntu20.04.1

To make sure that wasn't a confounding factor, I've downloaded the latest mainline Linux AppImage release and tried it. The behaviour was exactly the same as the 0.21.2 from PPA. It just loads way slower because it's an AppImage and AppImage is bloated and slow. I'm a bit surprised that version info is identical

OS: Ubuntu 20.04.6 LTS (Unity:Unity7:ubuntu/unity)
Word size of FreeCAD: 64-bit
Version: 0.21.2.33771 (Git)
Build type: Release
Branch: (HEAD detached at 0.21.2)
Hash: b9bfa5c5507506e4515816414cd27f4851d00489
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, Vtk 7.1.1, OCC 7.6.3
Locale: English/United Kingdom (en_GB)

realthunder commented 3 months ago

This is most likely a problem of the newer OCCT 7.7. Lastest mainline FreeCAD 0.22 also uses this version which has the same problem. I'll try to find some workaround.

realthunder commented 3 months ago

Unfortunately, the problem cannot seem to be fixed on FreeCAD side, which is why I transferred the issue here. What you can do, other than wait for my next release of custom built, is to manually split the circle into four segments, same number as the rectangle. OCCT by right will try evenly split the profiles to make them equal in number. But a recent commit adds a condition to keep the split only if the resulting curve is longer than 0.1 of the original one. Before the commit, it is 0.01, much more reasonable IMO.

The below picture illustrates how OCCT auto split the curve. It draws a line from the center of the profile with more segments to each vertex and project it onto the other profile for intersection. The split is done in sequence, and the 0.1 condition is violated in the third split action, causing the unsymmetrical shape you posted.

1.