By it's very nature, a 3D print originating from an STL file is going to sacrifice some resolution due to the meshing (or tessellation) process that converts the mathmatically precise CAD model into a triangle mesh. Here's an example of a sphere drawn in a CAD application and an example mesh (which is what is saved in an STL file):
|left: CAD sphere right: triangle mesh|
Take a look at the image below of a 20mm diameter sphere converted to five meshes, each with differing triangle counts. The CAD tool uses sophisticated math to calculate the geometry and display it. It looks like a perfect sphere on screen. The image shows five different resolutions from a low number of triangles to a high number of triangles (left to right).
|Effect of increasing triangle count (left to right)|
NOTE: When you download an STL file from Thingiverse or another sharing service, you have no control over the mesh count. The original author made the resolution choice for you and depending on their level of sophistication, the resulting mesh may not be optimal.
Back to the example - to take this one step further, imagine your slicer creating gcode from these meshed models. To demonstrate, I created an imaginary slicing plane at 12mm above the sphere's base that is .02 mm thick to represent a typical slicing layer. These are the red polygons circumscribing the meshes in the image above. I then projected these slices up above the models so you can see them more clearly (the black polygons "floating" above the meshes).
The 48 triangle model has a slice with 8 sides. It should be a perfect circle so this is a very low resolution slice. As you move left to right, each slice has more line segments to represent the circle. Higher segment counts to represent the circular cross section will result in a finer/higher resolution print all things being equal. But they are not! In addition to the slicer converting curves into short line segments, the firmware also imposes its own line segmentation on top of that - that is all of them except dc42 RepRapFirmware. dc42 draws each point along the way completely tracing the original path it was given within the resolution of the printer's mechanics. Smoothie, Repetier, Marlin and the others actually break the path up into short line segments and draw those. This does not always match the original path exactly.
As you can see, if the STL had a low triangle count, you are going to get a course print. Increasing the triangle count will improve the print quality until you reach the segmentation threshold of the firmware, at which point, increased # of triangles won't have an effect and might actually make things worse. That is except dc42, which will faithfully trace each of the tiny line segments exactly point by point.
To test if dc42's precise movement calculations have a positive effect, one would have to perform a side-by-side comparison using the same printer and filament, printing the same STL file (which was meshed with a high triangle count) once with a Smoothieboard running smoothieware and once with a Duet running dc42. I'm thinking about what the best test model should be to perform this test. If anyone has any suggestions or comments, please let me know.