Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


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

Creator of

Recent community posts

(1 edit)

The instructions for how to create/edit paths can be found via the question-mark button next to where it says "Edit Paths". There is also a complete table for all the editing controls in the User Guide.

EDIT: Yes, the grid is tied to the units. It tells you what your grid subdivision is set to in the status bar when you increment/decrement the subdivisions using the buttons on the view button bar.

(1 edit)

Create a paths-layer and then enable edit-paths mode.

EDIT: The UI is pretty much staying as-is, it's been under development for 3 years and while there are some things I wish I had in mind earlier during development the plan now is to finish the major features and get to beta sooner rather than later so we're going to go with a built-in help/tutorial/walkthrough mode that hilights what users must do in order to achieve different things. Have you looked at the included User Guide? It documents everything the UI exposes to users and explains a lot. It's updated for each released version.

Here's the steps leading up to the end:

...Then just increase the freshly created raster-layer's "Background Z" to be at the top of the canvas, and invert the layer (both on the right-side of the window when a raster-layer is selected) which results in the original image I uploaded. Then create a new operation just like the original one but when you generate a cut-path it will leave everything else alone and only generate cuts within the area masked off the rest of the canvas. You're just changing the contents of the canvas so that generating a cutpath won't cover the entire thing anymore. You might need to set your minimum cut Z depth to something like 0.001 depending on the operation, so that it doesn't generate cutpaths across the top of the canvas (which it might if min cut depth is set to zero).

There's currently no means of restricting toolpath generation other than with the canvas' volume. You can use a raster-layer to mask off areas of the canvas so that generating a toolpath only occurs in the un-masked area. Create a paths-layer and draw a path around the area you want to mask off, then use the Shapes From Paths function to create a flat shape. Invert the resulting raster-layer and change it's background Z to the top of the project, so you have something like this:

That's an idea. I do have experience writing recursive-descent expression evaluators so it won't be a hugely complicated task to add in there. What does the tab keypress do? In PixelCNC it jumps to the next editbox (which was requested previously by another user).

I think what might be useful for this sort of thing would be a medial-axis carving option that lets the user just manually set a fixed max-depth where the cutpaths don't vary in depth based on the width of the form and the cutter shape - like in the case with V-carving/B-carving. Instead, the cutter follows the medial-axis as with V/B-carving but just treats it like the profiling operation, where the user can toggle between varying cut Z to retain the shape of the form being carved, or if they just want a cutter to follow the medial-axis and specify a maximum radius/distance from the edges of a shape to allow it to travel - which currently is determined by the radius of the cutter itself. Hrmm, just thinking out loud. It would effectively allow the medial-axis carving operation to function like a profiling-along-centerline of the canvas' shapes and forms.

Ok, all systems go.

So the first option involves using the medial-axis operation. You could load the image as a raster-layer and then use the expand/contract function in raster-edit mode to beef it up (disable the "Expand Vertically" toggle on there to keep everything at the same height). Then invert the layer and generate your medial-axis carve off of that. You might need to raise the background Z height of the layer to the top of the canvas, if the canvas is larger than the raster-layer, otherwise the edges  of the layer will have cutpaths generated off them as well. This method requires manipulating the medial-axis operation via the cutter's geometry. You could just tell it to generate with V-bit geometry but actually use a different bit, like a ball-nose cutter or flat endmill.

Alternatively, you could trace the raster-layer to a paths-layer with a bit of a contouring offset so that the inner/outer paths generated are spaced a bit, and it will also resolve any little gaps there might be in the input image. Then you can use the Shapes From Paths with the paths-layer selected, or individual paths in the paths-layer selected while in path editing mode, to generate a flat shape, basically extruding the paths. You can profile off of these using the profiling operation then.

Here's an example project I just made for you to check out:

Profiling Example Project

Hi Eric,

 There's two options, I just tried to reply explaining them but this site hasn't been working very well on my end lately so I'm just testing being able to reply right now. Testing 123...

Hey that's pretty cool!

For the log files check the File menu, there's an option in there: "View Log Files" to get to the log files folder. Just keep in mind that after PixelCNC crashes and you launch it again the newest log file will be of the instance of PixelCNC that you're running at that moment while the one before that will be from the instance that the crash occurred during. So, the second-to-last, if you get to the PixelCNC log files by running it again after a crash and going to the File menu.

