v1.31a - Rest Machining, Cut Sorting, Model Bit-Depth, Spiral Offset...

Lots of snow happening in the California mountains over here. Our apple tree snapped in half and the power was out a few times over the last two weeks. Good times!

Here's the changes.txt for v1.31a:

• added "rest machining" option to clip toolpaths against previous operations
• added cut sorting to optimize toolpath by reducing total rapid distance (horizontal milling not added yet)
• improved horizontal milling island-bridging algorithm
• increased model-import bit-depth: fixed gradient smoothness issue
• added center XY offsets to spiral operation parameters
• reduced contrast on simulation shading: matches project mesh lighting better
• greatly improved toolpath generation speed for horizontal finishing (stepsize = 0)
• added multithreading to heavily utilized image processing functions to speed up several aspects of toolpath generation and simulation
• outline toolpath follows cut at successive depths before moving to next one to greatly reduce time spent traveling between cuts
• project files now at version 10 (now including project versions in changes.txt)
• project mode buttons are now disabled while an operation's toolpath is generating
• added supersampling to model import settings to mitigate edge aliasing artifacts
• added more axis-swap options to model import settings
• fixed smooth radius not loading-from/saving-to project files
• fixed crash when importing ASCII STL model: tells user support's not in yet instead
• fixed crash caused by uninitialized pointer when a project is loaded and an operation is selected in operations mode
• fixed crash caused by uncommon job-threading race condition
• fixed toolpath generation bug causing small start/end gaps between multi cut Z-depths
• fixed crash caused when changing simulation resolution in simulation mode when no operation is selected, after a previous simulated cut was generated
• fixed medial-carve toolpath errors caused by extremely narrow parallel areas
• fixed memory leak caused when project input is established
• fixed multisampling support detection bug
• fixed memory leak with medial carve toolpath generation
• fixed 32-bit version performance issues caused by lack of compiler optimizations
• removed disabling of GL_POLYGON_SMOOTH when multisampling is enabled
• fixed crash when applying changes to tool when operation toolpath extends beyond project edges after shrinking project size without regenerating toolpath
• optimized vertex format for geometry renderin buffers to reduce memory use
• optimized vertex buffer reallocation: buffer size raised to 1.1th power, instead of doubling size each time (which led to greater memory fragmentation)

Rest Machining

Rest-machining is an experimental new feature which will cull from a freshly generating operation's toolpath cuts which travel through material removed by previous operations. There are still some kinks to work out but with some fiddling it can dramatically reduce machining time and also simplify the process of getting an operation's toolpath to be more efficient. This feature may or may not be of much use to users, depending on what their needs are.

This somewhat exaggerated example above shows a project with a horizontal milling operation for roughing out the project and then a parallel operation that follows in smaller cut-depth increments. The view is of an area of the project in simulation mode, with the parallel operation selected (so its toolpath is visible), showing the material that remains after the preceding horizontal roughing operation. It's a little hard to see without being able to shift the perspective and observe the multiple layers of cuts but in the left image many of them just travel through empty space that's leftover by the roughing operation. On the right side 'rest-machining' has been enabled for the exact same operation (along with the cut linking and sorting options). You can see how cuts are confined to areas where there's actually material to be cut.

Cut Distance Sorting

Enabling the 'Distance Sort' option on an operation will sort cuts of a logical group of cuts so that each cut is succeeded by the next nearest cut - with some variation in the metric that specifies cut distance depending on operation cut direction. This reduces the overall travel distance spent rapiding between cuts, which reduces overall run time on a machine. This is not to say that the resulting toolpath will have its cuts in the absolute shortest possible ordering, just that they will be ordered in a way that approximates an optimal ordering and reducing the total run time significantly for some operations' toolpaths.

It's very easy for an operation's cut path generation algorithm to just spew out cuts in a seemingly random order. This order is actually specific to the triangle mesh hierarchy from which the contours for cuts is organized, and therefore is not conducive to preventing toolpaths that are 'randomly' organized, at best. The new distance sorting option performs a secondary sorting pass on the generated cuts in an effort to mitigate the effectively-random ordering in which they are generated.

In the above example, a simple v-carving, the left shows the ordering of the cuts as PixelCNC would normally output them. All those green lines are the rapid motions between cuts, which it's clear are not ordered worst-case (which would be each cut being followed by the next farthest cut) and instead are ordered somewhere in-between totally optimal and totally non-optimal. On the right is the same v-carving operation with 'Distance Sort' enabled before generating the toolpath. Now the tool will meander around, finding the next nearest cut after each one. This can lead to long rapids when the algorithm 'corners' itself far away from the remaining cuts, but overall ends up wasting a lot less time cutting air in most cases.

In this distance sorting example we've a parallel toolpath with a mixed cutting direction, so the tool is just alternating directions back and forth to eliminate the need to rapid back to the starting side and resume cutting. Simultaneously we've also a small minimum cut depth so that the tool's not dragging across the top of our material, thus all the rapid moves above the workpiece between the actual cuts. This is a lot of cutting-air, especially for an operation that allows for mixing cutting directions. On the right we've enabled distance sorting and clearly this has reduced the total number and sum lengths of rapid moves to just a handful of them.

Now, there's still room for improving upon this, and it even works for non-mixed cutting directions - where the toolpath will make an effort to refrain from making large leaps across the workpiece and instead focus on areas of cuts that seem related. It's not perfect, but it should prove useful to those who wish to cut down their machining time.

 This animated GIF demonstrates the cut-ordering that results for a climb-cut parallel milling operation, where the cutting direction is preserved. The toolpath comprises many smaller rapids - instead of many large ones with those that skip over the top surface of the project too. There's still some room for improving the selection of subsequent cuts, but the concept works and is of worthwhile utility. There is still a small issue at times when moving to a new group of cuts: the cutting direction for the initial cut may not be correct, so if your machine undergoes a significant amount of flex/torsion based on cutting direction you may wish to experiment with this feature before going ahead and tackling a large project with a big expensive piece of material.

Model Bit-Depth Fix

Model importing was added to PixelCNC with v1.30a, but there was a bug involving the bit-depth of the rendered depthmap. For deep projects this would manifest as a terraced appearance on imported models.

In v1.30a this was not an issue of the image being generated being the wrong bit-depth. The OpenGL framebuffer object, and attached texture were all 32-bit floats. When creating the model import functionality I assumed that this would ensure smooth model depthmaps, but they were still coming out as you see on the left above. It was a bit of a head-scratcher, but the problem ended up being with OpenGL's fixed-function pipeline utilizing purely an 8-bit coordinate value when passed to the fragment shader. This just required manually creating a float in the vertex shader and passing it to the fragment shader to be output to the framebuffer.

Model Super-Sampling/Anti-Aliasing

Also, v1.31a adds a super-sampling option to the model import settings via the Config menu. The supersampling value on the model import settings dialog controls a multiplier value for the area of the image that the model's depth values are rasterized to. So for a model import image size of 1024 (and a model with a square aspect-ratio), with a super-sampling value of 4 this would double the dimensions of the rendered image to 2048x2048. The resulting image is then down-scaled with the proper filtering involved to average out all the pertinent pixels' contributions to the resulting image's pixels.

Here you can see the effect super-sampling has on the sharp edges, or 'cliffs', of the imported model. They're much smoother now.

Spiral Center Offset

The spiral carving operation now features XY adjustments for offsetting the center of the spiral toolpath itself, as a percentage of the project size. The percentage can range from -50 to +50, allowing displacement anywhere within the edges of the project.