v1.32a - Ramp/Helical Engage, Rect. Meshing, Polyline Simplify, Improved Medial-Carve, Themes!

Builds for v1.32a are available for download. Lots of changes have taken place with this update, at least ones that are more visible than usual. Here's the changes.txt for v1.32a (roughly ordered by their importance):

• added ramp/helical operation cutpath engage types
• added rectangular meshing for smoother meshes/toolpaths with non-square projects
• fixed polyline simplify routine's poor corner-preservation, now generates
• higher quality toolpaths using fewer motion commands
• improved medial-axis carve toolpath generation quality at the cost of some speed
• added ramp angle to tool parameters (for ramp/helical engage types)
• added pre-defined appearance themes to config menu
• added project auto-backup for recovery of project lost to a crash
• added unsaved project changes notification prompt
• added notification messagebox clarifying to user that they must create a new project in order to begin working with the new units of measure they've selected
• changed unoccluded toolpath rendering to better convey paths infront/behind surfaces
• changed operation parameters panel to be more vertically compact and 50px wider to prevent parameters from extending beyond the bottom of smaller screens (i.e. netbooks)
• changed simulation behavior: selecting operation now shows result of operation
• moved simulation "skip forward" button from ops list to playback controls
• changed hide-toolpaths options to automatically disable when re-generating toolpath
• removed fixed-pipeline rendering for toolpaths, to improve older hardware support
• added option to disable operation max-depth limiting to tool total length
• project version advanced to v11 (tool ramp angle)
• added spacebar/left-arrow/right-arrow control over simulation playback
• operations mode now shows created operations plus one unused slot to create new operations with, instead of a static list of used and blank slots
• fixed slow medial-axis calculation and con_addsegtocells overflow errors caused when tool dia. is a large fraction of project dimensions (eg: smaller projects)
• added multiple draw call system for GPU image convolutions that utilize a large kernel size, e.g. simulated-cut depthmap generation w/ larger tooldiameter/projectsize ratio
• changed minimum 'toolpath simplify' setting to 0.05 to mitigate contouring overflows
• logfile output now includes debug verbosity that's less performance-hindering
• fixed poor project mesh shading contrast in metric units-of-measure mode
• fixed bug causing cuts separated by a z-cut level to be mistakenly linked by linear feed
• fixed bug causing sorted cuts to be improperly connected with liner feed
• fixed labyrinth walls-buffer overflow for large projects w/ small step
• separated project input flags and project size/origin so that mesh regeneration no longer occurs if only changing project size/origin (faster)
• re-generating a toolpath now automatically toggles off hide-toolpaths mode as well as re-enables write-enable and visibility of the selected operation
• separated project mesh coloration from shading: blends multiplicatively now
• fixed improper gradient blending between 3D view background colors
• refactored operation flags to be cleaner & more extensible in the future

Ramp/Helical Engage Cuts

Finally, operations are no longer limited to the single 'plunge' material engage entry cut type now for their generated cut paths. Ramping is available in some form or another for just about all operations (except the Stipple operation, which is limited to plunging only) and helical entry cuts are available only for the pocketing/horizontal milling type operations where a known area of material will be cleared out anyway. Helix diameter is fixed at between 2/3 and 1/2 of the cutter diameter. This may change in the future or become customizable as a tool property.

Just about all operations are able to ramp into cuts now, instead of just plunging down to the start of each cut. Cuts which are a closed circuit/loop will ramp down along the tail end of the cut in the direction of the cut. Alternatively, for cuts which have a distinct start/end that don't overlap (non-circuitous cuts) the cutter will ramp down backwards along the cut down to its beginning. If the cut is too short then the tool will zig-zag back and forth along the cutpath down to the start of the cut - regardless of cut direction.

Rectangular Meshing

The core meshing algorithm has been re-worked to generate triangles which are more square regardless of the aspect ratio of the underlying image. Previously meshes generated by simply subdividing triangles in half, which meant that all triangles would always have the same aspect ratio as the image. This is OK when the image is mostly square but for rectangular images with a pretty dramatic aspect it resulted in somewhat rough meshes.

In this comparison between v1.31a and v1.32a you can see how the X-axis has a lower resolution than the Y axis, because subdivisions are spread out over its length, which makes the italic 'N' and the curves on the 'C' come out rather choppy. Now meshes will subdivide much more evenly and be much smoother for all image aspect ratios.

Polyline Simplification Improved

All cutpaths are generated through a variety of different mesh/polyline intersection routines. These produce millions and billions of individual line segments, most of which are redundant and don't add any visible change to the resulting cutpath polyline. This warrants the use of an algorithm which can detect which points to keep and which to discard when building the polyline contours.

There are several popular algorithms for taking an existing polyline and reducing its overall vertex count, but in PixelCNC's case this would require generating polylines with billions of vertices and then decimating them as a secondary step - meaning the polyline would have to initially exist in its raw full-resolution form in memory. This isn't exactly an option in PixelCNC as it would hog system memory and run very slow. PixelCNC needs a way to determine whether or not vertices should be included in a polyline that it's generating on-the-fly, without having the whole polyline to look at.