Also, when you intentionally invoke a crash be sure to enable logging of debug information from the config menu beforehand. It will have the log file be outputted with the most information possible. Just check to ensure that it's disabled afterward when you continue using PixelCNC or it can severely bog down performance due to all kinds of extraneous bits of information about program state being output to disk during computationally-intensive functions like updating  the canvas state and generating operations' toolpaths.

Life's been pretty good and busier than usual over here for us too :) 

Hey that's a good idea! Go ahead and start a thread and I'll sticky it at the top of the posts and add my own pics to it too. I aim to get the price up a bit further once we hit beta and move to a more professional website, and have better learning materials (tutorials, videos, etc.) Software without learning materials or "proof" of what can be done with it is a bit of a hard sale but judging by existing sales (without any legit advertising/promotion yet) there clearly there are people who can take a look at a piece of software and imagine what the possibilities are and know it's well worth the price.

That's rather confusing. You say that you commented the CodeRelative "G91" line from the post-processor but the G-code you're outputting doesn't even have a G91 in it - it's using the CodeAbsolute/G90. There's a G91.1 that's being included via the PrefixBlock but that's a different code altogether and only applies to arc/helical motion command coordinates (which PixelCNC doesn't generate yet, just linear feeds and rapids right now).

I have a feeling that what "worked" was something else other than commenting out the CodeRelative line, because that should have no impact on the G-code that's output. I'd investigate further and compare the G-code that is actually being generated. Compare a program generated with and without the CodeRelative line commented out in the post, because they should really just be identical  due to the CodeRelative variable not being referenced anywhere in the actual command block definitions. I'm inclined to  think that the problem might be the G91.1 that's included in the PrefixCodeBlock and that Mach3 controller doesn't know that it's a G91.1, seeing it as a G91 instead. ...but that doesn't explain how "initializing" the machine with a different program causes it to work even with the G91.1 still in there.


(1 edit)

There's a program you can use to check the capabilities of your graphics hardware, called 'GLview'. That will tell us right away if there's a limitation that's causing the issue, or if it's somehow something else - which is still a possibility. EDIT: I forgot to mention, the values you want to look at for your graphics hardware's OpenGL capabilities are "GL_MAX_TEXTURE_SIZE" and "GL_MAX_RECTANGLE_TEXTURE_SIZE". I'm thinking they might be capping out at 4096, which would make sense if going up to 120ppi for a 35" project because that will produce a depthmap that's over 4096px in the longest dimension, and get rejected by the graphics hardware. This is still just speculation but I'm 95% confident it's the cause. I already have a solution to that in place, so hopefully that's what's causing the issue.

The rest-machining will omit cutpaths that intersect areas removed by *all* previous operations, if they are "enabled" (the little paperclip button on an operation in the list when it's selected while in Project Operations mode).

I think I will add another toggleable option with the "link cuts"/"distance sort"/"rest-machining"  options for generating paths to tool-center or to the tool's radius. It shouldn't be too tricky ;)

I saw your other post just now about the G-code. I'll reply about that over there.

Hi Eric,

I have been doing experiments and have not been able to produce a crash increasing the DPI or loading a large image thus far. v1.43a has a hard limit of 400ppi on a project's canvas regardless of its size. I'm able to load an 8000x8000 PNG just fine over here on my desktop and laptop, I'll have to test on older system today. PixelCNC should automatically be limiting canvas pixel density depending on the physical dimensions of your canvas - mainly to keep PixelCNC from being completely bogged down by huge computation costs but if you're not seeing the message that limits the pixels/inch then something else is causing the crash. The intent on the PPI limit is to "guard-rail" users from making everything unnecessarily slow with computations that have no benefit on their final product. I've found that a project doesn't need higher than 100-150ppi unless its relatively small, like an engraving or tiny decorative art piece like an ornament, which is why the PPI parameter is there but users should strive to keep their canvas PPI as low as possible without sacrificing quality of the final product. Projects made on a tabletop router on the order of feet in size really aren't visibly different with a canvas beyond ~150 pixels/inch. Even high-end CNC routers barely hold +/- 0.005"  tolerances (equating to 200 pixels/inch) what-with all the flex and backlash present. I'm positive that any project you make on your machine will not be improved by going above 200ppi unless it's a coin with lots of small text engraved into it. At any rate, it shouldn't be crashing! I don't think you're even hitting the PPI limit for your project's size, in fact.

