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

enter image description here

  • $\begingroup$ No it's not. Take a look here for little explanation how slicer works 3dprinting.stackexchange.com/questions/1180/… $\endgroup$ Commented May 16, 2016 at 12:42
  • $\begingroup$ The link refers to triangles as opposed to other polygon shapes in a model. This model has all triangles, so I'm not sure I see the pertinence to the question. This image shows all triangles, so my educated guess is that it would print fine. We don't see the triangles of a model when printing, only layer lines, unless the model is a low-poly design. $\endgroup$
    – fred_dot_u
    Commented May 16, 2016 at 14:10
  • $\begingroup$ @fred_dot_u the link gives a little explanation on how slicer works. It was assumed that the problem expressed in the question is so small (especially in the red rect) that such little explanation would be enough. Fortunately Ryan Carlyle described it in high level of details. $\endgroup$ Commented May 16, 2016 at 17:21
  • $\begingroup$ Based on the small size of the area in question and the not small size of the clarification answer, I'd expect that the result is trivial in terms of the slicer and/or the printer. Of course, there's no scale with which to base the model size. A 50 mm diameter sphere would probably show nothing, but a 5 m sphere might present the artifact nicely. $\endgroup$
    – fred_dot_u
    Commented May 16, 2016 at 18:08

1 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.

  • $\begingroup$ This is a very nice answer. It is quite surprising to me that S3D does not have decimation built-in. $\endgroup$ Commented May 17, 2016 at 7:09
  • $\begingroup$ It does annoy a lot of people, particularly Smoothieware users, due to a freeze/hang bug that can be triggered by very small motion commands. S3D gcode needs to be scrubbed through a post-processor script to be reliable on Smoothieboards. It does make some sense in context though when you consider that S3D DOES have a built-in manual mesh decimation tool, and is very often used with firmwares like Sailfish that already include post-processors that drop motions smaller than one motor step. $\endgroup$ Commented May 17, 2016 at 15:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .