Particular .STEP file does not slice properly in PrusaSlicer

[zwoop]

Description of the bug

I have a .step file as generated from Fusion, which does not render or slice properly. It's missing one part of the model. This renders properly in other software, such as eDrawings, and it also both renders and slices properly in BambuSlicer.

I'll try to attach the .step file as well.

Project file & How to reproduce

Load the .step file, and it will miss portions of the "foot" on one of the stands.

Checklist of files included above

• [x] Project file
• [x] Screenshot

Version of PrusaSlicer

2.8.0

Operating system

macOS 14.5

Printer model

Prusa XL, MK3 and MK4

[zwoop]

StepFail.tar.gz

[u89djt]

(Intrigued fellow user) I imported your step file into Fusion and re-exported that to step, and it loaded and sliced fine. Do you want to post a zipped f3d file from your original Fusion work for a fresh pair of eyes in case there's something quirky?

[zwoop]

(Intrigued fellow user) I imported your step file into Fusion and re-exported that to step, and it loaded and sliced fine. Do you want to post a zipped f3d file from your original Fusion work for a fresh pair of eyes in case there's something quirky?

Interesting. Did the .step file that I included here fail in Prusa Slicer though ? And yes, I can include the f3d file if anyone wants to take a look at it.

Fwiw, if I save the F360 as an STL (save mesh), PrusaSlicer handles it just fine, I'm pretty confident it's not a design issue. It's only the export to .step that PrusaSlicer (and only PrusaSlicer) has a problem with. It is possible that F360 is doing a "weird" export to STEP, but then why does it work in BambuSlicer (a fork of OrcaSlicer)?

[zwoop]

F3D file Spray Can 218x153 5.f3d.gz

[u89djt]

Yes, the step file you included failed in the slicer just like your screenshot. I can't see anything odd in your f3d file. When I export to step, that file fails the same way yours did. If I import that and re-export, it succeeds. So we seem to have the same Fusion export experience. It looks like Fusion is happy with some exact zeroes in its initial export from its own internal data, but when it comes in from a STEP file, it replaces some zeros with a small value. From the odd dig around in step files, that seems to be common. The file on the left is your orignal step file and on the right the re-export. I haven't dug into why this is or how it relates to the failed cone, but zeros are tough in many ways, so it guess it begins to be a plausible place to look. Anyhoo, you've got a workaround, I guess.

[u89djt]

Maybe they're taking a different approach to converting the step file to an internal mesh. How good do the curves look in the bambu slicer? https://github.com/bambulab/BambuStudio/issues/3437 I only have prusa slicer and cura installed right now. Just realising we've probably done the due dilligence. The original step file seems to be well-formed, so it's a bug. Here's the re-exported step file that the slicer imports successfully for the devs to work with: re-export Spray Can 218x153 5.zip

[zwoop]

It renders and prints fine in BambuStudio. Thanks for doing all the analysis, hopefully this helps whomever may want to take a look at the underlying code. My guess would be that the STEP conversion happens in a dependency library that PrusaSlicer uses?

I haven't honestly looked at any of the slicer code, so I don't know where the problems would be.

[u89djt]

Heh, you just replied as I was about to post this :) Further investigation: I don't want to assert that it's a bug. It's a shortcoming in comparison to the other slicer if you're happy with the quality of the surface[1] you get on the third clutch in that. Fusion inexplicably adds 10^-13 to the (common) y coordinates of the upper surface and upper circumference of the frustum that fails, but not to the frustum's lower surface's y coordinate. This is a diff between the exported step of the failed frustum and the middle frustum that succeeds: I'm working with the frustum in isolation with the lip deleted: The offset naturally causes the geometry to miss itself if you trust it completely. If I either delete both instances of 10^-13, or add 10^-13 to all the other appearances of the y coordinate, it succeeds in the slicer. Where the object succeeds in other circumstances, that suggests it's been refactored, or the mismatch has been ignored and the next steps worked anyway. Fusion shuffles things around, certainly. Where a mesh is the product, maybe you'd get something that looks a bit grungier[1] than the other two frustums where the disagreeing parts meet and errors have been relaxed across some iteratively-fit triangles. The fact that Fusion chooses to refactor the step data if you try to import it tells us that there's something contradictory between how Fusion represents/exports things and what it looks for in imports. Looking at the stls of the failure and fixedfailure exported from the slicer, it's confirmed that the failed conical face hasn't been rendered to triangles - there's no data for that face, just for the two discs. Files in stepfailandfix.zip: failure.step fixed.step failure.f3d both.3mf stepfailandfix.zip There's a whole world of options to do things differently in Fusion, but of course we ideally wouldn't have to, and it's not clear that it would inform development activity in the slicer. If anyone wants anything else out of this specific situation, I'm likely to be happy to grind it - I don't know where your priorities/entertainment preferences lie, @zwoop. I'm going to keep looking into how to avoid this kind of thing in Fusion. I'll look up the other step file issues that went past a while ago, too.