I believe that the issue is likely graphics-hardware related. I'm thinking it's simply not able to handle a large image for drawing to the 3D view with. I'm going to add some code to PixelCNC to query the graphics hardware for the maximum texture size and make sure it doesn't create any textures larger than that but I don't know for sure that is the issue at hand. One thing that might shed some light is if you create a project and then enable Log Debug Info from the config menu, and then increase the canvas pixel density to where it causes a crash. The log file it produces may have some useful information that helps to track down what exactly the crash results from. Just make sure you don't continue using PixelCNC with debugging info logging enabled or it will go extremely slow! I had a user forget that they left it enabled when we were chasing down a bug that they were experiencing and it was really worrying for them that it took 5 minutes to generate a cut path which used to only take 5 seconds!

In the meantime you could also try decreasing canvas quality in the View Settings. This only affects the rendering of the canvas and does not impact the quality of toolpaths generated - it only degrades the visuals, not the actual fidelity of the geometry that toolpaths are generated from. If that resolves the crash issue somewhat (allows you to use a higher canvas pixels/inch for given canvas dimensions than before) then it's likely a graphics hardware issue that I should be accommodating for by capping the size of image data offloaded to it for rendering.

As for the rest-machining functionality it simply clips an operation's generated cutpaths to whatever remains of the stock material after previous operations have been performed. Anywhere the previous operation didn't reach, because of a cutter too large for smaller areas, or a leave-stock that results in a layer of material for a finishing or re-roughing pass to get at, is a good candidate for a rest-machining op to follow. Rest-machining in PixelCNC is to prevent operations with a cut-depth that's a fraction of the max-depth from cutting-air wherever material has already been removed.

Also: dDid you figure out the G-code post processor situation?  I'd like to be able to include  compatibility with that controller's dialect in the Mach3 post on the next release. I get the feeling it has something to do with the order of commands being issued, and not so much that something's missing. It's an interesting problem :P



(Tried to reply yesterday but this site was broken, hopefully it works now)

Hi Eric! Thanks for sharing feedback. I too come from a precision machining background so I understand where you're coming from. Glad to know I'm not alone ;)

Well I've got good news: you can set the machine-origin, or "zero" for the XYZ  axes, to anywhere within the canvas' volume. PixelCNC defaults to using the top of the canvas. If you want to set it to the bottom of the canvas you can just change the origin Z percentage from 100% to 0%, or type "0" in the "Z Origin" editbox in a project's Canvas Properties.

Here's after changing the origin Z knob from 100% to 0%, in lieu of having to type a front-left-bottom relative coordinate in the XYZ origin editboxes, which you can do instead if you prefer) and hitting Apply.

The machine origin is retained and re-used whenever you create a new project, between PixelCNC sessions or otherwise. If you set it to X:50%, Y:50% and Z:0% on a 3"x3"x1" ?project it will be set to the bottom-center of any project, no matter the size of the canvas.

...and yeah, your point about the canvas and tool center is totally valid. The "canvas" is not meant to represent your stock material, it's just the volume within which cutpaths are generated. If you don't want your cuts to ever go deeper than 0.5" then make your canvas 0.5", etc.. If you have a 2" wide piece of stock that you want to cut the entire top of then set your canvas to 3" and add some margin in there. I could definitely add some functionality for it to automagically border the canvas with the tool radius for each operation when generating cut paths, as a toggle option for either the canvas or each operation individually. I'll make a note of that and look over the code to see what has to be done to make that a thing, because it's a good idea that I'd like to have in there myself now that you mention it.


 - Charlie

Couldn't post here  or reply to my customers yesterday, testing if I can yet.

Great feedback! I was definitely considering an "auto-fill" button or option under CNC/CAM Settings that would just fill new projects with the first 10 cutters found in the library. Alternatively each tool in the library could just have a toggle for auto-adding to new projects, so that you can have a library of tools but only a few regularly-used ones that you want to be included in a new project by default. Glad to hear confirmation that it's worth pursuing :)

What other tool types are you thinking should be added? Be forewarned: PixelCNC won't be able to do any kind of under-cutters just by the nature of it's core algorithms that everything is built upon - and all the stuff that is built out of them them would need a re-write. This was by design from the outset because it enables fast toolpath generation and CNC simulation by simplifying everything down to just a 2D field of height/depth values that conventional (and some custom-engineered) image-processing algorithms operate on.

