Missing Chamfers in STEP file

[SekA1448]

Description of the bug

Prusa slicer does not recognise all chamfers in STEP file.
Object has warning OPEN FACES detected.
Chamfers are present in 3DConnection (Spacemouse) viewer
3D file exported from FUSION 360
Exported STL file is OK in that regard

Best regards Aleksander

Project file & How to reproduce

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

Prusa slicer 2.7.1

Operating system

Windows 11

Printer model

Voron 2.4 350

[sarusani]

Your model has errors (hence the "warning OPEN FACES"), you need to repair it, after that the chamfers should be recognized correctly.

Click on the explanation mark on the object list (on the right). Or right-click the model and select "Fix by windows repair algorithm".

[neophyl]

This looks like the same problem as this one #12033
Just because a model can be rendered visually does not mean it can be correctly sliced.

[clfaye]

I can confirm that Prusa Slicer does not always treat chamfers correctly. Like the OP, I have a solid model from Fusion 360 that is water tight. No errors reported when I use the STL file. If I use the STEP file many (but not all - even though they are identical) of the chamfers are reported as open edges. The STEP file opens watertight with the Autodesk online STEP viewer, the Open Design Alliance STEP viewer, and the NIST STEP File Analyzer and Viewer.

main base project file.zip

[kubispe1]

There is a closed duplicate issue: #12271

[kubispe1]

SPE-2257

[lukasmatena]

Fixed in 2.8.1-rc1. Closing.

[adelton]

Hello @lukasmatena, I assume the fix in question is c6a0210, forcing the OCCT version back to 7.6.1. Do you have a link to where the underlying issue has been reported to OCCT? (I assume that SPE-2257 is some internal issue tracker of yours, not something consumable.)

[lukasmatena]

@adelton Hello. Yes, this was fixed by rolling OCCT version back (our official builds are statically linked). Last time I tried to report something to OCCT authors, I spend some time trying to submit it into their tracker, which forced me to do a registration and then didn't let me do it saying something about permissions or whatever. I tagged couple of people involved in the development and asked them to process it instead (#11305). AFAIK nothing happened. This time I did not bother.

[cryptomilk]

@lukasmatena Hey, I've just tested it. I'm able to create an account on their website, login to their bug tracker and report bugs to the "Community" project just fine.

If you don't report a bug, you can't expect that they know about it and and it is getting fixed. Please try again. Thank you!

Does PrusaSlicer accept bug reports reported only here or also on random other projects bug trackers? :-)

[adelton]

I tried to adapt the fix of using a bundled OCCT 7.6.1 in a Fedora build but I have hard time reproducing the fix. What is the canonical input / file / project which is just about the chamfers file and not about some other issues in the file? For example, the main base project file.3mf from #12122 (comment) has an orange triangle with exclamation mark in the UI, and only about half of the holes get shown in the sliced output even with OCCT 7.6.1.

Similarly, the idler-lever-b-r2.3mf from #12271 (comment) has that orange exclamation mark triangle and only one through hole is in the sliced output even with OCCT 7.6.1. And when I use the idler-lever-b-r2_fixed.stl from #12271 (comment), that one slices with two holes even with a build with Fedora's stock opencascade 7.8.1-3.fc41.x86_64 build.

So: was there ever a bug that got fixed with that downgrade to OCCT 7.6.1? Do we have a solid reproducer? If a model has that orange exclamation mark triangle, is that expected to be sliced with all the indicated holes?

[adelton]

I do see a difference with theSpray Can 218x153 5.step from #13138 (comment) where with a built using OCCT 7.6.1 has five cones and no orange exclamation mark triangle is shown, while with opencascade 7.8.1 it only has four and the orange exclamation mark triangle is shown.

Is that the reproducer and confirmation I'm after?

[adelton]

Of course another way to look at the situation would be: isn't it actually good that the new OCCT marks problematic inputs, rather than fixing or workarounding them? Granted, I did not dig into the details of what is going on there, it these are rounding issues or something else. But with some of the examples folks came up with fixed data. Isn't that the correct approach after all?

[cryptomilk]

From your explanations and also other comments in the bug. The issue is that we deal with broken step files and try to open them. In the past OCCT tired to magically fix those and with newer versions it shows proper errors?

[adelton]

I have no idea if those files are broken (out of specs, for whatever definition of specs), or just borderline (depending on things getting rounded or not rounded), or if something else is at play.

I did not dig into what those inputs do -- I don't think I have the skills to do that efficiently, and at the same time I probably don't care that much. :-) I was just hunting for a reproducer of what we are even dealing with here, to make a judgement call for a Fedora fix (https://bugzilla.redhat.com/show_bug.cgi?id=2333653, https://src.fedoraproject.org/rpms/prusa-slicer/pull-request/49).

[cryptomilk]

I can reproduce the issue with PrusaSlicer 2.8.1 and OCCT 7.8.1 and the Spray Can 218x153 5.step from StepFail.tar.gz.

FreeCAD also uses OCCT to import step files. I imported the Spray Can 218x153 5.step from StepFail.tar.gz in FreeCAD 1.0 and it opens and displays it correctly!

PrusaSlicer 2.8.1 and FreeCAD 1.0 on my system use both the same occt version 7.8.1. I would argue that it is a bug in PrusaSlicer.

[lockbox]

FWIW here is the FreeCAD commit where they added support for 2.8.1 OCCT: FreeCAD/FreeCAD@8abd093 to help speed up triaging a fix since this is going to continue to come up for people packaging prusa-slicer.