We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
I just released v1.15a of my PixelCNC program for streamlining the process of getting from a raster image design to G-code. It can generate a variety of toolpaths - some of which are unique and can’t be found in any other CAM software out there. Their purpose is to exploit the nature of the toolpath’s marks left from a tool’s shape profile to add an artistic stylized texture or pattern. Instead of a toolpath being exclusively a means to an end now the toolpath itself can be a piece of the artwork. There’s also the usual parallel/horizontal/v-carving toolpaths one can expect from a CAM program for more conventional CNCing purposes.
In a nutshell PixelCNC is a CAM program for artists who want something that gives them all the power and control they need, without the complexity (and price tag) of professional CAM software packages. There are also free programs out there for ‘converting’ an image to G-code, but they are extremely limited in features and capability and usually run very slow. PixelCNC is highly optimized, provides a nice looking 3D preview and minimalist interface, and features (the beginnings of) a simulation system for previewing the cuts that generated toolpaths will produce, so that you don’t have to ‘cut blind’ just to discover what your toolpaths will actually look like when run, which is something I loathed about the free software out there that just spits out G-code, or maybe only renders the toolpath as naked lines that poorly convey what the CNC will actually produce.
The latest version has a bunch of fixes and improvements and now supports SVG images as well, which was a feature suggested by a user. More features are on their way for v1.20a, which I’m aiming to have out in May. I’m also working on some video demonstrations and a set of tutorials for accomplishing different things with PixelCNC.
Hi, the Trial version only loads images that are ~65,000 or less pixels (not 65kb filesize) and does not allow loading/saving PixelCNC project files, but otherwise *is fully functional. This is explained in the messagebox that always shows when you start it up. The included example images are already sized to 256x256 so you can get started experimenting with it.
Good question! Right now there’s a hard-coded Mach3 compatible post processor, but everything’s setup so that I will be able to implement a post processor system without too much difficulty. This is one of the features that will come just before PixelCNC moves from alpha to beta and all that is left to do is work out the kinks and bugs. Right now the features that I’m focused on getting in there include moving the image-operation system which is at the core of the CAM algorithms to a GPU based method, and expand the simulation system engine to include a timeline the user can scrub along. Another large feature is a built-in image editor mode. If there’s enough interest in post processor support then I’ll likely bump it up on the timeline to get it out sooner, which was the case with adding SVG loading support. Thanks for your question
@CharlesVanNoland
Looks pretty slick. I like the interesting toolpaths.
I’d like to see mouseover hints for the various tools/options.
Question: how would I fill in areas not carved by a medial carve (v-carve)? The flat areas.
Also, is it possible to cut a profile path?
Any plans for importing mesh (STLs)?
As far as programming and software development goes I haven’t used anything in the way of demanding anything beyond what XP offers and supports, so theoretically it could work just fine. I’ve only myself 5 machines running anything from 7, to 8.1 and 10, and it runs fine on all of them. I haven’t used anything like .NET or Visual Studio 20XX that requires end users to install anything in the way of runtime redistributables.
However, I have a hankering for some fine optimized GPU-based rendering and so that’s what I employ in PixelCNC - just so that things run nice and smooth. It expects that the system’s hardware supports OpenGL 3.0, which is a graphics processor specific deal. As such, anything fabricated prior to 2009ish will likely not fly. XP should support GL 3.0, and beyond, but it’s up to the hardware of the machine itself as to whether or not that’s alright and not so much the OS.
There’s a free trial version that is only limited by way of the pixel area of the images that are loaded and with the project load/save functionality handicapped, but otherwise is fully functional. If the trial version runs on your XP machine I’d be glad to hear it, and am admittedly partial to investing the time and energy in ensuring that it does, only because I take pride in writing software that is usable on he widest range of hardware possible.
If we can make sure it runs on XP that’d be great. Go ahead and check out the trial version, see what you can do with that and get back to me.
One thing that I’m experimenting with is copying the v1.14a DLL files over the new ones that are included with v1.15a. They were updated to a new version for v1.15a in order to get SVG support working, but I suspect they’re causing problems for some people. I’m going to upload the v1.14a trial, which you can check out, or copy the DLL files from over the v1.15a ones.
Just so you know, I ran your trial version on a laptop with Windows 10 home, I5 processor, 16GB ram with integrated video…basic cheap Dell laptop. The trial version runs well for me.
Thanks Clyde, those errors are what I’d expect if a machine doesn’t have new enough graphics hardware. If your other machine does have a newer graphics chip, and up-to-date drivers, then there’s a good chance it will run fine. It might not run very fast, but it could theoretically run. If you do manage to get it running you can speed it up a bit by disabling the multisampling option in the Config->Appearance menu dialog box. It’s just a checkbox down at the bottom.
I’ll have to create a new operation specifically for generating a toolpath that removes the larger areas inside the v-carve areas. It shouldn’t be too hard, but it will definitely be a little while before I get that in there with some of the other stuff that’s taking precedence.
For a profile path you can use the outline operation, which allows you to set what brightness of the image to set the cutoff between bright/dark to use as the delineation to follow. You can also specify how far in/out to offset the toolpath using the ‘step size’ parameter of the outline operation. If you have a .25" cutter and want to trace the outline of a shape you’d set a step offset of -.125 or .125, depending on whether you want the tool to cut along the darker side or the lighter side, respectively.
There are plans for importing geometry meshes, which will be converted into depthmaps that are then used for all the image-based toolpathing algorithms. Thanks for asking!
What kinds of tooltips are you thinking? A sentence blurb describing each option/parameter? Or just the name of a button for the project mode and view buttons?
Hi DonSpells, Can I ask what version of Windows you’re running, and what hardware you have in your system?
CPU make/model, RAM, and graphics hardware?
EDIT: Also, could you go into your users<username>\App Data\Local\PixelCNC\ folder and send me your log.txt file after loading one of the included images crashes? You could also just paste it onto pastebin.org and send me the link. Thanks!
I forgot to mention that one of the things that’s been on the todo list is also allowing for generating inlays, which will require that the inner islands be cleared out. There would be the addition of two more toolpaths, one which could be tacked onto the existing v-carve path that removes the skinny areas unreachable by a larger flat end mill that would later come in with its own toolpath to clear out the meat of the leftover material.
Right now there’s a few features of equal size and priority along with a sizable list of smaller more tentative features to be added, and it’s a bit tricky trying to sort it all out and know which direction to go next. Then there’s obviously the surprise compatibility issues that seem to pop up out of the blue with certain peoples’ configurations, which I consider to take precedence over any and all new features. It’s a bit of a bummer being surprised with it not working when I’ve made every effort to maximize compatibility by avoiding using a bunch of modern dependencies that require users to go out of their way to download and install .NET updates and Visual Studio redistributables
. I will try it on my other XP-Mach 3 system tomorrow.