So if you have any other cutter geometries in mind that I haven't included, or that can't be achieved with the existing tool types, I'd love to hear about them!


Hey, that's a really great site for grabbing heightmaps!

Oh I see, it's drifting off to the side indefinitely. It could be that it's somehow not switching to absolute coordinates, so each absolute X coordinate just sends it off further and further down the X axis, in spite of the G90 that the Mach3 post includes at the beginning of the G-code. Maybe the controller is expecting it with some other G/M codes somehow. It seems like it could just be something finicky with the controller like that. Whatever it is I'd really like to know what it is and work in a fix - understanding the what/why of it.

It could very well be something else too, like the G40. There's no telling what the issue is without some trial-and-error just messing around with it. It could even have something to do with the lack of a "start read" character, the % line. I'd suggest trying removing that first line from the  working G-code and see if it still works, or if its presence is inconsequential.

PixelCNC's posts are relatively simple, I tried to keep all the cruft out and avoid over-complicating anything with features and vernacular nobody ever uses 99.99% of the time. The most complex part are the codeblock definitions at the bottom where it references different variable names/states within the block's string of characters. You could really just directly replace PixelCNC's program prefix codeblock with the one that works for you, but knowing why the Mach3 post isn't working with your 6090 controller would be much more useful to others in the future. That way I can work in a fix without breaking Mach3 support for other controllers that the posts already work for.


Hi Eric, thanks for the feedback! What controller are you running exactly?

I think it might be the addition of the G40, which disables cutter compensation, that might be what you're needing with your controller. I'll throw that into the Inch/Metric posts for the next update if you could try adding it to the beginning of a fresh PixelCNC mach3 G-code program and see if that solves the issue you're seeing.

Any discoveries to share creating specular holograms using a laser?

I did find some posts from the developers of WINE that explain why multithreaded OpenGL applications don't work very well unless they employ a very specific method for initialization. I might be able to get PixelCNC at least running under WINE - at the very least - so there is hope! Otherwise I'll be working with a friend to port it over to OSX and Linux - most of which should go pretty smooth but there are some Windows-specific API calls being made only because there wasn't a usable cross-platform method to achieve the same result (like the open/save file dialog boxes for loading/saving projects, exporting G-code, loading layer input media, etc as well as the color-choose dialog for customizing the view/UI appearance. There's a few other windows-specific things that will need changing but in the meantime there's a chance I'll be able to at least get it running reliably under WINE. I'll try a few things in the code for v1.43a that you can test out and see how it fares.

Alright, here's a re-creation of the other hologram that I linked to the G-code for. There's two versions, one that is made up of line-segments, and one that is made up using SVG's native cubic bezier curves.

Hologram Segments SVG

Hologram Curves SVG

Keep me posted!

If you can get the laser to produce a reflective surface within the groove it should work. The ideal tool is something conical with a very tiny radius at the tip, something like 0.002" so that there's a nice concave and self-polished surface within there. There are two sample/example G-codes generated from Holocraft that you could try. They are identical in terms of the hologram they produce but one uses strictly G1 feed commands while the other utilizes arc-feeds instead (someone was curious about the difference so I created these to show them).

Here's the links to the G-code produced: 

Hologram Segments

Hologram Arcs

Let me know if an SVG of the groove optics would be better than G-code for you to test out. I'd love to see what kind of results you can manage w/ a laser :)

Hi Scribs, thanks for your interest in PixelCNC!

There's tentative plans to port PixelCNC to Mac and Linux. You're not the first person to ask about a port though so it's clear that there is a bit of demand for them! It likely won't be at least until toward the end of the year, at the very soonest, after all the planned features are implemented and bugfixes and polish are about all that's left to be done. I don't own a Mac or have any experience developing for/on one so that would be a bit of a project unto itself though a friend of mine has some experience and might be able to take care of at least a Mac port, so it's not something that's completely out of the realm of possibility. I may have to figure out the Linux port myself, with my minimal experience setting up and maintaining crypto mining rigs :P

You can check out the PixelCNC devlog where I document all of the new features/functionality/changes/bugfixes with each release and add yourself as a follower to be notified when I post about new versions. I title posts with the most pertinent aspects of each version released, so you should be able to see at a glance whether or not a new version includes ports for other platforms without having to actually scour the post's contents. New versions are released every 2-3 months typically, so you'd likely experience just a handful of notifications before a Mac port comes around.

