v1.30a - 3D Model Import, Pocketing Operation, Improved SVG Import ...

v1.30a finally released! I planned to get this out sooner but the final testing before packaging everything up yielded two new bugs that I was compelled to squash first. Also, I underestimated how much longer it takes manually creating both full and trial builds, as well as a 32-bit and 64-bit version of each, plus packaging up the automatic update packages for 32/64 bit versions. Aye!

One thing I'd like to mention before diving into the meat of this update is that previous 64-bit versions' auto-update package extraction system is broken. A 3rd party package decompression library that works fine in the 32-bit builds just happens to corrupt memory for unknown reasons in the 64-bit builds. A message notifying 64-bit users will show up when the auto-update system checks for an update, notifying them of the situation and that they'll have to download v1.30a and install it manually (like the good old days!) in order to be able to receive automatic updates in the future.

Here's the changes.txt:

• added 3D model importing (currently supporting GL3.0+ only  should work for GL2.1!)
• added pocketing operation for creating pockets from forms at arbitrary depths
• improved SVG support: ensures SVGs are rasterized at sufficient resolution
• added UCCNC/Stepcraft post-processors (prefixblock: one command per line)
• added Mach3 post: just a duplicate of the GRBL post, for clarity
• removed free trial restriction of 65k pixels in loaded project image
• added 'Smooth Radius' to project size settings, for aliased/rough project images
• added free trial restriction: ~4000 motions/operation in exported G-code
• added free trial delay timer forcing users to wait before clicking OK to continue
• fixed cut-depth/max-depth behavior for medial-axis
• fixed initial/last toolpath point on medial-axis carve (b-carves fixed)
• minimum project image downscale factor changed from 1 to 0 (i.e. 'no downscaling')
• added 'set' command to post-processor scripting for defining custom variables
• changed horizontal operation to include 'max depth' as a cutting plane if successive cut planes at 'cut depth' increments exceeds it
• added comment with operation name and tool to exported g-code
• improved flexibility of automatic delimiter placement in G-code generation
• miscellaneous GUI and G-code tweaks/changes
• improved raymarched simulation rendering (less warping of hard edges)
• fixed raymarched simulation rendering 'bleeding' to opposite edges
• improved CPU usage by 5-10x when idle and cap-framerate is enabled
• fixed toolpath overwrite errors when loading project with no operations
• fixed decimal places in project dimensions in image size/origin not changing with project units of measure
• changing a tool's geometry now updates the simulation depthmap for operations which are using the tool (users will usually want to re-gen toolpath anyway)
• load image defaults to last loaded image path, instead of last project
• made slight adjustments to improve quality of generated toolpaths
• improved older hardware support: should allow users with older GPUs to enable GPU image convolution from the Config menu, which should speed up toolpath calculation and the simulation system.
• re-arranged various settings dialogs and Config menu
• improved speed and reliability of horizontal operation toolpath generation
• fixed 64-bit build auto-update system not able to extract update package

Importing 3D Models

In spite of PixelCNC's main selling point being that it generates toolpaths/G-code from images I decided that it would be more useful to those who already have an established 3D-model based workflow (which I imagine is most seasoned hobby CNCers) if they could use their existing cache of 3D models. Then they could at least experiment and transition to a 2D image based workflow at their own pace, instead of having to jump right in with both feet CAMing images, which may be somewhat foreign to some users.

The new 3D model import functionality works by simply rendering the loaded model to a depthmap image, which is then fed into PixelCNC the same way any conventional image loaded from the file system would be. There's a new dialog under the Config menu named 'Model' which exposes parameters for adjusting how models are rendered to the input image, including the size of the image itself.

Currently only STL models are supposed (binary only, no ASCII). More model formats will be supported over the next few versions. OBJ is looking like the next best candidate, and from there it will be tricky as other popular formats like FBX, GLTF, etc.. can be a little trickier.

Pocketing Operation

The new operation is conceptually a bit of a mix between the Horizontal Milling operation and the Outline Carving operation. This operation uses a Threshold parameter (similar to Medial-Axis and Outline carving operations) to designate the image grayscale value that delineates where pockets should be formed. From here the user can set an arbitrary Max Depth for the pocket to be cut to, in multiple Z passes at Cut Depth increments, until the tool reaches Max Depth for the final cut pass. This enables users to create pockets that ignore the geometry of the input image, except for the initial threshold which defines the actual pocket shape.

