Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Deftware Industries

A member registered May 30, 2015 · View creator page →

Creator of

Recent community posts

Glad to hear you're figuring things out :) The included User Guide also serves as a thorough reference for everything you can encounter in PixelCNC. Though for newcomers to CNC and milling/routing in general it may not be as useful as a tutorial to get you up and running. For most operations the key is knowing what your machine and cutting tools can handle. This determines the range that your spindle RPM speed and cutting feed rates should be, as well as your cut depth per pass and step-over size

Typically, a good rule of thumb for most hobby tabletop machines is to use a step-over ~33% of your cutter diameter for most end-mills. For a depth-of-cut it really depends on how much force your machine can handle. A more rigid machine can handle a deeper cut depth per pass, which makes use of more of the cutting edges along the end-mill's length. Conversely, a less-rigid machine will not be able to take such deep cuts and will need to keep cuts rather shallow, which wears out the tip of the cutter much faster because it's doing all the cutting while the rest of the cutter is underused.

As PixelCNC approaches completion and the intended workflow and usage methodology becomes finalized it will be easier to put out more tutorials and example projects to help newcomers become more familiarized with the basics of PixelCNC as well as demonstrate the more advanced techniques for accomplishing all kinds of wonderful results for a variety of different projects. This will be sometime after PixelCNC leaves alpha and enters the beta phase of development - when the focus moves from adding features and functionality to chasing bugs and polishing the existing feature set.

By my estimate the transition from alpha to beta will be toward the end of the year which also means shifting gears from development and feature implementation to PR and marketing mode - and really putting PixelCNC out there. There's still plenty of great stuff coming down the pipe over the next months that I'm really excited to put into the hands of both existing users (at no extra charge!)  and future PixelCNC users who are looking for something that is simple-to-use while also remaining powerful in its range of features and capabilities.

Please feel free to ask any questions or offer any ideas or feedback that you may have, however big or small. There's always a need for more suggestions and requests from end-users. Admittedly, no promises that everything suggested will be added in - only because there's already plenty of work to be done - but anything that's not too complex and is beneficial to the overall user experience is, to my mind, well worth the time and energy spent.

Are you generating a toolpath first ?

Haven't heard from you for a few days, were you able to get PixelCNC up and running?

Also, there is apparently a widespread issue with running programs in Windows 10 if you have associated a Microsoft Account with the current Windows user account, requiring that almost all programs be run as administrator just to get them to run.

Can you provide more details as to the error messages you're seeing? Our test unzipping all of the included files in the free trial Zip file into C:\pixelcnc\ works on Windows 10 machines. The unknown publisher warning is standard for unsigned executables and should not be preventing you from running the program entirely unless something else is explicitly blocking unsigned software from running, such as User Account Control, Windows Defender, or something related.

Two alternative options are to either run PixelCNC as administrator and/or putting the PixelCNC folder somewhere else on your harddrive that is not accessible only by administrators, such as your Desktop, Documents, or user account folder. PixelCNC does not require administrator access for anything because it does not write to anywhere outside of the current user's files for writing a config file and log file but there have been reports of running as administrator being required just to get it to run, which is something that will be resolved when PixelCNC moves to the beta phase of development.