Otherwise I'd suggest just checking back here every few months. We'll be moving from over to in a few months but this page will still exist at least just to point people to the new site once it's all setup, and possibly continue serving as PixelCNC's online community.

Thanks again! :)


Fixed it! I went ahead and re-created the test case that fails to generate a correct toolpath in v1.42a in previous versions and found that rest machining  worked fine there. I was then able to deduce that there was a code change from v1.40a to v1.41a that was missing an additional line of code that was needed, resulting in rest machining being broken in certain situations.

I'm working on some new canvas editing functionality at the moment and once they've been knocked out v1.43a will be rolled out, including the fix for the rest-machining bug.

Thanks again for the bug report!


Hi Mike, thanks for taking the time to figure out how to reproduce the bug you've found, that saves the trouble of the back-and-forth with users to get to the actual cause of the problem. I'm able to recreate what you're seeing over here with the instructions you've provided so I have a good specimen to work with now.

I have an inkling that somehow the rest-machining is confusing the feeds and rapids, where a rapid has attached to it a retract-to-safe-Z move, then  the actual rapid to the next cut's XY, followed by a feed/engage move to begin the cut, but if it's flagged as a "feed" it doesn't generate the retract, rapid, or engage moves and instead just treats it like any other feed move. It could very well be something entirely different, maybe in some of the geometry logic that "cuts out" the area that's already removed by previous operations from the generated cut paths that should only cut where there's still material.

In either case I'm on it! I'll let you know once I've squared it away and the fix will be rolled out with the v1.43a release. In the meantime feel free to let me know  if you have any questions, suggestions, feedback, or come across any other issues that need to be looked at.

Thanks again :)


If you're logged into (which you should be if you're able to post to this messageboard) then there should be a bar visible at the top of the Holocraft page that is captioned with "You own this tool" and a download button that will show you the current downloads owners have access to. This is what it should look like:


Had texture mode working about a week ago, but spent time tweaking and tuning everything else (as one does). v2.3a is up!

Finally released PixelCNC v1.41a. I'm working on Holocraft's texture feature now. Should have an update released in the next few days!

(1 edit)

I'll probably have v1.41a out either tonight or tomorrow, working on updating the User Guide right now so that it reflects the changes that have been made to the interface and overall program behavior. If all goes well (I don't stumble across a terrible bug that takes a week to fix) then you'll be able to test DXF files yourself this weekend instead :)

If you do come across any that do not load properly send them this way and I'll get things smoothed out for v1.42a. Thanks!

Sorry about that, I've been very busy with PixelCNC. I'll make it a point to get the texture function running in Holocraft once PixelCNC v1.41a is out the door. It should be done over the coming week or two. I'm currently hacking away at adding DXF import support, and it's a bit of a tricky format, but once it's in there I'll dive back into the Holocraft codebase and get that all squared away for ya. :)

Any new holograms to show off?

Hi again, do you have a relatively small/simple DXF sample I could work with? I want to see how different DXFs can be and make sure PixelCNC will be able to handle a range of DXF structures reliably.

I totally understand where you're coming from but unfortunately it's just not in the cards this time around. If it were something I could pull off in a week then I'd be up to considering it as a possibility. As it stands, due to the inherent limitations of PixelCNC's core systems any given XY point on the canvas can have only one corresponding Z coordinate. As as a result there is no way to cleanly or easily add any kind of functionality for designing or calculating toolpaths for any kind of overhangs. This applies to the simulation system and cutter geometry as well. Everything is built around a simple 2D representation where each point can have a single Z coordinate tied to it.

The best I can do is add a new entry-cut mode to the profiling operation which instead approaches cuts from the side, rather than from above, but you'll still be defining your router bits as one of the existing tool types and simulating it without being able to see what the final result will actually look like in the simulation, but the resulting toolpath should be perfectly usable with a router bit (assuming that your toolpath parameters are correct and it doesn't try to approach the toolpath wrong or move too far into the material).

