v1.21a released & via auto-update!

PixelCNC v1.21a has been released. I just pushed the first update via the new auto-update system that was added with v1.20a, so any users who run PixelCNC on a web-connected machine should be seeing a prompt to download the update the next time they fire it up. Limited testing resources leave the possibility open that the auto-update system might not work properly for everyone. I don't know this to be a fact, it might work completely fine for everybody who accepts the update, but on the off chance (fingers crossed) that it does not go properly I hope users are willing to help get PixelCNC where it needs to be by reporting their experience, with as much detail as possible, i.e. Windows version, any antivirus or other non-standard software that might interfere with update operation, and any other pertinent information.

I'm looking at finally investing in a certificate for signing PixelCNC's executable files, so that users and their antivirus programs don't complain about a seemingly-random EXE file being run on their systems. This will probably happen over the next few months.

Here's the changes for v1.21a:

 - improved simulation system: now updates individual patches of mesh, instead of bounding rectangle
 - improved horizontal operation toolpath ordering (depth-first & respects milling direction now)
 - improved view homing to better fit project to window size
 - added support for conservative 3D view redraw on older GPUs (was only supported on GL3.0+)
 - added automatic op sim depthmap regeneration on config resolution change
 - added "log debug info" to config menu for increased log verbosity (more info in userguide)
 - added some messageboxes to auto-update system to apprise user of success/fail/etc
 - fixed older GPU support being broken in v1.20a
 - fixed g-code not rapiding to next cut before plunging if cut's first coord is X0Y0
 - fixed stipple toolpath having no effect with live simulation playback
 - fixed chevron step parm to specify actual cut spacing and not Y-axis separation
 - fixed text clipping rectangle on text inside some UI elements
 - fixed simulation not including tool motions between cut paths
 - fixed bad blur kernel size for project mesh texture causing bad appearance on contrast edges
 - fixed not being able to remove operation from project by setting type to 'none'
 - fixed wrong toolpath safe Z for loaded projects with origin Z not at 100%
 - locked simulation resolution in simulation settings when simulation is playing
 - tweaked stipple advection behavior
 - tweaked mesh texture generation appearance
 - export G-code now uses input image name as default G-code program file name
 - removed UI debug info left on the statusbar in v1.20a

The live simulation playback should be quite a bit faster now, as it only updates the local area around cuts even more closely than before by dividing up the simulation mesh into 16x16 quadrants, and individually checks and updates them as needed.

The horizontal milling operation received some much-needed attention with its cut-sorting. A much improved logic sequence for building the cut order hierarchy will prevent deep cuts from taking place before shallower cuts that are above them, while also doing a better job at following the edges of existing pockets. The previous horizontal toolpath generation was barely usable by comparison. There's still room for improvement but this new cutpath tree building logic is definitely a huge step-up, and generated toolpaths are now at least reliably not going to do something highly illogical. I'm proud of where they are at now, but it's still going to take a bit more work to get them to be 'perfect'.

I added functionality for older GPUs to render-to-texture by performing a glReadPixels so that the 3D view could be drawn once, saved into memory, and re-used instead of re-drawing whatever mesh is in the view every single frame - which interferes with the responsiveness of the user interface. Since v1.20a newer GPUs are able to just directly save the 3D view to an internal buffer and dump that to the program window before redrawing the UI each frame, which lends itself to a significant speedup, but the OpenGL functionality utilized for this is not present with older GPUs so I had to devise a work-around.

Simultaneously, some new code happened to completely break support for older GPUs with v1.20a, which was a bit embarrassing, but at least that has been resolved now as well.

The Stipple operation's toolpaths were not being properly simulated in the live simulation playback. This has been resolved.

The Chevron operation's 'step size' parameter now properly spaces apart neighboring cutpaths. Cuts with a high chevron-height to width ratio would end up closer than those with a low H/W ratio, because the step size was only referring to the vertex distance between peaks/valleys of the chevron zig-zag cuts. Now they will increase in spacing with an increased H/W ratio, so that the actual distance between linear cut moves is equal to the established step-size.

Another rather annoying issue was that once an operation slot was assigned an operation type it could not be removed from the project. The plan was to allow the operation type to be changed back to 'none' and PixelCNC would remove the operation entirely, toolpath and all, but this slipped through broken - and unnoticed. v1.21a fixes this, so now if you decide an operation is unneeded in a project you don't have to disable write-enable just to get PixelCNC to ignore it when writing G-code or simulating the project's operations.

There was an error in the size of the blur kernel used for generating mesh textures, which led to yucky looking edges on black/white input mages such as this:

The fix involved ensuring a blur kernel that was an odd-size, so there could be a 'middle' kernel row/column/pixel, which now produces this result:

Also, there has been some tweaking to texture-generation in general, especially with simulation meshes. It was determined that generating all of the shading/coloration into the texture for the simulation was one of the more expensive parts of generating simulation updates, so the shading has been moved to the mesh's triangles themselves, which is a bit of a return to PixelCNC's old flat-shaded appearance from a few versions ago, but is much faster than trying to perform the smooth texture-based shading that the project mesh utilizes (and can get away with).

You can see above the old texture-shading on the left from v1.20a, and the new triangle-shading on the right with v1.21a. These are both identical V-carve operations, and it's obvious that utilizing the faster geometry-oriented shading approach is much better at conveying the simulated cut geometry, and is much more representative of any planar surfaces a cut will generate. The older shading method was generally just too smooth and rounded, and made it harder to discern the exact form that cuts took.

There was a problem with loading toolpaths from projects that didn't have their machine origin Z at 100% (the top surface of the project). This resulted in the loaded toolpaths having rapid moves in the wrong location. This could easily be resolved by simply regenerating the toolpath but the loaded toolpath should've been rapiding where it is supposed to be, regardless of the project's Z origin.

As you can see above, the generated toolpath on the left has the rapids above the project surface, by the specified .125 amount. After saving and reloading the project, which has a Z origin of 0% (bottom of the project), the rapids suddenly traverse 0.125 above the bottom of the project, instead of the top, which results in rapids that are actually underneath the top surface instead. This has been fixed in v1.21a.

There are a few other fixes and changes, but these are the most significant. The next update coming down the pipe will feature some new operations, for inlays and more interesting contouring patterns, and possibly support for post-processors to generate G-code for a variety of different CNC machines (finally!) If the auto-update system seems to be working well for everyone then I may start doing less-often release builds, and more-often updates. New customers who download an out-dated version of PixelCNC will naturally then have access to the latest update via the auto-update system.

A video explaining PixelCNC's interface and demonstrating four of the included operations has been uploaded, and is now viewable on the PixelCNC page. With this video out of the way I will begin creating shorter/tighter videos that demonstrate a variety of interesting CNC projects that PixelCNC allows for, which goes a ways beyond just the individual operations. Combining operations and using them in creative and clever ways can go a long way before exhausting the actual number of possibilities, and I'm exciting to be able to start demonstrating all the cool stuff that can be done. I also want to show some actual cuts on the CNC, which is a little trickier to get situated, but I feel it is imperative for giving viewers the full sense of what can be done.

Thanks for your time and interest  :)