Is inconsistent vertex density a bad thing?

Question

Will an inconsistent vertex density likely introduce artifacts in a print? Or is it OK as long as it's a smooth surface?

Answer 1

For the most part, the exact level of vertex density doesn't matter too much. But it does depend on the slicer and settings. Some slicers (like Slic3r) will auto-decimate toolpaths to ensure that the rate of motion commands isn't too difficult for the old, slow 8bit processors in most consumer/hobbyist 3d printers. Having a large number of very small motion commands can bog down these motion controllers and cause pause-stuttering that creates little zits on the print. Most slicers simply reduce model detail level to safeguard the motion controller. Because the contours are decimated to a minimum motion segment length, very small model triangles are irrelevant to printer performance. At the most, they might add a marginal amount of slicing time.

On the other hand, some slicers (like Simplify3d) assume you have the correct level of detail you want in your model, and will pretty faithfully reproduce the model file's contours in the sliced toolpath. If your entire model is very high mesh density / poly count in general, or if your high-density mesh regions are crossed by a layer slice, this can produce a series of very, very short motion commands. Sometimes the motion commands are even smaller than the motion resolution of the printer, and simply take up processor time (to evaluate and drop from the queue) with no benefit to print fidelity.

In a more general sense, high-poly models are dramatically more difficult for the 3d printer to reproduce accurately. There are two big issues:

• Each motion segment requires some processor time to read/receive, parse, and execute. But the shorter the segment lengths are, the faster the printer runs through them. A short move takes little time to perform but still has the same processor load as a long move. At a certain point, the processor can't keep up, and performance suffers. The printer may run out of queued moves to execute and pause in place, or it may violate acceleration limits and violently clunk through corners (or even lose position) because it didn't have enough time to iterate through the calculations that determine how fast it should move.
• The algorithms used by most consumer/hobbyist 3d printer firmwares (Marlin, Repetier, Sailfish, Smoothieware, etc) are based on GRBL. And without getting into the math, GRBL uses the sharpness of the corners between motion segments to decide how fast to travel through the corner. So a 90 degree turn will trigger a considerable slowdown, while a series of small angles (such as many small segments comprising a curved surface) is not recognized by the algorithm, and it will try to barrel through the curve at full speed. On long, gentle curves, this is fine, but high-poly tight curves (such as a filleted edge or organic model detail) are traversed far too fast because no slowdowns are triggered. This means high-poly models must be printed at much lower feedrates / target speeds, because the acceleration algorithm can't figure out when to go fast or slow. Whereas a blocky, low-poly model can be printed much faster and the acceleration code will speed up and slow down as needed for good quality.

These are primarily issues with high vertex density versus low vertex density, not variable density. Small pockets of high detail are usually not problematic, as long as they are small enough that the motion planner queue (say, 16 segments) doesn't get filled with too many very small movements. A few small segments in a row is ok, but a few dozen is not.

These are limitations baked into the algorithms used by today's slicers and motion controllers. In the future, they may not be so problematic.