I would recommend against running any software as administrator if possible by moving the folder to another location that the current Windows user account has access to (i.e. the user account's folder), but this is not a surefire guarantee that it will prevent Windows 10 from requiring the program run as administrator.

(1 edit)

Did you extract the files from the downloaded Zip file into their own folder on your system?

EDIT: Users can simply copy the PixelCNC folder that's contained in the downloaded Zip file to their desktop or other preferred destination, and create a shortcut to the included EXE file on their desktop by right-clicking the EXE file and selecting "Send to Desktop->Create Shortcut".

(2 edits)

Did you create an operation that actually generated a toolpath visible in the view? For example, the spiral operation will produce a toolpath that appears as such:

If you're not seeing any toolpath in the view after creating an operation then you need to carefully consider the parameters you're using for the operation to generate a toolpath with, because it's not impossible to cause an operation to generate zero cut paths - which will in turn generate zero useful G-code.

EDIT: It would be tremendously helpful for us to get you on track to generating useful G-code if you could provide more details as the provided User Guide explains. Step-by-step instructions for reproducing the problem and the generated log-file are invaluable for getting to the bottom of problems such as this.

Ah, I knew I had to be missing something! It's an interesting idea for sure. Have you tried doing it with the image itself? I don't know what exactly you're doing to produce toolpaths that are almost exclusively level, other than perhaps setting project Z depth to a very tiny size and pretending that's your cut depth for the Sharpie to traverse. If you took your image for the stripes and added a radial gradient to them and toolpathed off that using the contour-carving type operations (i.e. parallel, spiral, etc) then you could get the Sharpie to be lifted off more, or have less pressure, at either end of them. That likely won't be as good as changing the feed rate though.

I'll have to think about that because there's a lot of different ways to go about something like that. For instance, would you want to set a percentage of feed rate change per inch of depth/step-over? Or would you just want to say "at this point we feed at this rate" and then pick a distance point "at this distance and beyond we're at this feed rate". That would allow at least a feed rate gradient based on radial proximity to the original center point.There's really a huge array of possibilities, you could also have a set of points all over the project that are blendpoints for different feed rates, or have square/diamond/star shaped concentric zones of either blending between feeds or sharply stepping between them.

Then would you just want a linear transition from one feed to another or something more like a polynomial transition that gives a different dynamic? You could have plain old linear, but maybe something like an ease-in or ease-out cubic transition would be better. Maybe the user should just have control over the curve's start/end derivatives to change the feed rate blend dynamic.

There could even be a new marker/pen tool that just doodles on the project material surface. That might be neato too.

Well I'm not going to make any promises just yet, but I'll definitely keep a location-based variable feed rate idea cooking in the back of my mind, because there is definitely some value there as a feature for manipulating the final appearance of something. I think it could be one and the same with the variable feed system for maintaining a relatively constant spindle load - spawning visible points across the project for an operation which affect the feed rate as the tool approaches them. We will see! This is something that I probably won't be able to get around to until at least 6 months from now, or more, depending on how things go with the features currently lined up for me to knock out. In the meantime feel free to keep sharing your work here for other users to see. It's a pretty cool use case for PixelCNC!



Hi GF357, thank you for the suggestion!

The only related feature that has been under consideration thus far has been with regard to dynamically controlling feed/speed rates (spindle RPM for machines that support it) to maintain a constant spindle load in spite of varying engagement between the cutter and material. I'm curious what exactly the purpose of the feature you propose would be because you did explain the effect clearly enough but I'm at a loss as to what this would be useful for. I apologize if I come off as presumptuous, and by no means intend to seem insulting in any way, but what it sounds like you're talking about is a bit like an alternate means of producing a sort of finishing cut pass? If that's not the case then please elaborate because I'm always curious as to what users envision a need for :)

For purposes of ensuring a clean final surface it is possible in most cases to simply create a finishing pass operation that cleans up previous operations' cuts at different feed/speed rates. The "Leave Stock" parameter enables operations to be treated as roughing passes, leaving a thickness of stock material which allows for a finishing pass to then come in and clean up the rest of the workpiece at different feed/speed rates - and even entirely different cutters that are better suited for the task than what roughed out the piece to begin with. Multiple finishing passes can be performed too, with each one leaving successively less stock material behind to ensure a flawless final surface. I mean no insult if you're well-rehearsed in the arts of CNC and if none of this is new to you and you still think there's a need for a variable feed feature then consider my interest piqued!

The leave-stock parameter, however, is only applicable with the operations which generate toolpaths from the project's actual surface contours and form, such as for relief/emboss type carvings. This excludes the Medial-Axis Carve, Profiling, and Pocketing operations due to the fact that these operations generate toolpaths directly from the project input image itself, with no regard for any 3D geometry to 'leave stock' of any thickness on. They simply generate a toolpath based on a 2D image with no intention of producing or conforming to any  3D form because their depth and offset parameters allow for cuts that are completely independent of the generated 3D project mesh.

At any rate, as far as the 2.5D type operations like pocketing/profiling/horizontal are concerned - which feed through cuts horizontally at incremental depths - it wouldn't be much of a hassle at all to implement a means by which users could impart a fractional decrease in the feed rate or spindle RPM of successive cuts by depth or concentricity. Specifically for the pocketing operation though it's not difficult to produce the equivalent of a finishing pass by using another pocketing operation with the cut depth and max depth both set to the exact final desired depth, and a finishing feed/speed rate set. This would only take care of the bottom of the pockets which is where a profiling operation would come in right after to clean up the 'walls' of the pockets at the finishing speed/feed rates. If your flutes are long enough to reach the depth of your pocketing max-depth then you could clean up the walls with the finishing pocketing operation itself instead, because the profiling operation is only necessary if your cut depth is less than the max depth of the pockets themselves and you couldn't just combine finishing the bottom of the pockets with the walls in one shot.

Again, I am in no way trying to be insulting or presumptive as to what your skill level or existing CNC knowledge may be! I'm only trying to provide some pointers in the event that they may be useful because many PixelCNC users are (surprisingly) actually complete newcomers to CNC. But if what you're suggesting has another reason that such a feature would be of use then consider me all ears! Perhaps it could be a means of providing an opportunity for something of a pseudo-finishing pass built right into an operation - without having to explicitly define one (or more) to get the job done, and that doesn't seem like a bad idea at all. Let me know!

Thanks again,


I completely understand because my setup is pretty much the same. I use my desktop PC for developing and doing CAM work on and then a little cheap netbook to run my CNC in the other room. As such I can't in good conscience confine users to using PixelCNC on any number of computers. Feel free to use it on as many computers as you need to.

There's no anti-piracy/copy-protection mechanisms integrated into PixelCNC to prevent users from making as many copies as they wish, or from running it on as many computers as they choose, and while this may change in the future there are currently no plans to integrate any annoying anti-piracy or license enforcement mechanisms into PixelCNC. I'm trusting the researchers who've shown that the cost of implementing anti-piracy measures is not justified by the minimal increase in sales. I can only hope that users respect my efforts and appreciate PixelCNC by its own merit enough to do the right thing.

Thank you for asking and let me know if you have any further questions/comments/concerns. :)