[zwoop]

Btw, note that the three cones are all patterns on a path in F360. Only the last one of the three in this model has the problem. I'm sure it's possible that Fusion is doing a bad export of the .step here, and if it hadn't been for the fact that other slicers, and viewers (such as eDrawings) renders it just fine, I would have blamed Fusion directly and not filed a Prusa issue :-).

Also, I should say that I've made many other STEP exports with other parameters (different sizes), different number of platforms etc., and this is the only one that renders poorly after exporting.

[u89djt]

Aye, it seems to be solidly down to Fusion doing something weird to the numbers that the slicer can't cope with - see the diff and description above - but the other software works round it. Also, Fusion decides not to cope with those weird numbers when it re-imports, so something among its representation and export processes is flawed as far as it itself is concerned. I guess I'm using 3DConnexion Viewer instead of eDrawing and that's apparently happy with it.

[zwoop]

On a side note, I've had some issues with a .STEP file (same design as this, but larger) where it gets one very slight layer shift. I'd suspect it'd be my Prusa XL, however, I tried the same .STEP file in two separate prints, where I rotated the model in the second print at a 45 degree angle. And the layer shift happened in exactly the same direction (at a 45 degree angle in the second test).

I'm testing the same model now, from an STL file, and where it did the layer shift before, it did not do so now. Not exactly scientifically valid, but I'm starting to suspect that the slicer may be causing something in the output gcode that causes the layer shift.

For now, I think I'll just go back to STL files for reliability (as I understand, under the hood PrusaSlicer will convert to STL first anyways?).

[zwoop]

Aye, it seems to be solidly down to Fusion doing something weird to the numbers that the slicer can't cope with - see the diff and description above - but the other software works round it. Also, Fusion decides not to cope with those weird numbers when it re-imports, so something among its representation and export processes is flawed as far as it itself is concerned. I guess I'm using 3DConnexion Viewer instead of eDrawing and that's apparently happy with it.

I re-read your analysis. If I were to guess, other slicers will round (or truncate) these values. Seems reasonable to round it to some number of decimals, say 2 or 3. I have no idea why Fusion would produce such values, but feels like it could be an easy fix in Slicer to round the input appropriate and consistently.

[u89djt]

Right, so if every vector value in the step file were parallel to X, Y or Z, then that might turn out OK. The object you've posted looks like it could be described that way except for the frustums. You'll see in your step file things like DIRECTION('ref_axis',(0.,0.707106781186547,-0.707106781186547)) for the 45 degree angle you've used (that's 1/sqrt(2)). As soon as you're removing meaningful digits from something that deals with angles off axes, even if they're things that look like they're made of equal offsets, you're setting yourself up to miss again. Truncation is similar in a sense to adding k*10^-something and you'll only get away with that when everything lines up nicely. Try it on your step file with a script and see what happens. Task for you if you want to close the loop: export an stl from bambu's import of the step file. Let's look at the surface it makes for the frustum on the third clutch.

[Jan-Soustruznik]

Hello, @zwoop , could you check with latest release of PrusaSlicer, link to release: https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.8.1-rc1 We enchancement importing of STEP/STP files.

similar issues: https://github.com/prusa3d/PrusaSlicer/issues/12271 / https://github.com/prusa3d/PrusaSlicer/issues/12122