Above is a normal v-carving using a 90 degree 0.5" v-bit with the Medial-Axis Carving operation. The inner parts of the shape are too wide for the bit to reach.

Using the pocketing operation for both the v-bit and a 0.125" flat endmill all the inner areas can be cleared out.

However, there is a bit of redundant v-bit pathing going on because most of the material can be cleared out by the 0.125" endmill, and the v-bit need only clear out the tight corners that it can't reach. This is where adaptive toolpathing will come in, which is not yet implemented but it's a major feature that I've been sketching ideas about algorithms for which will allow quickly generating toolpaths that ignore areas already cut by previous operations.

Improved SVG Import

Previously, PixelCNC's SVG import support was achieved through the use of SDL (Simple Direct media Layer, a platform-abstraction graphics applications development library) which includes functionality for loading a variety of different image types. All of PixelCNC's image-loading capabilities are achieved through the utilization of SDL's capabilities. SDL implements SVG loading using NanoSVG, which is a small single-header source file that can be found on GitHub, but did not expose any of NanoSVG's parameters for rasterizing SVGs to a conventional raster image. The end result was that some SVG images with weird internal sizes would rasterize at unusable low resolutions.

PixelCNC now directly utilizes NanoSVG. This is not to say that it circumvents SDL, but instead just implements its own version of NanoSVG alongside SDL. I've modified NanoSVG to rasterize images in a way that's more suited for PixelCNC's purposes, including changing the background color from black to white - just as an SVG appears when viewed in an editor or browser. I figured this made much more sense, although, I should do the same thing I did with model import, where the user has options for controlling background color and margin size, etc..

Here's a comparison between v1.29a (left) and v1.30a (right) loading the same SVG for a project with identical dimensions and parameters. You can see here the benefit of having a default white background, and also how a margin is added so that the vector doesn't get clipped at the bottom or at the top corners.

Improved Support for Older Graphics Hardware

One of the major issues plaguing older GPUs limited to OpenGL 2.1 (PixelCNC's minimum required version) which is 10+ years old is that it's a version of OpenGL that was basically in limbo between the old fashioned way of interacting with the primitive hardware of the 90s and the new modern way of interacting with much more capable GPUs loaded with all kinds of compute capabilities. The end result? Most developers save themselves the trouble of bothering with supporting anything that doesn't support at least 3.0 or above - sometimes even newer.

I made the choice to support OpenGL 2.1 specifically because I believe users have a right to software that fully utilizes their perfectly capable hardware. Users shouldn't have to upgrade just because developers are getting lazy! Anyway, I recently discovered that the graphics functionality PixelCNC uses to perform slow and expensive image operations on GPUs that support GL 3.0 or newer is actually supported on the majority of GPUs that are limited to GL 2.1, in spite of it not being a part of the GL 2.1 specification. This is because the hardware implemented that particular functionality but does not meet the full 3.0 specification to qualify, so the 'official' supported OpenGL version on these older GPUs is 2.1.

PixelCNC v1.30a now attempts to access this functionality, enabling older GPUs to enable "GPU: Image Convolution" in the Config menu, which will dramatically speed up mesh generation, toolpath generation, and simulation speed.

Etcetera...

This update ended up being a bit beefier than I had intended. I really need to come up with a better system for releasing updates, because it's becoming quite a chore these days with all the different versions and bits and auto-update packages, etc.. I'll probably just keep working on PixelCNC itself instead and grit my teeth and bear it each time an update needs to go out.

I'm planning on some really neat stuff for PixelCNC over the coming months that I'm really excited about - stuff that wasn't even planned in the original 'vision' for PixelCNC. Actually, they are ideas that I did have early on but decided they would be better for a PixelCNC 2.0, which would be a whole re-write of PixelCNC from the ground up, borrowing some boilerplate code from the current iteration, but I've decided to hunker down and commit more of 2019 than I originally wanted to toward PixelCNC to build it up as awesome as I can muster.

Stay tuned and thanks for using PixelCNC. Have a happy New Year!