[Regression] PartDesign: Additive Loft tool does not work (v1.1.0dev 38728 Windows 11)

[terjenauf]

Is there an existing issue for this?

• [X] I have searched the existing issues

Problem description

Sorry if this is reported already. I did not find any searching it. Just found some with "BRep_API: command not done". I did not get an error like that.

I have made a simple drawing with a sketch on the XY plane, made two datumn-planes on XY axis with offset in Z axis of 40 and 80mm and made a square sketch on each of the datumn planes.

When I try to use the additive loft tool it wont do anything, and the report view tells me that "AdditiveLoft: Loft: At least one section is needed.

Using the same drawing in 0.21.2 - 33771 works fine.

Full version info

OS: Windows 11 build 22631
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38728 (Git)
Build type: Release
Branch: main
Hash: 9de78e27f4148e8032594788a9804486e769388b
Python 3.11.9, Qt 5.15.13, Coin 4.0.2, Vtk 9.2.6, OCC 7.7.2
Locale: Norwegian Bokmal/Norway (nb_NO)
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default
Installed mods: 
  * 3D_Printing_Tools
  * A2plus 0.4.67
  * btl 0.9.9
  * ExplodedAssembly
  * fasteners 0.5.29
  * frame 0.1.1
  * freecad.gears 1.2.0
  * Gridfinity 0.6.0
  * parts_library
  * Render 2024.8.4
  * Reporting
  * sheetmetal 0.4.25
  * symbols_library
  * woodworking 0.21.2.33771

Subproject(s) affected?

PartDesign

Anything else?

Code of Conduct

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

[Roy-043]

Seems to work fine here. Please post your file. pd-additive-loft.FCStd.zip (remove the zip extension)

OS: Windows 8 build 9600
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38728 (Git)
Build type: Release
Branch: main
Hash: 9de78e27f4148e8032594788a9804486e769388b
Python 3.11.9, Qt 5.15.13, Coin 4.0.2, Vtk 9.2.6, OCC 7.7.2
Locale: C/Default (C) [ OS: Dutch/Netherlands (nl_NL) ]
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default
Installed mods:

[terjenauf]

Thanks for your reply. I had already continued the work on the file in 0.21.2, so I do not have the exact file from my report. However, I tried to recreate it. This time I go/saw the "BRep_API:command not done" error. I believe this already is a reported issue, and this issue should maybe be closed?

vase.FCStd.zip

[evanmac03]

Hello, I am having an issue with the Additive Loft in FreeCAD 1.0.0RC1.38642.

I trying to make a loft from one larger square to another square.

I am following this video

https://www.youtube.com/watch?v=Px1bkazmFH8&list=PL_28gc6LBA1ve8Aamf1izQjNlqgtBWoLS&index=9

Here are the current steps I am using:

1. Create one square in sketcher
2. Call it "FirstSketch"
3. Fully constrain it
4. Create another smaller square in sketcher
5. Call it "SecondSketch"
6. Fully constrain it
7. Select the larger square first, called 'FirstSketch'
8. Push "Additive Loft" button
9. In the Tasks tab in the 'Loft parameters' section, click the 'Add Section'
10. Select the smaller square called 'SecondSketch'

The loft doesn't appear and I am get the error "Additive Loft: At least one section is needed"

OS: Windows 11 build 22621 Word size of FreeCAD: 64-bit Version: 1.0.0RC1.38642 (Git) Build type: Release Branch: (HEAD detached at 1.0rc1) Hash: 60a251354e203bdb924e2190fb9f5e18b48d7362 Python 3.11.9, Qt 5.15.13, Coin 4.0.2, Vtk 9.2.6, OCC 7.7.2 Locale: English/Canada (en_CA)

LoftAndSweeps1.FCStd.zip

[terjenauf]

Hello, I am having an issue with the Additive Loft in FreeCAD 1.0.0RC1.38642.

I trying to make a loft from one larger square to another square.

I am following this video

https://www.youtube.com/watch?v=Px1bkazmFH8&list=PL_28gc6LBA1ve8Aamf1izQjNlqgtBWoLS&index=9

Here are the current steps I am using:

1. Create one square in sketcher
2. Call it "FirstSketch"
3. Fully constrain it
4. Create another smaller square in sketcher
5. Call it "SecondSketch"
6. Fully constrain it
7. Select the larger square first, called 'FirstSketch'
8. Push "Additive Loft" button
9. In the Tasks tab in the 'Loft parameters' section, click the 'Add Section'
10. Select the smaller square called 'SecondSketch'

The loft doesn't appear and I am get the error "Additive Loft: At least one section is needed"