Thanks, much appreciated. Let me know what you're able to dig up. Surely there's a conversation on a forum or messageboard somewhere between some other people who were interested to either generate or read .tool files into their own projects.

Interesting. I am curious as to whether or not they are intentionally keeping it a secret, as a proprietary format, like some software companies do with their unique file types. That's hard to believe though with other programs also supporting the format, but there could be a monetary compensation aspect involved there. I could possibly reverse engineer the format if I were seriously determined to but I am inclined to think that the payoff would not justify the effort - especially when there are much more valuable features and functionality I could be hacking away at with my time. I'll do some more rigorous Googling after the v1.34a build goes out and see what I can come up with. I can't be the only developer interested in using an already existing tool definition format, someone might have already done the hard part of deciphering it. There also might just be an official spec explaining the layout of the parameters in the .tool file that is just harder to dig up because 'tool' is a pretty common word in search results.

Oh I already found a bunch of .tool files, but they are not some kind of easy-to-decipher and/or modify text format, like say a post-processor usually is for some CAM software. They are some kind of special format for which a specification sheet might not have been released to the public yet. You could shoot an email off to Vectric though asking if they have a file format spec for .tool files though.

I can't find a file format specification that details how the data is laid out in .tool files with a cursory Google search but if one is out there then I don't see why I wouldn't allow loading tool definitions. PixelCNC only represents tools in a very simple way, however, and so there are tools which would not be possible to import - basically anything that performs an undercut or that has very unusual geometry. Otherwise most tools should be able to import just fine once I get all these other features implemented and can dig up a spec sheet on the ".tool" file format.

