<p>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. </p>

<p>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. </p>

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

<ul>
<li>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.</li>
<li>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 <em>tight</em> 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. </li>
</ul>

<p>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. </p>

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

CC BY-SA 3.0
2016-05-17T07:09:20.750Z
This is a very nice answer. It is quite surprising to me that S3D does not have decimation built-in.
Tom van der Zanden
CC BY-SA 3.0
2016-05-17T15:34:55.247Z
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.
Ryan Carlyle
CC BY-SA 3.0
2016-05-16T15:51:57.763Z
2016-05-16T15:51:57.763Z
Ryan Carlyle
<p>Will an inconsistent vertex density likely introduce artifacts in a print?  Or is it OK as long as it's a smooth surface?</p>

<p><a href="https://i.sstatic.net/FmO9L.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/FmO9L.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2016-05-16T12:42:00.203Z
No it's not. Take a look here for little explanation how slicer works http://3dprinting.stackexchange.com/questions/1180/do-3d-printers-prefer-particular-topology
darth pixel
CC BY-SA 3.0
2016-05-16T14:10:13.140Z
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.
fred_dot_u
CC BY-SA 3.0
2016-05-16T17:21:21.997Z
@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.
darth pixel
CC BY-SA 3.0
2016-05-16T18:08:18.503Z
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.
fred_dot_u
<3d-models><3d-design><slicing>
Is inconsistent vertex density a bad thing?
ajwood
# Is inconsistent vertex density a bad thing?

(Asked by: username_0 on 2016-05-16)

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](https://i.sstatic.net/FmO9L.png)](https://i.sstatic.net/FmO9L.png)

**Tags:** 3d-models, 3d-design, slicing

> **Comments:**
> **username_1**: No it's not. Take a look here for little explanation how slicer works http://3dprinting.stackexchange.com/questions/1180/do-3d-printers-prefer-particular-topology  
> **username_2**: 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.  
> **username_1**: @username_2 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 username_3 username_3 described it in high level of details.  
> **username_2**: 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.  

---

## 1 answers

### Answer by username_3 on 2016-05-16. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_4**: This is a very nice answer. It is quite surprising to me that S3D does not have decimation built-in.  
> **username_3**: 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.  

---