OS: Windows 11 build 22621 Word size of FreeCAD: 64-bit Version: 1.0.0RC1.38642 (Git) Build type: Release Branch: (HEAD detached at 1.0rc1) Hash: 60a2513 Python 3.11.9, Qt 5.15.13, Coin 4.0.2, Vtk 9.2.6, OCC 7.7.2 Locale: English/Canada (en_CA)

LoftAndSweeps1.FCStd.zip

I tried the same with your drawing, and got the same error. However if I choose both sketches first (select one, and Ctrl+click the next), and then pressing the adaptive loft it works.

[Roy-043]

I can confirm as well. This is a regression.

[luzpaz]

Blocker ?

[AIRCAP]

I just tried this on

OS: Ubuntu 20.04.6 LTS (XFCE/xfce)
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38830 (Git)
Build type: Debug
Branch: main
Hash: b38c42262f58cf0587b627e7a866d3756da34dc4
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, Vtk 7.1.1, OCC 7.6.3
Locale: English/United States (en_US)
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default

I can reproduce the issue but I get a different error message: "Input error: Sections must all be closed or all open"

Although in the Loft Edit dialog it shows "SecondSketch" as the "section" - this is not whats happening under the hood, as apparent from the Model->Data tab: The Section selected is actually only the actual edge the user clicked on - not the whole sketch!!!

Since a single edge does not make a closed surface, the loft correctly fails.

However the issue is that the Edit dialog a) does not indicate that only 1 edge is selected b) also does not give the ability to select a second edge (Clicking "Add Section" and then clicking a different edge of the sketch doesn't actually do anything - I assume because the same sketch is already listed in the sections)

[AIRCAP]

In

OS: Ubuntu 20.04.6 LTS (XFCE/xfce)
Word size of FreeCAD: 64-bit
Version: 1.0.0RC1.38642 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 1.0rc1)
Hash: 60a251354e203bdb924e2190fb9f5e18b48d7362
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Locale: English/United States (en_US)

The exact samre thing happens with one difference, the error message says "AdditiveLoft: BRep_API: command not done"

however under the hood the same issue happens - an edge is selected instead of the whole loft sketch.

[AIRCAP]

Btw in

OS: Ubuntu 20.04.6 LTS (XFCE/xfce)
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 States (en_US)

the whole sketch gets selected instead of a single edge, thus this doesn't happen.

[AIRCAP]

This is an interesting one. git bisect says the regression started with

git bisect good
9bc5675ab3e731ad160ab5adf80dbc9dda6f88d7 is the first bad commit
commit 9bc5675ab3e731ad160ab5adf80dbc9dda6f88d7
Author: Chris Hennes <chennes@pioneerlibrarysystem.org>
Date:   Tue Apr 30 16:19:21 2024 -0500

    Correct flag

 cMake/FreeCAD_Helpers/SetGlobalCompilerAndLinkerSettings.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@bgbsww I found a curious one. Why is this regression caused by adding linker flag?

this also means that the regression was set in stone by ecf7e51ab3138643f23c4f2969bd3773d863c4e7 Toponaming: Remove all FC_USE_TNP_FIX protected old code

so mabye the better question is - why was it working before... and what other regressions may this have caused?

[bgbsww]

The flag just enabled the toggle from old to TNP code, and we left that all in place for many months to address any errors that occurred. We then did the removal in advance of the RC builds and releases.

So, next step here is to look at the loft code, and then maybe at the select code for places where the #if[n]def FC_USE_TNP_FIX flag offered two code paths ( in any pre https://github.com/FreeCAD/FreeCAD/commit/ecf7e51ab3138643f23c4f2969bd3773d863c4e7 version of the source code ) to see what changed.

Context: This is all part of the very major code transfer of TopoNamingProblem mitigation code from the forked codebase at https://github.com/realthunder/FreeCAD which was a massive, many month and many PR effort.

Most but not all cases of regressions based on that have been dealt with. Unfortunately, both code bases evolved independently for many years before the transfer was finally attempted, and so every location required scrutiny.

This is one where it was missed.

[AIRCAP]

OK I looked into it a bit more. It looks like there were no changes to the view provider / GUI for Lofts - Rather to the lofts themselves. The "old" lofts - before 9bc5675ab3e731ad160ab5adf80dbc9dda6f88d7 - were "smart" in the regard even if the second shape was a single vertex or edge, the loft would extend to the entire surface it is part of. therefore it is sufficient if in the GUI a single wire is selected.

The new Loft code that is enabled by FC_USE_TNP_FIX does not have this automagic smartness - it takes the object selected by the Loft sections literally - and if that's just a single wire instead of the entire sketch, then the loft will fail.