Oh, I totally forgot: I didn't even know a tapered ball-nose existed! I'll add that to the todo list and it should be in a future update - probably not this next one which will introduce the initial form of the canvas system but hopefully the one after that, along with some of the new carving operations and contour modeling stuff for creating projects from scratch directly in PixelCNC.


Thanks for your interest in PixelCNC! It's great to hear whenever someone is able to put it to good use :)

A few different users have inquired about a tool library/persistence type feature and so it has definitely been in the "adding-for-sure" section of the planned features list, for a few months now in fact. The situation is coming up with a clean and yet simple-to-implement means of achieving the desired result. There are still other big features that are going to take a bit of effort to get done so finding a solution for achieving a tool library system that is the easiest to do without totally sacrificing usability and intuitiveness is the goal.

I've been wrestling with a few ideas and for a while nothing seemed like it would work great in all situations, particularly when the user loads a project that has its own tool definitions which deviate from their library. At that point it seemed that having a legitimate tool library that the user can add/remove/edit the tools in is necessary. From there users can create a new project and either just directly load their library as a whole into their project, or individual tools into the project's tool slots. If they need to define a new tool that isn't in their library they can simply define it within their project and on the tool parameters panel.

The situation is that the tool library would consist of a list of tool definitions stored in their config file. When you're in the tools mode of PixelCNC you could click on a slot and there would be two buttons that appear on the tool slot itself: Load Tool and Save Tool. Clicking the load tool button would just pop up a dialog or menu of the user's saved tools which they could select a tool from to fill the project's tool slot. Alternatively, when they select the tool slot they'd still be able to define a tool on the right pane where the tool definition parameters are, after hitting apply to put the defined tool in the selected slot they could then click the Save Tool button and select a slot in their library to save the tool to - either an empty blank one or overwrite an existing one.

Lastly, there would be a button at the top of the tools list "Load Saved Tools" which would just fill the project's tool list with all of the saved tools. The only limitation to this system, as a whole, would be a finite number of tools that could be saved to the library - unless I took it a step further and had "primary" and "secondary" tools in the library, for power users (hehe). The primary tools would be the tools that a project's tool slots gets filled with when the user clicks "Load Saved Tools" to automatically fill the project's tool slots. The secondary tools would be backup, and they could swap those around with the primary tools as needed. The primary tools list would have the same number of tool slots as projects (10 tools) but the secondary tools list would be larger, if not unlimited. Just an idea.

I think that I'll be going with just having a tool library that is the same size as a project's tools list though, because it seems like it would make 99% of users happy that would prefer some kind of tool librar.y/persistence feature. It also is something I should be able to hammer out within a day, so that's a plus too.

Right now I'm hacking away at the new layer/canvas system and so far I have being able to load multiple images and position/scale/rotate them while changing how they are  each blended into the final 'canvas' off which toolpaths are generated. Next up I'm going to get support for models  working, so that users can load a 3D model into PixelCNC and actually see the geometry and rotate it around to whatever orientation and have it blend with the other layers. Somewhere in there I will get the tool library system setup too and then get another update out. After that I'll be adding more layer types for drawing 2D paths and placing OTF/TTF based text off which various contours and modeling operations can be generated. Then I have a handful of new cool new operations/toolpaths to add as well that I'm itching to get running and test out.

It's getting really exciting now! Thanks again for the feedback :)

(1 edit)

They are knobs that you click-drag up and down.

EDIT: You can also scroll the mouse-wheel over them to increment/decrement them through their value range.

The origin offset parameters control where the machine origin (i.e. x0. y0. z0.) is relative to the project's volume. You must press 'Apply' below the origin offset inputs in order to update the positioning of the project relative to the machine origin, which is depicted as a red/green/blue axis. If you want the front-left top corner then use an X/Y offset of zero percent and a Z offset of 100%. This is detailed further in the User Guide found in the Help menu.

Not bad! Now you just need to get in there with a small step size to clean it up :)

The free trial version has no time limit, but does not allow saving project files. If you have paid for the full version you own it now, which includes access to any future updates at no extra cost. Now that you've confirmed that saving the project prevents the export G-code crash I know that the fix I've put into v1.33a should work. I'm putting the finishing touches on v1.33a, mostly just updating the user guide, and then I'll be putting that out over the course of the day.

Feel free to share anything you create with PixelCNC that you carve on your machine!

I'm not sure exactly what is causing the crash but I have a pretty good idea. The same thing was happening to another user so I've added some new code to a build that I'll be putting out today which includes many other fixes and changes. It has yet to be tested and I've never been able to re-create the problem myself on any of my test computers. Try going into CNC/CAM settings and selecting the post-processor you wish to use just before exporting G-code. Keep an eye out for v1.33a which I'm putting out in the next few hours here after I tie up some loose ends and it should be fixed, but you should also be able to get G-code export to work with a bit of persistence. Also, try saving your project after confirming your post-processor, before you export G-code.

I made up a little hemisphere example to illustrate the effect leave-stock has on an operation's toolpaths. This is a 1" diameter hemisphere with 0.25" leave stock:

Hi, thanks for your questions. I see three things that will need changing: your leave-stock, cut depth, and min-depth are too large.

A quarter of an inch leave stock, for that particular project size and image means almost all of your project will leave nothing to be cut because the leave-stock effectively expands the project surface in all directions. If you have a perfect hemisphere,that is 0.5" in diameter, for example, and have a leave stock of 0.5" then the actual surface manifold which toolpaths will contour are limited to a 1" diameter hemisphere. The leave-stock imposes a margin in all axes, not just the Z axis. This way any vertical parts of the surface will also push the tool out away to ensure that there's stock left there. Start with a leave stock of zero just to get things working and increment it from there as you see fit.

Secondly, the cut depth is going to result in only two sets of horizontal cuts being generated. The horizontal milling operation generates sets of concentric cuts at 'cut depth' increments up to and including 'max depth'. So right now with 0.25" cut depth and project Z size of 0.5" it will try to generate cuts at the vertical middle of your project and then again at the bottom. The particular image you're using doesn't require much material to be removed as most of the features are all just below the top surface, with just a few pockets that actually go below 0.25", and with the 0.25" leave stock you had they pretty much just get removed entirely as cutting into the pockets would mean that 0.25" of stock isn't left in there between the cut and the surface your image produces.

The minimum depth parameter sets the depth-wise starting point for the cuts, relative to the top surface of your project (the max-depth similarly confines cuts to a maximum depth below the top surface). The minimum depth parameter functions as a cut-off point above which no cuts will be generated (except for engage/entry cuts), and with 0.25" you're preventing any cuts from generating in the top-half of your project. Set it to zero unless you have a reason down the road for cuts to be confined to the deeper parts of a project.

To help you get started I'm going to suggest trying a leave stock of 0.0, a cut depth of 0.1, and a min.depth of 0.0. Also, you might want to use a smaller step size, usually half your cutter diameter is perfect for horizontal operations. Start with that to get something happening and then play with changing different values here and there so you can get a feel for the way things are setup.

Not exactly sure why your simulation isn't showing anything - unless that's a screenshot from when there were no toolpaths generating (none are displaying so I imagine that to be the case).

Let me know how it goes!


Payout finally went through, thanks guys.

(1 edit)

Hello. Just curious what the situation is with payouts. I have one that's about to be been in review for 13 days in just a few hours, and another one that's been in review for  8 days. After imposing those retroactive payout fees out of the blue we were told we'd see a reduction in the amount of time payouts would be under review. I am not sure if I noticed much difference because review time can fluctuate (for whatever reason) but I've definitely been having payouts that have been pushing the "please allow 9 to 11 days" to the last possible few hours lately.

You are welcome :) If you haven't seen already I posted a tutorial/walkthrough on this forum, it should be stickied at the top. There's also a video tutorial I did up months ago that will need updating but it is a bit of an orientation and walkthrough, explaining various parameters in depth. I need to figure a better format for tutorial videos but I probably won't be making more until the summer time. I'll probably omit the in depth explanation and assume viewers have already gone through the first video tutorial. 

You are welcome. Let me know if you have any more questions/comments/concerns/etc and I'll typically be able to get back to you pretty quick.

Hey Gerry, this is a bug that was also reported recently and will be fixed in v1.32a, which will be out this week. The image is divided up into cells that are equal to the tool's radius but have a fixed buffer size for storing individual lists of contour segments.  With a small project size and a relatively large tool, complex images like this are divided into too few cells and throw a curve ball! For now you can increase your "path simplify" higher. I tested 0.35 and it works but the path isn't super smooth: 0.3 might work too. You'll also need to set your v-bit diameter smaller for small projects: the resulting toolpath will be the same so long as none of the features are wider/deeper than the specified tool. I tested it with 0.25" diameter v-bit, for a 4-inch wide project and it worked:

...or you can just wait until v1.32a this weekend and not have to worry about fiddling around with getting it to work. Have a good week!

Ah, I'm going to take a stab and guess that in your CNC/CAM settings you have min/max path length set extremely small and simplify turned down to zero? This could be the cause of both of the problems you're having. Let me know how it goes!


Also, please enable log extra info from the config menu and re-create the project from scratch as I mentioned on the other thread so we can get some more details about what is creating these issues.


Set your cut depth as deep as it will let you, and then limit the max depth to that value. It should limit you to the flute-length of your cutter, which is automatically calculated. What tool are you trying to generate a medial-axis carve with?

I'm going to have to have you send me this tigerhead image because I've never seen something like it cause so many problems!

Hi Dennis, I'm not seeing much that indicates the program itself is frozen in any way, particularly because it still appears to shutdown normally when you close it, which leads me to think something is interrupting it from accessing the program window for render output.

To help narrow it down I can have you generate a log file with more details about everything happening under the hood if you start up PixelCNC and go into the Config menu to enable the "log extra-info" option and then re-create the project again. This time send the complete contents of the resulting log file so I can see other aspects like GPU/system capabilities that may be playing a role in the issue. If you feel the need to remove any personal details like user directory path etc.. please just replace the characters with something else. Also, can you also show me the CNC/CAM settings you're using in PixelCNC?

One thing you might want to try, just to help narrow things down, is disabling GPU image convolution from the config menu too and then seeing what happens. But if you haven't had any problems previously then I'm wondering if it's a very specific situation with the project itself you're trying to create and not related to the image processing functionality utilizing the GPU. Could you also try a different project size, add an inch, shift the machine origin, etc.. so we can narrow it down between either this specific project or your specific settings/configuration? Thanks. There's a chance that you've discovered some kind of rare edge case with these exact project settings that gets something caught in a loop, or that is somehow stalling out the rendering context. A log file with debugging info will help us make a determination.

It's very curious that the statusbar says "...set toolpath done" because that's not actually something PixelCNC ever says in the statusbar, it looks like somehow "...set toolXX" after creating the cutting tool is being overwritten only over the end by "spiral toolpath done" and somehow becoming visible before your GUI stops refreshing. Interesting.

We should be able to get this squared away and get you running pretty quick. Have you been able to re-create this problem in any other way before or was it just with this specific project and these specific parameters/setup?


