[Problem] Shape generation randomly broken on a complex body

[lukash]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

In a complex project with multiple documents depending on each other, and on a rather complex body, I'm getting recurrent corruptions in the generated shape. I am very certain they're not caused by errors in the input data (user errors). This object is all sketches and Part Design features, all sketches well defined and fully constrained. No pipes wrapping on themselves etc.

The project is unfortunately private, but I can share it with a dev together with a precise list of steps to reproduce, and I can be of any assistance that's required. I've already shared my project with @bgbsww, who has spent a lot of time looking into it, so far with no luck, but together we've ruled out all the simple potential causes.

The corruption changes when e.g. the order of objects in the body changes, and sometimes it would appear to be fixed. Strangely, even on a recompute the error would appear to be fixed, but when (for example) a spreadsheet with shared dimensions is marked for recompute and the body recomputed, the corruption would come back. All my attempts to work around this so far have been futile and I'm completely stuck working on the project until this is fixed - this is barring some radical attempts to change the body hierarchy that could possibly help and I haven't tried yet.

I tried to simplify the reproducer to be able to make it public, but the issue was the corruption seemed to be there until a very simple case, but then some random "marking for recompute" and "recompute" made it go away, making it hard to do this (there are a ton of references etc.). AFAIK @bgbsww was also so far unable to create a public reproducer.

I know this is not much to go by, but it seems to be a really nasty corruption and it'd be really great to have it fixed.

FWIW the corruption doesn't happen with @realthunder's https://github.com/realthunder/FreeCAD/releases/tag/20240123stable, at least not apparently, though I haven't spent much time with it, as there seems to be no guarantee of format compatibility (that I know of).

There's more info in the linked forum thread, but to pick a few screenshots:

Correct shape:

An interesting case, where even a sketch would get messed up by just reordering the object (the sketch is not like this for real and I haven't even edited it).

When clicking "recompute" on the sketch, it'd fix itself (I have automatic recomputes turned off), but the object would remain broken:

Full version info

[code]
OS: NixOS 23.11 (Tapir) (none+awesome/none+awesome)
Word size of FreeCAD: 64-bit
Version: 0.21.2.Unknown
Build type: Release
Python 3.11.6, Qt 5.15.11, Coin 4.0.1, Vtk 9.2.6, OCC 7.6.2
Locale: English/United States (en_US)
Installed mods: 
  * Curves 0.6.5
  * Render 2023.1.0
  * Assembly4 0.50.6
[/code]

Subproject(s) affected?

None

Anything else?

https://forum.freecad.org/viewtopic.php?t=84002

Code of Conduct

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

[luzpaz]

Per this forum post, this is TNP related.

[lukash]

Per this forum post, this is TNP related.

Until someone actually proves that, I maintain it is not.

1. There are no TNP dependencies in my model, everything is parametrically positioned.
2. If it was TNP, I could go and fix the broken name references. Due to 1., I have nothing to fix.

[FlachyJoe]

Can you please share the dependency graph (Tools, Dependency Graph and then print to PDF) ?

EDIT: or Tools, Export Dependency Graph

[lukash]

@FlachyJoe not sure this is gonna be of any use:
depgraph.pdf
depgraph.zip

[FlachyJoe]

@lukash On which feature is the error? Can you extract the defective part from the document in order to have a smaller graph?

Off-topic:
How long takes your model to recompute? Your spreadsheet graph is quite populated 🧑‍🤝‍🧑

[lukash]

@FlachyJoe the error is on the "controller box" body, around the "cb motor conn hole pocket", "cb cable channel top pocket" and "cb cable channel roundover" objects.

I can try to reduce the model if someone is actually going to have a serious look at this. I'm quite tired of trying to provide all the information only to be waved off blaming it on a model error, TNP or whatever else.

I don't normally recompute the whole thing, I have auto recomputes off and manually recompute the parts I work on. If it's a bigger part, it takes dozens of seconds, maybe a couple of minutes, on a 14 inch laptop.

[lukash]

So, I've picked the work back up on this project and I'm slowly managing to live with this issue.

What I've done to start with is create a new body and one by one copy-paste the broken body sketches, and then re-creating the body objects with them. This worked for a while with no problem, then the same issue came back.

The corruption always seems to happen around the same areas, it seems to be related to lofts of somewhat complex sketches that contain both circular and straight lines, and when there's more than one of those stacked right next to each other. But the area with most corruptions is not that (it's just pockets, again, some circles and lines in the sketches).

I've found out when I arrange the problematic body objects at the end, it tends to help make the issue disappear for a while.

But most importantly, I've found that when I expand all body objects to expose the sketches, then shift-select all the body contents (including sketches), right click and Mark to recompute, then recompute the body, it makes the corruption go away. I think it hasn't been helping always, but it has worked the last three times it came back. I also find this to be a strong case in point this is not a TNP issue.

[realthunder]

FreeCAD has this assumption that OCC treats input shapes as constant and not modify it when creating new shapes. But unfortunately it is not the case, because they have this BRepAlgoAPI_BuilderAlgo::SetNonDestructive() that by default is not enabled. This affects all boolean operations and maybe more. The problem reported here may very likely be the victim of this gotcha. The document states that OCC may modify sub-shape of the input, which implies that it may affect FreeCAD object many steps ahead in history that first produce the sub-shape.

In my branch, there is only one entry to call the OCC boolean operation, which is through TopoShape::makEBoolean(), so it is easy to fix. For upstream, it is a lot harder, as the calls are spread all over the place.

[FlachyJoe]

@lukash

even a sketch would get messed up by just reordering the object

don't you face a sketch geometry flip? In some cases a sketch can have multiple solutions but the solver still converge and display the fully constrained message. You can fix this by changing some relations (horizontal and perpendicular instead of horizontal and vertical for example). Can you share a view of this sketch?

[lukash]

@FlachyJoe That's not that unlikely, though staring at the sketch I don't see how it would happen... This would be the likely culprit if it was the case: