PixelCNC v1.85b - 30% Off Holiday Sale!

 

It's that time of year again where the days are short, the air is brisk, and parcel delivery is slower than ever. Of course, if you're on the southern hemisphere, only one of those things is true. :]

At least the sunsets are nice when the sky is partially cloudy and the increased humidity in the air condenses to make the sky hazy, resulting in deeper Rayleigh scattering than usual.

PixelCNC v1.85b has gone live and it includes a few new features along with several bugfixes and changes, the most important of which are detailed below. We've also launched our Holiday Sale and PixelCNC can be had for 30% off through the 5th of January!

  

All Paths-Layers Contour Input

 Operation types which allow specifying the source for Contour Input to generate cutpaths from have allowed for using a "waterline" Z-plane contour of the canvas, or selecting a paths-layer from the operation's chosen Layer Group. v1.85b now allows for a 3rd contour source: all of the paths-layers from the operation's Layer Group, combined.

 

 This allows users to keep their paths-layers separate for subsequent resizing/positioning/etc without having to maintain both a set of separate paths and then duplicate and merge all of them into a "toolpathing" paths-layer.

 Currently this is not available with the Paths Carving operation, as it does not use Contour Input, it only directly converts paths into cutpaths, but we're looking at including an option to allow it to use all of the paths-layers too.

 

Export Toolpath

 A new export option has been added to PixelCNC while in the Project Simulation mode. This appears as a save disk icon button on operations in the operation's list, next to the include/exclude paperclip icon button. An operation's toolpath can now be exported as 2D geometry, which is currently limited to SVG files at the moment.

 

SVG Import/Export Units

 Within the CNC/CAM Settings dialog we've added a new option for toggling whether SVG geometry should be imported/exported in physical measurement unit coordinates instead of canvas pixel coordinates. The new option is labeled "Physical SVG I/O Units". When loading a vector as a paths-layer the Fit to Canvas option on the New Layer dialog still applies, however.

 If you only plan on loading SVG vectors that are sized in physical units, keep this option enabled. Keep in mind that it does not make any distinction between what units the SVG's coordinates are in and what the current project's measurement units are. It's assumed that the SVG is in the same units as the project itself. In other words, an SVG of 100 "units" loaded into a metric project will be 100 millimeters, while when loaded into a project that's in inches it will instead be 100 inches!

 

Distance Measure Tool Additions

The Distance Measure Tool has had some additional dimensions added to it so that every possible dimension can be measured without too much effort. These measurement dimensions take the form of three separate axis-aligned right-triangles where one leg of each triangle is aligned with one of the XYZ axes while the other leg is a diagonal formed along the plane of other two axes. The hypotenuse of all three triangles is the line segment between the endpoints placed by the user to measure between.

 

Any dimensioning triangles whose measurement-axis is too short on the screen is omitted from being rendered. Zooming in the 3D view to increase their screenspace length will make them appear. This is to keep the jumble of dimensions and lines from being visually cluttered and difficult to read, which it easily does without measurements being omitted that are very short on the screen.

The legs of the triangles are colored by the axes that they are a measurement of. Red indicates the X axis, green indicates the Y axis, and blue is the Z axis - just like the machine origin's coloration. Similarly, yellow indicates a combination of red and green, and is therefore a diagonal measure along the XY plane, while cyan is green and blue, and therefore a measure along the YZ plane. We will likely be fine-tuning this coloration scheme, or perhaps adding the ability to toggle certain axes/combinations from being displayed, but we felt that this is at least readable enough for now.

 

 As you can see in this image, by simply placing the distance measurement endpoints on the two rivets, it's clear that they are separated by 0.2" on the vertical, and they're 1.354" apart on the horizontal (XY) plane. We can also easily see how far apart they are on the X axis and the Y axis too.

It should be much easier now to get a measurement between two features, or the radius or diameter of a circular feature, as the exact measurement endpoints no longer need to be in perfect alignment on axes that are irrelevant to what's being measured.

  

Overlapping/Duplicate Paths Rendering

 For purposes of helping users to work with 2D geometry that includes redundant/duplicate overlapping paths, we've added an option called "Show Path Overlap" to the View Settings dialog which changes the paths-layer rendering to highlight where there are overlapping/duplicate paths in a selected paths-layer. This may get moved to the view button bar along the top of the PixelCNC window in a future update.

Previously, while there was a visual indication as to whether two paths occupied the same pixels on the screen, it was much more subtle, and only emboldened the appearance of paths somewhat - which made it easy to miss if you weren't looking for it. This could cause certain paths to seem like they're being completely ignored when generating 3D shapes or toolpaths from the paths-layer.

 The new overlapping-paths highlight option simply indicates wherever in the view a pixel is occupied by more than one path segment. The caveat is that the highlight can also appear when the Paths Thickness setting is turned up (under View Settings), and/or when the camera is zoomed out, in spite of there technically being no actual overlapping/intersecting paths. We're working on a way to remedy this, but for now it's a relatively minor visual rendering glitch that the option produces:

The solution we're mulling over to remedy this issue would entail a more expensive means of rendering paths altogether, and could slow things down on older hardware. This could be an optional rendering mode that PixelCNC defaults to using, but that users can disable if interacting with the 3D view becomes too sluggish, which it very well could on older hardware when a project includes a paths-layer with many paths. We'll be exploring different options in the meantime.

 

 

Duplicate-Paths Removal Function

 Along with highlighting where duplicate paths are present in a paths-layer, we've also added a new function to the paths-layer's editing mode that automatically detects, and removes, any redundant paths that may exist in a paths-layer. With the SVG image format in particular it is not uncommon to come across files, which when loaded into PixelCNC as paths-layers, result in the situation where a path includes an extra "duplicate" version of itself overlapping it. This is usually either because of a user mistake when  originally authoring the vector image, or the duplicate paths are intentionally created to convey some other visual/graphical quality or effect - because SVG is ultimately a "graphic design" format, rather than a proper 2D geometry CAD format like DXF. 

 

With the way that PixelCNC interprets paths, any redundant duplicate paths will cancel eachother out in situations where the area inside of the paths is differentiated from the outside. This causes it to behave as though neither of the paths are present in the paths-layer. This is due to paths being treated so that they invert the area that they occupy, allowing a path to serve as the outline of a positive space while interior paths then are automatically treated as areas of negative space within the outline path.

The new Remove Duplicates function exposes an "Overlap" parameter for users to adjust the threshold of overlap that is required for paths to be considered as the same for one of them to be removed. This is provided because not all redundant paths are exactly the same as the path they are similar to. Sometimes a duplicate path is slightly shifted by a small distance, or its path nodes are ordered in reverse, etc. The Overlap parameter provides an adjustable margin for the automatic duplicate path removal to abide by.

 

Medial-Axis Carving Bugfix

We've remedied a situation with the Medial-Axis Carving operation that would result in tiny little contours confusing the cutpath generation, and generating some ugly corrupted cuts. This can be seen here in v1.84b:

In v1.85b we simply omit contours that are just too small to effectively generate a proper cutpath from. This does cause features to be missing, but the fix is simply increasing the Canvas Resolution as shown here:

 

 There still may be the potential for very thin/sharp features to improperly contour, which can result in a similar issue. The quick fix for now is to increase the Canvas Resolution - usually it doesn't take much - which will clean up the contours and generate a legitimate cutpath.

 

Trochoidal Milling Bugfix

Another toolpathing bug was discovered in the Trochoidal Milling operations, which would cause cutpath arcs to not span the entire area of a pocket as they should. This is what that looked like in v1.84b:

 

This was a rare occurrence that could happen when toolpathing square or rectangular contours, but it wasn't something that occurred reliably - only when all of the parameters happened to line up in just the right way.

 

 

Above is the same operation after generating its toolpath in v1.85b, which has resolved the issue. The initial spiral cut now spans the entire width of the area to be milled out, so that the subsequent arc cuts are able to maximize their material removal, moving along the centerline of the rectangle's area.

 

Merging Mirrored Paths-Layers Bugfix

 We've rectified a bug that went unnoticed for a time because it was introduced indirectly by a change that was made around paths-layers and merging them. The bug manifested when a paths-layer employing the Mirror X/Y options had another paths-layer merged down with it. The resulting paths-layer would end up with the wrong layer origin, shifting the paths of both layers to the incorrect position.

 

Conclusion

Unless a hotfix update is warranted within the next two weeks, this will be the last PixelCNC update of 2024! We're always looking for user feedback, especially suggestions and feature/functionality requests. Don't hesitate to send us your questions/comments/concerns at: support@deftware.org

Here are some signs we made recently using PixelCNC: 

These are maple boards that have been whitewashed (white latex paint diluted with water), then vinyl was temporarily adhered to before V-carving. The cuts came out very clean and nice. Then we spray-painted the cuts with a stain black paint and peeled the vinyl off. We lastly sprayed several coats of indoor/outdoor urethane on them in the hopes of them surviving for a few years being exposed to the elements in front of our friend's baked goods shop. Fingers crossed!

 

We also had another Tree Of Life order, which (after this photo of the finished cut) was stained using Red Oak to make it nice and dark and wooden looking. This was cut out of poplar, but we might start cutting everything out of maple having recently discovered a new local wood supply shop that has great prices and high quality wood.

See you next year, and happy CNCing! :]