v1.29a - Fixed Older Graphics/OpenGL Support, Much Improved Horizontal Toolpaths

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

• horizontal milling toolpaths now handle islands in a more robust manner
• changed horizontal toolpath generation progress to show only surface contours
• migrated to new development environment to allow for 64-bit PixelCNC builds
• fixed chevron operation generating blank toolpath with 'climb' cutting direction
• improved project rescaling to optimize resolution for large and small projects
• simulation resolution is now capped to 150 pixels/inch, to prevent GPU 'crash' timeout
• fixed crash when changing project mesh color without a project image loaded
• changed project mesh shading to be project scale invariant
• changed simulation shading calculation to better accomodate tiny projects
• swapped editbox cursor move direction on mouse wheel up/down
• added value-knob adjustment via mousewheel
• added new UI fonts 'IBM' and 'KaiTi'
• fixed render system GPU shader error checking failure in edge cases
• fixed bug in render system OpenGL version reporting
• added logfile path to debuginfo log output
• fixed medial-axis ignoring max-depth parameter if smaller than cut-depth
• changed medial-axis max-depth to restrict distance from outer contour edges
• fixed labyrinth operation getting "trapped" and not generating a full toolpath
• fixed some debuginfo not being written to log due to configuration not loading first
• fixed 'nested comments' being written to G-code files (caused errors for some CNCs)
• added option to open generated G-code after writing to disk
• fixed crash on 'export g-code' with project that has no operations/toolpaths

Horizontal Milling Toolpaths

Horizontal milling toolpaths have finally been given some much-needed attention. A problem which stemmed from an elusive issue involving the ordering of cuts around islands has been mitigated through the use of forming 'bridges' which effectively converts everything to individual pockets. This was detailed in a previous devlog post.

Improved Project Rescaling

PixelCNC's previous behavior was to cap the input image resolution to roughly 150 pixels per inch. The end result was that 1"x1" projects would result in the input image being rescaled to ~150x150 pixels, which is simply not enough resolution when doing small engraving type projects. For most larger projects this blanket resolution cap works out just fine, but makes it very tricky to do smaller highly detailed engravings. Now the resolution dynamically adjusts with the size of the project. The downscaling is there to begin with specifically to minimize both the amount of calculations and memory usage when generating toolpaths, which is especially useful for users who have large images and are not paying attention to their size/resolution. PixelCNC automatically pre-processes the image to eliminate redundant resolution as a result.

New Dev Environment for 64-Bit Builds

This particular todo list item has been avoided for far too long, and should've been tackled before PixelCNC was originally released 11 months ago with v1.0a. 32-bit versions will still be offered for users who happen to be running on 32-bit systems for whatever reason. All other users should be using the 64-bit version of PixelCNC as it virtually eliminates out-of-memory issues that are caused by the limited range of memory addresses inherent to 32-bit versions. For most common projects this has not been a problem but creating one-too-many operations or an operation with a tiny step-over has resulted in memory allocation failures while generating a toolpath due to all of the memory within a 32-bit address being used up, or at least fragmented enough for there to no longer be any available large contiguous chunks of memory for PixelCNC to use. The system which is responsible for generating a 3D mesh from an image usually requires the most amount of memory, and has since been converted to a dynamic memory allocation scheme which only uses as much memory as it needs, but for large meshes being generated that result in millions of triangles it is easy to consume the relatively small amount of available memory allotted a 32-bit program.

The automatic-update functionality has also been divided between the 32-bit and 64-bit versions, where the 32-bit version will only ever auto-update to the latest 32-bit version of PixelCNC. Users who wish to switch to the 64-bit version will have to initially download it manually first. The 64-bit version will then automatically seek out updates for itself. Maintaining these two separate builds and updates, (alongside the free trial builds for each version) will be more work but if it makes the most possible number of users happy then it's worth doing!

Fixed Render System Error / OpenGL Version Checking

PixelCNC is advertised as supporting OpenGL 2.1 as the bare-minimum graphics hardware requirement, and has worked for some older systems but over the last week a user reported some trouble getting PixelCNC to render properly in spite of loading just fine. Some changes have been put in place to greatly improve compatibility with older hardware and it is suggested that anybody who has had trouble running PixelCNC on an older system should try again with the latest version. As long as the system truly is OpenGL 2.1 capable PixelCNC should work this time around.

Changed Medial-Axis Max Depth Behavior

The behavior surrounding the cut-depth of a medial-axis carving operation originally simply restricted the depth at which a medial-axis toolpath was allowed to cut at, but still followed the medial-axis of the shape at the threshold level for the input image and the flute-length of the cutter. The idea was that the cut-depth parameter would allow V-carves and B-carves that would cut in multiple passes, up to max-depth, but the medial-axis itself was always dependent on the cutter's flute length itself. Now the max-depth parameter and tool profile are used to calculate a maximum edge-distance for the medial-axis.

Here's what a normal V-carve looks like with a 0.25" 90 degree v-bit, and a max-depth of 0.25". You can see that the original form of the arrows is retained.

Now here's the same operation but modified so that the max-depth is halved to 0.125". The arrows lose their form because the tool follows the same medial-axis for the 0.25" flute-length of the cutter but the toolpath itself just has its maximum cut depth restricted artificially:

v1.29a retains the original shape of the thresholded forms, even with the max depth restricted to 0.125" because it calculates a proper medial-axis for the max-depth.

Admittedly, there's now a bug involving the interaction between cut-depth and max-depth. A new medial-axis should be generated for each successive cut depth.

Fixed "Nested Comments" in Exported G-Code

Exported G-code contained both the program title and post-processor used, and the title of the PixelCNC window before v1.29a was finalized had the '32-bit' or '64-bit' contained in parentheses, i.e. "PixelCNC v1.29a (32-bit)" while the included post-processors are postfixed with '(Inches)' or '(Metric)'. Mach3 compatible CNC controllers expect comments to be formatted by their enclosure within a pair of parentheses, and having these 'nested' parentheses in the first two lines of exported G-code was proving problematic in various ways for multiple users. 

Some controllers would just report an error processing the G-code lines but otherwise run fine while others would fail to generate a toolpath preview. Strings written out as comments to exported G-code are now stripped of common characters used for formatting comments, such as semi-colons, parentheses, etc.. This is a bit of a hacky/roundabout fix as it should really just strip out whatever symbols are specific to the formatting of comments for the current post-processor. I've also since removed the parentheses from the PixelCNC program title, but prefer to keep them with the post-processors (there's an actual reason I won't get into right now) so it's a bit of a meeting half-way deal.

Example Images Separated from Builds

One last thing I wanted to point out to users is that the example images typically included within each release have been separated out into their own individual downloads. This is to keep things more concise and less redundant. I have a harddrive full of PixelCNC builds, for both the full version and free trial, and each one has a copy of the sample images - for no good reason! I have made it a point to reduce redundancy in other ways but just separating them out from the PixelCNC releases themselves is a simple and effective change, especially when they almost never change.

Happy CNCing!