|
|
|
@@ -153,9 +153,87 @@ than the run needs, the next value that changes anything is 0.5 mm — and going
|
|
|
|
|
0.125 mm is another eight times the voxels, not a small step.</p>
|
|
|
|
|
<p>The ladder bottoms out at <strong>0.001953125 mm</strong>. A finer request is clamped to it, so the finest entry
|
|
|
|
|
offered in the workpiece's Initial Resolution list builds the same mesh as the one above it.</p>
|
|
|
|
|
<h2 id="the-width-only-ever-goes-finer">The width only ever goes finer</h2>
|
|
|
|
|
<p>A mesh that exists cannot be coarsened. Every cut takes the <strong>finer</strong> of the width already built and
|
|
|
|
|
the width being asked for, so raising Machining Resolution above the mesh the workpiece was built at
|
|
|
|
|
does not simplify anything — the request is dropped and the run keeps the mesh it has.</p>
|
|
|
|
|
<p>This is why the two settings are not interchangeable. The workpiece's <strong>Initial Resolution</strong> is what
|
|
|
|
|
builds the mesh and is therefore the memory setting; <strong>Machining Resolution</strong> gates how fine a
|
|
|
|
|
<em>newly cut</em> surface may go, and can only ever refine. To make a run cheaper in memory, coarsen the
|
|
|
|
|
Initial Resolution — coarsening Machining Resolution alone changes nothing about the stock that is
|
|
|
|
|
already there.</p>
|
|
|
|
|
<p>It still changes the <em>time</em>, and by a lot, because the same number sizes two other things: the
|
|
|
|
|
tessellation of the cutter's own solid, and the number of engagement layers per step. Both are
|
|
|
|
|
per-step work that is thrown away again, so a coarser Machining Resolution can cut the run time
|
|
|
|
|
several-fold while the memory figure does not move at all. A run that got faster without getting
|
|
|
|
|
smaller is this, not a mystery.</p>
|
|
|
|
|
<p>Pick from the ladder and the number shown in the mission row is the number the run used. That
|
|
|
|
|
matters beyond tidiness: a recorded mesh is built at whatever resolution is in force when the
|
|
|
|
|
record runs, so an off-ladder value is silently baked into the cache as its rounded neighbour.</p>
|
|
|
|
|
<h2 id="what-it-costs-in-memory">What It Costs in Memory</h2>
|
|
|
|
|
<p>Far less than it costs in time, which is the opposite of what four rungs of the ladder — sixteen
|
|
|
|
|
times finer, and so four thousand times the voxels — leads most people to expect. Measured by
|
|
|
|
|
sweeping one case across five rungs with the program and the step count held fixed — a cylindrical
|
|
|
|
|
blank, one roughing program, 199,242 steps every run:</p>
|
|
|
|
|
<table>
|
|
|
|
|
<thead>
|
|
|
|
|
<tr>
|
|
|
|
|
<th>Mesh width</th>
|
|
|
|
|
<th>Play time</th>
|
|
|
|
|
<th>Process memory outside the managed heap</th>
|
|
|
|
|
</tr>
|
|
|
|
|
</thead>
|
|
|
|
|
<tbody>
|
|
|
|
|
<tr>
|
|
|
|
|
<td>2 mm</td>
|
|
|
|
|
<td>10.5 s</td>
|
|
|
|
|
<td>665 MB</td>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td>1 mm</td>
|
|
|
|
|
<td>15.3 s</td>
|
|
|
|
|
<td>688 MB</td>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td>0.5 mm</td>
|
|
|
|
|
<td>31.2 s</td>
|
|
|
|
|
<td>722 MB</td>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td>0.25 mm</td>
|
|
|
|
|
<td>76.6 s</td>
|
|
|
|
|
<td>826 MB</td>
|
|
|
|
|
</tr>
|
|
|
|
|
<tr>
|
|
|
|
|
<td>0.125 mm</td>
|
|
|
|
|
<td>242.9 s</td>
|
|
|
|
|
<td>1,456 MB</td>
|
|
|
|
|
</tr>
|
|
|
|
|
</tbody>
|
|
|
|
|
</table>
|
|
|
|
|
<p>Sixteen times finer costs <strong>23 times the time and 2.2 times the memory</strong>. Two things flatten that
|
|
|
|
|
second column, and it is worth separating them:</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><strong>Most of the figure is a baseline the mesh does not set.</strong> The coarsest run in the sweep already
|
|
|
|
|
sits at 665 MB, and the whole sixteen-fold refinement adds 791 MB on top of it. Read the column as
|
|
|
|
|
increments rather than as totals: the ratio at the bottom of the table is diluted by everything in
|
|
|
|
|
the figure that would be there at any mesh width.</li>
|
|
|
|
|
<li><strong>The increments grow slowly at coarse widths and then accelerate.</strong> Halving the width added
|
|
|
|
|
23 MB, then 34, then 104, then 630 — each increment about 1.5, then 3.1, then 6.1 times the one
|
|
|
|
|
before it, a local exponent climbing from roughly 0.6 to 2.6. A cube stops subdividing as soon as
|
|
|
|
|
the surface inside it is a single flat facet, so while the mesh is coarser than the part's facets
|
|
|
|
|
and curvature, refining mostly buys nothing. The volume-scaling intuition is not wrong; it only
|
|
|
|
|
arrives once the width is below the feature scale, and by then it arrives fast.</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>A big <em>workpiece</em> moves the same curve up: where the stock is a large imported solid rather than a
|
|
|
|
|
small procedural blank, there is far more surface to subdivide and the mesh-dependent part dominates
|
|
|
|
|
much earlier.</p>
|
|
|
|
|
<p><strong>Do not judge the mesh by the process's peak memory.</strong> On a long run most of that figure is the
|
|
|
|
|
per-step data the run accumulates, which lives on the managed heap, scales with the number of steps
|
|
|
|
|
and not with the mesh at all — and it moves the <em>other</em> way when the mesh is refined, because a
|
|
|
|
|
slower run allocates more slowly and the collector commits less. The two cancel: measured on a
|
|
|
|
|
larger case across a four-fold refinement, peak memory fell slightly while the mesh's own footprint
|
|
|
|
|
grew by nearly 40%. Read the two apart before concluding anything.</p>
|
|
|
|
|
<h2 id="what-the-mesh-does-not-change">What the Mesh Does Not Change</h2>
|
|
|
|
|
<p>For a representative test case — downward circular slot milling with varying width and depth —
|
|
|
|
|
the <strong>physical</strong> values move within about <strong>20%</strong> across the full range of mesh widths. The
|
|
|
|
|
