Caution! - STL Resolution
-
Hello.
I've spent an age trying to resolve vertical artefacts in my prints. Firstly for clarity there were numerous tweaks that I made to my machine and settings to help address these. After a couple of late nights it occurred to me that the vertical artefacts were at the same spacing as the tessellation on my mesh file that the slicer was processing. Smoothing the mesh file resulted in a massive improvement.
The issue that I was struggling with was the vertex edge effects were different around the circumference of the test part. I had expected to be able to get the facet definition on the part a bit better, and consistent but I think this is asking too much from the machine in it's current state - or at least more than the free time I have left to chasing the issue.
For FreeCAD users you have far tighter control on mesh creation if you make the mesh in the mesh output workbench rather than just using the export option on a body. The angle of deviation control is probably one that will have a direct effect on the effective use of instant speed to smooth the head motion.
Above parts printed at 0.2mm layers with 0.4mm nozzle, and 0.48mm track width. Potentially a slight over extrusion, but otherwise fine for me!
Edit for clarity: Some improvements between the two parts resulted from slight changes to the z-axis. Not all down to STL resolution.
-
Oh I hate those artifacts. Big pet peeve of mine. I spent a week trying to figure out what was wrong with my printer. It drove me to fix a few issues with belts and the z axis, but I couldn't ever solve it, until it dawned on me.
It always bugs me when I see STLs with very low resolution, or when I see people say to export to STL with very low resolution because the common wisdom is that printers will just choke on the detail anyway. This isn't 2010 anymore. Printers are capable of very fine detail now compared to a few years ago and 32bit controllers have no problem with a high detail STL with lots of segments.
Since STL is a destructive format it should be presented with as high a quality as possible. Let the end user decimate if need be. Those files will exist on the internet for decades potentially. Who knows what kind of printer someone will try to use with it in the future. Resin printers are already capable of extremely high detail. It's also not uncommon to enlarge a model for printing it at 4x normal size or more. All those "curves" on the normal size model turn into huge flat facets when blown up.
STL isn't a great format to begin with but it can hold a lot of detail, file size be damned.
-
@Phaedrux Your arguments are the reason why I prefer taking things from thingiverse in OpenScad or other CAD data and try to ignore objects which are in STL format only. Most objects are not so complex to argument for intel property protection and using the original format helps to learn the program for own object creation.
If there are STL-only models in thingiverse without a Make, I avoid it, because in case of faulty models, it becomes difficult to repair them. It would be better to have the original format then. -
What was weird was that it wasn't showing up the full detail of the triangle, just these vertical features.
As it happens these were things I did the CAD work for and the file on the left shows the default settings for FreeCAD when you 'export as' STL (other triangular mesh file formats are available which are more robust, but same resolution issues!) straight from the Part Design workbench shape / body. To create the mash on the left I created a mesh in the mesh workbench to settings a tenth of the original and the Exported the mesh as an STL file.
It's just time for me to stomach longer gcode upload times!
-
As anyone tried to print any large diameter cylindrical objects? Like say in excess of 300 mm diameter? When I've tried in the past, they always come out faceted regardless of what I set the resolution to in OpenScad. So I can set the segment size to say 0.5mm which takes forever to render and makes a huge STL file. But when I import that STL into Slic3R, it seems to discard much of what is in the stl and "do it's own thing" with segment sizes. In the past, I've tried a simple hollow cylinder then changing the segment size in OpenScad to a number of different sizes, then rendering and saving those stl files which obviously results in a number of different sized stl files. But I can then import them all one at a time into Slic3R, slice the object and end up with a number of gcode files which are all the same size. Maybe it's a "Slic3R thing". I've found a setting to reduce the resolution but nothing to increase it.
-
Could Slic3R have a minimum feature or simplification function to avoid generating "too much" g-code?
I only use Fusion and S3D/Cura (or even UpStudio occationally), and limited to 120mm^2 on the printer but no problems making round things round enough to not have noticeable facets.
-
@bearer said in Caution! - STL Resolution:
Could Slic3R have a minimum feature or simplification function to avoid generating "too much" g-code?
It does but I have it turned off.
-
I was also having issues with stl files. Firstley when I exported them from Solidworks I always maxed out the resolution which made for some pretty big file sizes, but really helped with the print rez. That is also the second was the file sizes were getting crazy big. I am now exporting my diles in .3mf format and I could not be happier. The file sizes are manageable and the print resolution for me is just as good if not better. If you have not trued out a .3mf file I would suggest you do. I sliced the same part in both formats and same print settings and the .3mf format still printed a better quality than the STL
-
The flip side of this on Thingieverse: https://www.thingiverse.com/search?q=low+poly
And my extreme take on it:
https://www.thingiverse.com/thing:2964528Sometimes I like the effect of low poly counts, but mostly it's a pita, as @deckingman says; it can be hard to get rid of them at big sizes. I do the occasional 250+mm diameter vases on my delta and need to look out for this, another area where Octoprint's gcode viewer comes in handy for seeing 'what you will axctually get' vs the preview in the slicer.
-
There is certinally an art to good gcode. I've parsed some and found tones of sub mocron vectors which proportionally made the duet in to an expense delete key when the printed to ignored proportion of the file was considered!
Arc interpolation looks an interesting feature on Marlin, discussed in a tweet that the Duet3D account liked. Have we already got that or not?
-
It would of course result in yet another tunable feature!
-
@DocTrucker said in Caution! - STL Resolution:
Have we already got that or not?
https://duet3d.dozuki.com/Wiki/Gcode#Section_G2_G3_Controlled_Arc_Move
Whether any slicers are prepared to support it is a different matter. It's better suited to slicing from model files (Scad, etc) rather than from polygon based STL's where some, err, extrapolation would be required. Given how most slicers can get confused by straight edges I'm not optimistic they could extrapolate curves from polygons correctly
But.. Very handy for CNC users; though working out the maths has had me sitting with a pencil, a piece of paper, a calculator and a cold sweat.
-
Surprised G2/G3 doesn't have a Z input; would make it great for vase prints. I'd think it would then be relatively easy to parse a vase gcode file to convert G1 moves and remove stl artefacts: from a given point, use the next G1 move as the intermediate point, and the subsequent point as the end point of the arc. Would have to parse for G2/G3 clockwise or anticlockwise moves.
Edit: doesn't quite work as above, but easy to calculate centre of circle from three points.
Ian
-
@droftarts said in Caution! - STL Resolution:
Surprised G2/G3 doesn't have a Z input.
This is a whole topic in itself... Not a common CNC feature at all. On GRBL you get some planar support (pick any two axes, eg XZ, but not three).
Some controllers even implement a helix mode.. but no standards exist. My go-to reference bookmark for M2/3 is here: https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/
-
@droftarts said in Caution! - STL Resolution:
Surprised G2/G3 doesn't have a Z input; would make it great for vase prints.
It does, at least in RRF.
-
As far as I understand it arc interpolation on Marlin is a look ahead on the gcode that recognises a sequence of short vectors with constant angle change as an arc, and path plans based on that rather than forcing the path of the vectors.
-
@DocTrucker said in Caution! - STL Resolution:
path plans based on that rather than forcing the path of the vectors.
Ah! now that is different from G2/3; and sounds far more promising for smoothing objects. Thanks for explaining so succinctly.
-
@EasyTarget said in Caution! - STL Resolution:
And my extreme take on it:
https://www.thingiverse.com/thing:2964528