As for actually giving the user the ability to model cutters or features on their project's canvas that cannot be represented using a 2D heightfield function it's just not going to happen without spending months of time gutting tons of code and re-writing it to work with a new canvas representation - including all the toolpath generation algorithms. That's time I just don't have, unless you'd be willing to start paying me a full time salary to work on it. I've already set my sights on getting PixelCNC to beta this summer for over a year now (and it's already going to be really tight as-is) so that I can finally switch to PR/marketing mode and begin generating an income for my wife and kids.

In the meantime, I still have at least half a dozen new toolpath types I plan to incorporate which will allow for some cool new stuff, and a bunch of canvas layer editing functions, along with built-in tutorial/walkthrough modes and a system for orienting new users with the interface.

Ah, I see. The plan has always been to import a file as a single layer. I hadn't looked into DXF too much yet to be aware of the fact that they internally had "layers" for delineating groups of paths/shapes. I'll make sure there's an option for separating a DXF's layers into their own paths-layers in PixelCNC. I did decide to squeeze DXF support into v1.41a before releasing it. I don't know how long it will take to get it in there but I imagine no more than a week's time with the other things I wanted to get in there too. Thanks for the headsup!

There might be a way that you can get PixelCNC to output G-code for a 4th axis by creating a custom post processor and doing some trickery with changing the Y axis to the rotation. Using the scaling factor you can map the Y dimension of the project to 360 degrees. So if you make a project that's 6 inches long in the Y dimension you could set a scaling factor to 6.0 for the Y dimension and change the register label in the post from Y to A (IIRC that's how you specify 4th axis angle?). I think it could be done, I'd be interested to find out if someone can pull it off.

I've already been working on PixelCNC pretty much full time for about 2.5 years now and my goal is to get it to the point that I originally envisioned, at which point it will enter beta phase and I will switch gears to PR/promotion/marketing mode. The goal is to expand it into a full income by the summer time. We'll see! Thanks for the feedback :)

(1 edit)

DXF import is something still being worked on at the moment, perhaps I'll try to squeeze it in before v1.41a goes out. But yeah, the individual shapes will be separate within the layer but only individually accessible while in path-editing mode. You can select individual paths and copy them to their own layer and generate stuff off that layer - or select each shape/path individually and generate shapes off each one while it's selected instead of copying them to their own layer and generating shapes from them.

Here's an example:

EDIT: Also, I suppose I could include an option to create one layer for each individual path that's loaded from vector file types.

We'll see! A lot of the things I had planned for v2.0 ended up being incorporated into the existing version "just because" but I do have tentative plans for creating a DIY 5-axis with accompanying full 3D CAM, with the goal of making CNC almost as easy as 3D printing. I also have other projects I'd like to do too so only time will tell :)

There is no plan to support anything other than 3-axis milling/carving.

(1 edit)

PixelCNC generates all toolpaths from the canvas, which is composited from different layers. Vectors can be imported either as a raster-layer or as a paths-layer. Different 3D shapes/forms can be generated from a paths-layer (using "Shapes From Paths" when a paths-layer is selected). There is no direct conversion from a vector to a toolpath.

Ah, yes, there's no plan to add support for the kind of cutting geometry that router bits entail specifically because PixelCNC's toolpathing and CNC simulation engine - and the core systems they're built on - operate on the assumption that for each XY point on a project or cutter there is a single corresponding Z coordinate, as opposed to multiple Z coordinates.

PixelCNC has always been intended for 3-axis milling/carving the "top" of a project - where cuts are entered/exited vertically, as opposed to entering and routing along edges from a sideways approach. However, I might be able to at least add some kind of support for another cut entry method - which would allow a toolpath to approach a cut from a distance away and move inward to the cut along a fixed Z, as well as retract at a fixed Z a specified distance before rapiding to the safe Z level. Then you  could just define a generic endmill to generate the path with. I can't promise this will even be a thing as I already have plenty on my plate and hope to get to beta before summer but I'll keep it in mind :)

Hi again! I'm curious about your custom tool shape suggestion. Could you provide more details? What kinds of parameters or means of defining a tool are you imagining? A quick diagram would be great, or links to a few different cutters that you'd like to be able to define and perhaps I could come up with a means for users to articulate them to PixelCNC.

As for the tool holder itself: I do plan to show the actual holder/chuck for the very purpose you indicated, and also to perform automatic intersection tests to show the user if they might have problems with certain cuts that are deeper than the length of the cutter. This would basically operate the same way as the existing simulation system but almost as a secondary tool that's larger and at the top of the actual cutter, showing red areas wherever it "crashes" into the workpiece - which would be whenever the cutter has cut deeper than the distance from tip-to-holder. There's no telling when this feature will be in but hopefully within the next few months. The todo list is still rather long just to get us to beta but this is definitely a feature that's on there :)