I am gearing up to print this project as soon as all of the parts make it in and I get my printer setup and calibrated. I have noticed, as many of you have as well I am sure, that the number of segments when generating circles and arcs in openscsd is relatively low resulting in a blicky design. (Don’t get me wrong, I like the overall look of the project). I would be interested to know if there was a way to adjust this globally when generating the STL’s? I did see that $fn you s set manually in several of the parts. Is this done for a reason? It would be great to have butter smooth curves.
The short answer is no.
I think that there is a default that you can set in OpenSCAD, but in most places as you say the $fn is set specifically in individual modules.
They way in which OpenSCAD generates solid geometries means that curves are always made from segments. This then makes it common to define triangular parts as cylinders with $fn=3, or hexagons for nut traps as 6-sided cylinders. For parts that are actually rounded in the microscope we also usually locally define the number is faces to get a balance between looks and the size of the STL file.
If you really want to try, use VSCode to open your local copy of the repository. It has a global search function that will find $fn in all files. Then you just need to work out which ones are curves, and which are deliberately polygons 
I don’t think a global change would work as, as @WilliamW says if $fn is used later thing this will take precedence.
While some of the $fn usage is, as William says, is to create polygons, some others are set for performance reasons. Probably the comments in the codebase could be improved to make this clearer.
Why some of the blockyness is my fault!
The other thing that happened which will affect how blocky/bumpy things look was the code base changed from v6 to v7.
In v6 we were using a more “traditional” way of using OpenSCAD with lots of global variables defined in one file, here a base level of $fn was set. As well as lots of other global variables. The issue with this method was it made it very difficult to customise and re-use certain elements of the design as everything was tied to global variables. Some models could only be generated from commandline with the -b option. The other problem was that there were hundreds of variables available to each function, these were often overwritten in different scopes making it very hard to avoid bugs.
To avoid this we used some of the newer features of OpenSCAD to create our own dictionary-type variable that could be used to send parameters through the code. This allowed us to stop using use to call in files, using include instead to avoid global variables. More information was written up as an Enhancement proposal as there were so many changes to the code base.
But what does this have to do with making things blocky!?
Well the answer to that is that over a couple of months, most of the codebase was heavily adjusted to remove the use of global variables. While it was easy-ish to track when normal global variables had changed, the different scoping of $fn was much harder to track. For such a large code base I concentrated on things functionally the same and cared much less about aesthetics.
Since then a number of things were obviously way to blocky and they have been improved. Other functional items added at a similar time, such as the cable management have also been improved as my original designs were quite spiky.
What to do?
You can go through and try to find a few parameters and improve them for your microscope. There is certainly a trade off between smoothness and OpenSCAD taking forever to compile.
Even better (for us), would be to take screenshots of areas you think could look prettier and open an issue on GitLab asking us to consider changing them. Though it might be some time before anyone is able to do the improvements.
If you are able to, you could share also share any code for aesthetic improvements back to the project on GitLab as a merge request to improve the microscope for everyone. I assume there will be some delay on merging changes into the code base right now as the core team prepares for the big v7 release. As we recompile the renders for the documentation with each change, we have to be somewhat careful about changes that significantly slow down the build process.
1 Like