Above on the left you can see the old simplify algorithm completely ignoring the chevron corners in a bunch of spots. Using the same path simplify and min/max segment length CNC/CAM settings for both v1.31a on the left and v1.32a on the right you can see that the chevron corners are perfectly preserved now.

Here's a zoom in on a deep corner next to a raised feature with a parallel toolpath and a very small step over size. Once again the old polyline simplification code is on the left and the new code is on the right:

Medial-Carve Quality Improved

One of the problems with the medial-carve toolpath generation was that it did not work in concert with the polyline simplify very well. Areas comprising straighter and longer segments would make for generating a poor medial-axis toolpath. The medial-axis calculation algorithm has been improved to more tightly conform to corners and also prevent sloppy areas caused by straighter edges.

In the image above is a 1" square area of a 24" wide project. You can see how these smaller features can get sloppy if the CNC/CAM settings are not finessed. In order to prevent the 'loose' toolpath you see on the left users would have to reduce their segment max length to get a toolpath that better conformed the medial-axis of the shapes and designs in the input image. On the right side you can see v1.32a's much improved medial-axis toolpath, using the same default CNC/CAM settings as the left image (simplify = 0.20, min.length = 0.02", max.length = 0.25").

Better Un-Occluded Toolpath Render Mode

The un-occluded toolpath render mode, which is depicted by the toolbar top-center of the 3D view as a stack of squares that are transparent, has always felt like it could be done better. When toolpath rendering is un-occluded you can see all toolpaths all the time, which may be useful in some cases but in many cases it makes it hard to tell which lines are where with more complex toolpaths. This render mode has been enhanced a bit to draw toolpaths that are behind/beneath geometry with an inverted coloration as well as a 2x2 pixel checkered dither pattern.

Separated Min/Max Project Colors From Shading

A visual change was made that allows users to choose a wider variety of project mesh top/bottom colors without having to worry about how it would affect shading. Previously the bottom color chosen would also show up wherever there was shadowing due to the simple lighting that's in place. Now the shading is multiplicatively applied to whatever the top/bottom gradient coloration produces.

Both images are of the same project with the same project mesh coloration (nevermind the background gradient coloration). Clearly the old mesh coloration simply combined the high/low and bright/dark together, and then used that to determine where on the two-color spectrum each spot would be colored with. Now the shading pertains exclusively to light/dark and the coloration is confined to just the depth of the mesh.

Fixed Miscellaneous Toolpathing Bugs

There were reported instances where having multiple Z cut depths (i.e. cut depth is smaller than max depth) with link cuts and distance sorting enabled causing stray cuts through a project. These were the result of the new distance sorting algorithm mistakenly ignoring the distance between Z-levels when looking for the next closest path to proceed with, and linking them together with a feed the way that neighboring cuts should only be linked.

Now what?

So far a lot of the changes in the past few updates have been rather incremental, not introducing large features that change the overall utility and functionality of PixelCNC as a whole. This is about to change. Barring any emergency update releases due to horribly broken bugs that warrant it/them the next update to go out will likely be a two-month wait as it will include the first iteration of a new 'canvas' system.

This canvas system will allow a project to comprise multiple 'layers' which would take the form of loaded images/models and also text and geometry/shapes that are created within PixelCNC. Layers will be able to combine or blend together using various blending functions, as well as be repositioned, scaled, rotated, etcetera. This will allow crafting elaborate projects entirely within PixelCNC, instead of relying on existing models or a graphic design program for creating projects.

There's still a lot of details to hammer out, which I plan to along the way, but I have a pretty good idea of where I want to go with the canvas system. One thing I'm still mulling over is whether or not (or even how, exactly) to incorporate the ability to have operations that generate toolpaths off of only specific layers, or say have a medial-axis/V-carving that's from a conventional black and white image layer but then have the actual toolpath draped over some other 3D shape or relief form.

My original idea was to just have the canvas system effectively function as an in-program image editor where users can paste a bunch of different images/models together and organize them into whatever their vision for their project was and then all the layers would be compiled or blended together into a final project input image off which all toolpaths are generated. They'd be able to edit the layers at will and then re-generate their toolpaths, but this idea does not allow for having, say, a text layer that will be V-carved.  It would be the simplest form of the canvas system to create but also not as powerful as being able to toolpath off of any combination of layers.

Anyway, that's the next big plan for PixelCNC and I think it will really empower users who are not experts at graphic design. With a background in multiplayer game development I'm also debating adding a prefab library that users can share stuff on. Made a cool little decorative corner doo-dad that other users might like to use? Post it to the public library! Need a decorative little doo-dad for a new sign or engraving you're making? Find one on the public library! Etcetera.

Ikigai!

PS: Automatic updates for v1.32a will be going out over the next few hours.