Shape missing from FC saved file

[easyw-fc]

I'm having an issue in loading some shape that I didn't have in FC 0.18
here my error log

Code: Select all

12:27:49  <Part> ViewProviderExt.cpp(1268): Cannot compute Inventor representation for the shape of shape_issue#Shape003: Geom_TrimmedCurve::U1 == U2

FC-0.21-issue.png (156.27 KiB) Viewed 1148 times

FC-0.18-no-issue.png (110.25 KiB) Viewed 1148 times

and the testing file (opening without issues in FC0.18)

shape-issue.FCStd

(8.32 KiB) Downloaded 19 times

what could I do to avoid that issue? (my shapes are python generated, but I didn't noticed this issue before)
could it be OCC related or FC related?

my FC full info

Code: Select all

OS: Windows 10 Version 1909
Word size of FreeCAD: 64-bit
Version: 0.21.0.31641 (Git)
Build type: Release
Branch: master
Hash: d28d63b87b60161419c6c0c532fbbfaed96926b8
Python 3.10.8, Qt 5.15.6, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3

Code: Select all

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.4 (GitTag)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: 980bf9060e28555fecd9e3462f68ca74007b70f8
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0

and the same issue on Linux

Code: Select all

OS: Linux Mint 20.3 (X-Cinnamon)
Word size of FreeCAD: 64-bit
Version: 0.20.1.29410 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.20.1)
Hash: f5d13554ecc7a456fb6e970568ae5c74ba727563
Python 3.10.5, Qt 5.15.4, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.2

[easyw-fc]

the strange part is that inside FC file there are two shapes... extracting those,
I have the same issue on FC 0.19,0.20,0.21 but I have no issue in FC 0.18.
Here the BRP shape file

PartShape1.brp

(26.49 KiB) Downloaded 17 times

[easyw-fc]

ok, it seems there is little interest on this, but imo this is a quite big issue...
I can generate shapes and render them correctly in FC, even export them correctly as step, but when I save that file, the next time I load it the shapes are simply disappeared...

Here a Fc file with 6 shapes in the tree, but only 4 present in the 3d viewer and a step exported file from the original FC file (before the saving and closing process) with all the 6 shapes fully present in the tree and 3d viewer.

shape-issue-test2.FCStd

(21.07 KiB) Downloaded 14 times

shape-issue-test2.step

(122.35 KiB) Downloaded 14 times

-

6shapes.png (409.92 KiB) Viewed 957 times

[chrisb]

ok, it seems there is little interest on this, but imo this is a quite big issue...

my shapes are python generated

What exactly has to be done to reproduce? Can you provide the python code?

[easyw-fc]

What exactly has to be done to reproduce? Can you provide the python code?

After installing KiCADStepUp WB it is possible to load KiCAD footprint in FreeCAD to check geometry constrains...

I'm attaching a file to test the issue and a small screencast.
From the screencast it is possible to see that the shapes are correctly generated and exported to STEP file. But if the user saves the FC file, when re-opening it the shapes will trig the error and display nothing in 3D viewer, even if they are present in tree view.
(Note that was not triggering any error in FC <= 0.18)
Loading file and generating shapes:

missing-shapes-1.gif (839.95 KiB) Viewed 851 times

Loading STEP file and FC file:

missing-shapes-2.gif (551.8 KiB) Viewed 851 times

and the file (zipped) to be loaded by StepUp WB:

[Syres]

could it be OCC related or FC related?

Based on using only OCC 7.3.0 for all testing and Git Bisecting, I've found this git commit 9e85160 to be the cause of the regression you are seeing.
I'll leave you to consult with Werner regarding a solution.

Code: Select all

OS: Linux Mint 20.3 (X-Cinnamon/cinnamon)
Word size of FreeCAD: 64-bit
Version: 0.20.26249 (Git)
Build type: Release
Branch: (no branch, bisect started on releases/FreeCAD-0-20)
Hash: 9e8516002b9ced0bada5064b2dc775d022adea73
Python version: 3.8.10
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)

[easyw-fc]

Based on using only OCC 7.3.0 for all testing and Git Bisecting, I've found this git commit 9e85160 to be the cause of the regression you are seeing.
I'll leave you to consult with Werner regarding a solution.

thanks a lot @Syres
I'm pinging Werner @wmayer

[Syres]

Just to add to findings above, I built the last good working git commit b488071 using OCC 7.6.3 instead of 7.3.0 as I was suspicious that there could be a different outcome and sure enough, no error is raised but the visual output is different:

OCC763DifftoOCC730.png (6.56 KiB) Viewed 647 times

[wmayer]

could it be OCC related or FC related?

The model has invalid geometries. Geom_TrimmedCurve::U1 == U2 means that you have a curve where the first and last parameter are identical so that the curve degenerates to a point.

I've found this git commit 9e85160 to be the cause of the regression you are seeing.

The fix should be simple. It has to be checked if the curve is degenerated and if so return with a null handle.

[wmayer]

It seems the issue is more tricky and I guess there also was a change in behaviour of OCC. Inside the function Part::Tools::triangulationOfFace a BRepAdaptor_Surface is used to get the parameter ranges and for one of the faces an exception is raised immediately. When adding a try/catch block around then this can be handled by returning a null handle.

However, as result you will get a rectangular face on the top and bottom. And if Part::Tools::triangulationOfFace is changed to

Code: Select all

Handle (Poly_Triangulation) Part::Tools::triangulationOfFace(const TopoDS_Face& face)
{
    TopLoc_Location loc;
    return BRep_Tool::Triangulation(face, loc);
}

then you will get the same result as Syres has shown in his last posting.