Now this doesn't matter if the loft is created via macro or by first selecting all shapes in the tree or GUI and then creating the loft -- but it does matter when using the Task GUI - which only selects the very edge selected - hides this from the user - and relies on the loft execute() code to be smart enough to handle that - which the new code is not.

having a look at fa8f29aed489247e931631dbd1e600cc7610c38f specifically src/Mod/PartDesign/App/FeatureLoft.cpp - this is more or less a complete reimplementation of the Lofts with not too much in common between the two code bases (git diff has a hard time even finding corresponding lines)

This rises the big question how to fix this

Option 1: make FeatureLoft great again (aka give it back its automagic smartness of guessing if the selected shape should actually be the parent of the selected shape)

Option 2: make the GUI smarter and have it select entire shapes/sketches instead of individual wires/vertices -- and stop hiding information from the user.

From personal gut feeling, I am heavily leaning towards Option 2 - since base features should be explicit and not have implicit magic (aka unexpected side effects), while user interfaces should have all the implicit magic - but this is effectively an architecture decision. On the other hand, backwards compatibility might be desirable, which would mean Option 1 should be chosen (for the rare cases where the individual edge is actually stored in the doc tree and the loft works anyway)

[AIRCAP]

bad news - this is a LOT WORSE

in 1,0 rc1 or any other recent FC version, old files with lofts that were created withj the Task GUI are actually broken

they display ok at first glance (on restore) but break on document recompute. the issue is that in the task tree in Loft.Sections, indeed the individual selected Edge is stored, not the shape.

this means this worse case for backwards compatibility is actually the norm

and that means Option2 is not an option :(

@bgbsww ping - I guess that means this bug is actually a blocker?

[bgbsww]

Well, that saved me making the argument for Option 1. Which is basically that we have to fix the regressions, and then we can consider the new capabilities.

Please note that while I'm pretty experienced with this codebase, I am not an old hand and I do not speak for the project - I'd merely an educated opinion and an active developer.

We need to restore the auto magic smartness. If you've already tracked it down, maybe you can propose the change?

And yeah, that makes this a blocker in my view, but I don't control such things - just make recommendations.

I should note that performing option 1 doesn't preclude option 2, right? It's just there's less reason to do it.

[AIRCAP]

fun fact - both old and new code allow making a loft between a face/multiple wires and a single vertex (loft gets pyramid shaped) and this works when either the base shape is a single vertex and the section is a face - or the base shape is a face and the section is a vertex -- the old (pre 0.22) code will also try to make a loft when both base shape and section are a single vertex -- and promptly SEGFAULT ;)

in other words, both code bases already have quite a bit of implicit smarts implemented and do a lot of case-ing depending the nature of the selected things for base and segments -- the old code has more smarts - and as a result more bugs...

[bgbsww]

"Bug? That's not a bug, it's a feature!!" (ducks to avoid the dopeslap)

Thank you for your work here.

[AIRCAP]

now I have to nitpick - I guess the correct behaviour for a loft between 2 vertices is to make a wire between them, isn't it? but then again then it should also be possible to "loft" a face between 2 individual wires... i don#t think there currently is a way in the partdesign workbench to do that...

btw current main segfaults when multiple sketches are GUI selected with ctrl+click lemme see if there's already an issue for that

[bgbsww]

That's thinking, not nitpicking! Keep going, but recognize the difference between bugfixes ( fast approval, especially if a blocker relevant to 1.0 or a regression or a crash ) and new feature implementation ( slower approval, sometimes a call for discussion, sometimes there's a history of why it is the way it is ).

I think you're right here, but keep the bugfixes and features separate for faster responses.

[420noscope-exe]

In

OS: Ubuntu 20.04.6 LTS (XFCE/xfce)
Word size of FreeCAD: 64-bit
Version: 1.0.0RC1.38642 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 1.0rc1)
Hash: 60a251354e203bdb924e2190fb9f5e18b48d7362
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Locale: English/United States (en_US)

The exact samre thing happens with one difference, the error message says "AdditiveLoft: BRep_API: command not done"

however under the hood the same issue happens - an edge is selected instead of the whole ~loft~ sketch.

It is most definitely just selecting an edge under the hood instead of the whole sketch. Instead of selecting the sections by clicking on the edge, I first selected the first rectangular sketch in the Tasks Panel, then ctrl+clicked the second sketch in that same panel, and then I finally clicked additive loft. This ensured that the whole sketches were being used instead of an edge, and seems to work as it should. This is the workaround.

Before, I saw nothing when "Update View" was checked, had the same errors in the console 14:56:27 AdditiveLoft: Loft: At least one section is needed, and also got the BRep_API:command not done error pop-up.