A topic that will be important later on.
No, this statement is generally incorrect, "the STL image of this would have a zillion-sided polygon."
Let me tell you why. The more points exported, the larger the STL file is. Yes, most CAD programs have settings that can change how fine the export detail is, and yes, they can be increased- but defaults are defaults for good reason and super high detail large file size is not typically default.
Now in and of itself, you might first say no big deal, what's so bad about a large STL file?
Well first, the slicing program (Ideamaker or any other slicer) has to import and then place and render (draw on the screen) that large massive high density point cloud known as an STL. Then any transformation (movement within the build space) while placing this on the build plate, any scaling, rotation, or dozens of other moves now has to manipulate all those data points in 3D.
So you say so what if the slicer is a little sluggish while trying to move the STL, I have a fast computer, fast graphics card, etc...
Then you export the gcode.
The problem at this step is again, gcode in current 3D printing format, there are no curves- only straight lines. Each line is a line of gcode.
You now potentially produce a massive 100mb or more gcode print file with millions of lines and every line has to be executed without mistake.
But wait, it's not even to the printer yet. Thats just making the gcode. Now you have to transfer it across the network to the printer.
The larger the file, the greater the chance that one tiny line of gcode is messed up.
Oh wait, we aren't even printing it yet.
Now you have to understand the architecture and limitation of the raise3d printer design. The MOTION board and firmware is what actually runs the printer. This is what interprets and reads line by line the gcode print file, plans the acceleration and deceleration moves, and then sends those pulses to the stepper drivers in perfected timed sequences to result in hopefully smooth motion. But the key is, how it gets that gcode line by line, over a serial data interface. Yes, serial data, like old school 1990s dial up modems- serial at a baud rate. The front panel LCD computer is what you transferred the file to, but it doesnt actually print the file, it streams it line by line over this serial data limitation between the 2 processor system. And yes, there is a limit and yes, beyond a shadow of doubt you can hit it, and when you do, your print stutters.
So yes, technically, these printers have a resolution limit that is almost never discussed and yes, it looks really ugly when you smack into this trying to solve other problems.
What I'm trying to get at is, someone or somewhere you look at reading and trying to solve your current problem might mention increasing resolution or segment count or some other setting detail from CAD in effort to reduce the effects of the polygon crossing into the desired center of a hole. Use caution, that can cause more problems than it solves.
Not to mention, if you own this printer, it's good to know what it can and cannot do.
Here is that topic and while it was related to brim, the facts are valid, there is an internal limit and it is testable, it can be hit, it's related to segmentation in a curve. https://forum.raise3d.com/viewtopic.php ... ter#p27232