Four long months later... v1.20a!

v1.20a has been released! Here's the changes.txt:

 - GPU-powered image operations (GL 3.0+ GPUs only at the moment)
 - added incremental simulation updating system for operation playback
 - added compression to project files (old projects still are backwards compatible)
 - added automatic update download + install system (paid version only)
 - added 3D view redraw only as needed, to maximize UI responsiveness (GL 3.0+ GPUs only)
 - added 'Leave Stock' parameter for creating roughing operations
 - added 'v-bit' cutting tool type 
 - added drawing of tool cutter profile diagrams when editing tool parameters
 - added UI tooltips to help users become oriented with the interface more quickly
 - added multiple sizes/resolutions to program icon
 - added light/dark cutoff parameter to medial-axis operation
 - added loaded image/project filename in window title
 - added option for drawing single polygon while panning/zooming view
 - added framerate cap option for users to conserve battery or maximize responsiveness
 - added UI font option "courier"
 - added log file output window for users to easily see output for bug reporting purposes
 - changed name of logfile to date/time of program so each run generates its own logfile
 - changed method for obtaining user temp folder for config/logfile writing
 - optimized GPU vertex buffer drawcall allocation to minimize memory usage
 - narrowed up widths of UI left/right columns to be less obtrusive to the 3D view
 - improved GL 2.0/2.1 compatibility with more robust extension handling for older hardware
 - reworked user config format for better future-proofing
 - invert image option now defaults to config-stored value now
 - increased keyboard editbox 'typematic' delay from 200 to 350 milliseconds
 - optimized mesh memory usage and generation by removing apex Z float32 from triangle nodes
 - replaced heightmap mesh triangle flat-shading with smoother texture-based shading
 - fixed bug in bilinear image sample function which caused a crash
 - fixed bug which generated incorrect toolpaths for non-90 degree tapered cutters/v-bits
 - fixed tool definition arguments in wrong order when loaded from config
 - fixed miscellaneous UI issues
 - added option for users to force-run in spite of multi-core CPU not detected,
defaulting to thread count used on dual-core CPUs

I ran into some trouble with the auto-update system while doing some last-minute testing on a Windows 10 machine. I'll be putting out a tiny v1.21a update sometime this week so users can test the update system and make sure that everything works for everybody. Anyway, I didn't manage to get v1.20a uploaded and available until late into the night. A lot of work has gone into this update, and yet plenty more work still lies ahead. I'm always coming up with new ideas so the todo list is constantly growing - always faster than things are being checked off so it's important that I sift through everything on there and sort it by priority/urgency. It's a bit of an undertaking unto itself to be honest.

The simulation system has had quite a bit of work go into it, there's a lot going on under the hood. There's already quite a bit of complexity involved in minimizing the time it takes to generate each simulation step, but there's still a bit more room for optimization. For now the simulation system updates rectangular areas of the simulation mesh containing each increment's section of toolpath for which a cut is simulating. That is to say, if there's an 'L' shaped section of a toolpath being simulated PixelCNC will update the entire rectangular area it fits inside of - all that empty space on the upper-right gets recalculated, instead of only the area along the toolpath. Similarly, both a diagonal or circular segment of toolpath will result in a lot of wasted calculation. As such, it updates much more quickly with a shorter simulation step length. I already know what has to be done to conform simulation updates more closely to sections of toolpath, and it will be incorporated into an update by September. All of the patch-based updating In the meantime users can reduce their simulation resolution and/or mesh quality to maximize simulation update speed.

Also, the entire mesh texture is being recalculated and updated each simulation step, which can easily take more time than actually calculating the depthmap and mesh update, by a factor of 5x or more at times with a tiny step length. I will have to incorporate a partial texture updating API into the render system, basically wrapping glSubTexImage2D at the core - but it will require a bit of new code in PixelCNC's image-handling API on top of that which the simulation code will interface with. My goal is to include this improvement by September as well.

However, for the next week or two I will be changing gears a bit and creating video tutorials demonstrating PixelCNC's usage. Someone pointed out on Reddit that video tutorials can also serve as marketing demonstrations for potential buyers who are interested in but unclear as to what PixelCNC is capable of. So today I will start planning out some tutorials to record, and I have a nice little cache of scrap material I can use to actually show PixelCNC G-code running on a CNC. I'll probably record multiple tutorials at the same time: record on-screen PixelCNC usage via OBS for different tutorials, then later record some footage of actually running the code on CNC and the finished result. Then I could have a side-by-side comparison with what the simulation system generated vs what the CNC actually cut.

There's a bunch of other things, big and small, that I aim to have all in there by the holidays. Right now I need to focus on getting some tutorials going to help grow the user base, because I haven't been doing any promotion or marketing at all and this version of PixelCNC is much better situated for more widespread use than previous ones, particularly because of the automatic update system. Now I should be able to release new versions all the time and users will not have to check back and manually install them anymore, hopefully. It remains to be seen whether or not the autoupdate system will actually work for everybody. It works fine in my tests now on Windows 7 and 10 machines, so hopefully it will work fine for everybody else as well.