Open CCS86 opened 9 months ago
Could you provide us with the original step file and stl file for analysis?
Thanks!
So, this is interesting... the translation issues may be on certain types of faces only. You can see here that the strict cylinder and torus/fillet look much better. But the other faces: cone, b-spline, etc, look really bad:
Here are these test models:
Hi, From the file you provided, it can be seen that the size of the step file is much smaller than that of the stl file, so the grid information of the step file is far less than that of the stl file. From the grid, it can also be seen that the grid of stl file is finer than that of step file.
Hi, From the file you provided, it can be seen that the size of the step file is much smaller than that of the stl file, so the grid information of the step file is far less than that of the stl file.
STEP files are not faceted, they are solid models, that is why there is a large difference in file size. Despite the smaller size, the STEP file contains more accurate information describing the model geometry.
I'm not sure what program you have opened the step file in, but those facets shown were created by that program.
You're right, the step file is a solid model, but 3D printing requires mesh data, so it needs to convert the solid into a triangular mesh. There are performance and accuracy requirements here. Currently, we are using the triangulation algorithm provided by the OCCT library, which may have some errors.
You're right, the step file is a solid model, but 3D printing requires mesh data, so it needs to convert the solid into a triangular mesh. There are performance and accuracy requirements here. Currently, we are using the triangulation algorithm provided by the OCCT library, which may have some errors.
Hmm, I wonder why STEP file support is touted as a significant feature, when it just converts to a mesh anyway with a buggy library.
You're right, the step file is a solid model, but 3D printing requires mesh data, so it needs to convert the solid into a triangular mesh. There are performance and accuracy requirements here. Currently, we are using the triangulation algorithm provided by the OCCT library, which may have some errors.
Slicing doesn't inherently require mesh data. What is required is one or more intersection between curve between the model and the slicing plane.
I think it very much depends on the resolution/precision of whatever is creating the mash from the model: be that the CAD software, or the slicer... many are finding that their cad software produces better mesh than their slicer, I have found the opposite (step = 132000 triangles vs stl = 54000) with onshape: the mesh from the slicer (i.e. importing a step file) is better quality than the fine mode from onshape (though you can use custom mode and get better results, but the files start to become quite large and the slicers have problems again...)
I for one am waiting for someone to make a move on rewriting a slicer to work directly on the model and not require (or convert to) a mesh... then the quantisation into linear stepper moves can be done much later (at higher resolution, in firmware)
the problem is much more complicated when you don't only have triangles though.
I think it very much depends on the resolution/precision of whatever is creating the mash from the model: be that the CAD software, or the slicer... many are finding that their cad software produces better mesh than their slicer, I have found the opposite (step = 132000 triangles vs stl = 54000) with onshape: the mesh from the slicer (i.e. importing a step file) is better quality than the fine mode from onshape (though you can use custom mode and get better results, but the files start to become quite large and the slicers have problems again...)
You are contradicting yourself here. The Onshape presets are obviously too coarse. So, the solution is to fine tune the custom export. Who cares if the file size is bigger? What problems does the slicer have with large STLs?
I’m talking about being slow to load, slow when moving models, slicing slower - though I do understand your point and agree that in the end (while the slicing is done on triangles only) then the mesh has to be just as big no matter how it gets into the slicer. I guess my issue here is that I guess I am like most people, I don’t really know what setting I should use to configure the mesh generation and I just want the tools to do the right thing easily. Would you say that the precision (wrt quality of mesh generated) likely goes: your cad software > slicer > onshape - so I see better mesh using slicer but you see worse? I’ll read up what the stl export options mean and try a better stl from onshape and see if anything changes in the rest of the pipeline to print quality.
I wasn’t disagreeing with the premise of this ticket, that the step file import needs to be configurable (or at least better).
I hope this gets fixed because I don't remember this being an issue in previous versions of BS and it's made working with smooth curvatures much more of a pain!
This issue has been marked as inactive due to no response for 90 days.
Bambu Studio Version
1.8.3
Where is the application from?
Bambu Lab github releases
OS version
Win 10 x64
Additional system information
No response
Printer
X1C
How to reproduce
Imported STEP files are actually a step down in quality from high quality STL.
Actual results
Here is a comparison between an inserted primitive cylinder, an imported STL and an imported STEP.
You can see that the STEP import has 44% fewer triangles, and even gets the dimensions wrong.
Expected results
Here is another example:
That same STEP file imported into Onshape looks great:
Until the slicing engine can be rewritten to run directly on a solid model, it may not be a big deal. It seems that currently the STEP files are being converted into a faceted model, but without any control over the tolerances used.
Project file & Debug log uploads
Cylinder.zip
Checklist of files to include