(1 edit)

You can set your machine origin relative to your project as percentages of your project's size. If you want your machine zero to be at the front-left edge of your project you'd use an X offset of 0% and a Y offset of 0%. The default is the center of a project, or X=50% and Y=50%, with the top of the project as the Z0. (Z offset = 100%). The red-green-blue axis lines you see in the 3D view are the machine origin (XYZ = 0,0,0) and change after adjusting the origin offset values and hitting Apply.

If you change your project size and/or machine origin after creating some operations you will have to go back and re-generate their toolpaths by hitting the Apply button on each one to get new toolpaths which are set to the project's new size/origin. This is something that's been on the table for re-working to make it easier for users to change without having to regenerate toolpaths manually.

Great! Let us know if you need help with anything else.

Ah, your tool is in inches but your project is in metric. Right now there's no intermixing of metric/imperial tools/projects.. It thinks your tool is 0.125mm in diameter. The same goes for your operation parameters - it looks like you have them all in inches but your project is metric.. When you change between inches/metric mode it changes everything in the program to one of the other, not just the project's dimensions.

If your cut depth and step size seem like they should work try turning down "path simplify" under CNC/CAM settings in the Config menu, as well as the "path min. length" parameter.

Hello Dennis, can you tell me what parameters you are using for your horizontal operation, and what dimensions your project and cutting tool are?

Dang! I'm always eager to hunt down bugs and issues like that to maximize reliability for everyone. If you manage to figure out how to re-create the problem, or any problem for that matter, let me know so I can chase down the problem. Right now I'm tackling the cut engage/entry modes that I've had planned for the last 6 months or so - both ramping down into a cut and also helically into pocketing/horizontal-milling cuts too. These new cut engage types will be limited to certain toolpath types as you can't always ramp into a cut if there's no way to get to it (i.e. material in the way that's not supposed to get cut). Especially when the user only wants the tool to cut in one specific direction, for instance. Then there's a few other little tidbits afterwards that I plan to get up and running before I dive into the canvas system. Stay tuned!

Thanks! Your feedback is much appreciated :)

Running PixelCNC under any kind of Windows emulation or virtual machine, or via other operating systems, is not something that's currently supported at the moment. It should be run on a machine that's running Windows natively for maximum compatibility and performance. Some users have had varying levels of success running PixelCNC from other operating systems via Windows virtual-machine or emulation but that is beyond my purview.

The majority of PixelCNC is developed with cross-platform compatibility in mind but due to the extra work that would be involved in setting up to actually build, test, and release Linux/Mac versions the implementation of CAM features/functionality and bugfixes currently takes precedent among the list of priorities. Cross-platform support is definitely on the radar but it could be another year before that comes to be a reality. Ideally this would be something to tackle either toward the end of the alpha phase or in the beta phase - and we're about ~60% the way to beta. The next big feature coming down the pipe is the canvas system, which will allow users to load multiple images/models simultaneously into one project and position/scale/rotate/etc them as individual elements on a single 'canvas' off which toolpaths are generated. That will mark the transition to beta.

With that said, I'm curious what images you're trying to load into PixelCNC that are causing a crash. If you could email them to we should be able to get that squared away pretty quick. :)

You'll have to manually open a command-line box and navigate to where you unzipped the TGA2STL exe file. Put your TGA images in the same folder to make it easier to use. You can also create a batch file that you can drag-and-drop TGA files onto that will automatically do the command-line work for you. In fact, I'm surprised I didn't include them in the Zip file. If you visit the TGA2STL github there are 3 batch files named 'high', 'med', and 'low' .bat. You can save those to your TGA2STL folder and then you will just have to drag and drop your TGA image onto whichever one you want, depending on the number of polygons you want the mesh to have (i.e. quality level).  You can also drag/drop TGA images right onto TGA2STL itself but you won't be able to control the quality level of the STL mesh it generates.