PixelCNC Has Moved: deftware.org

CAM software developed by artists for artists to create unique and original works on a 3-axis CNC router or mill. · By Deftware

Add to collection

tool Community Devlog

PixelCNC Has Moved: deftware.org community

Abort ongoing toolpath generation?

A topic by QRUXEL created 9 days ago Views: 43 Replies: 4

Viewing posts 1 to 3

QRUXEL9 days ago(+1)

Hi,

Quite new to PixelCNC, but I like it - even though I am probably far from the optimal use-case for a software like this, I mostly use it to cut out 2.5D parts from large sheets on our full size CNC.

One of my main "pet-peves" is that I quite often find myself in a situation where I quickly realize that I should have had "inverted" checkbox clicked, and have to wait for a long time for toolpaths to generate - and sometimes this can take minutes if I have a small stepover size and it wants to fill large areas.

TL:DR; Is there a way to cancel the current toolprocess generation?`

Another quite annoying thing is the wierd keyboard handler. I use a swedish keyboard layout and our "+" is in the same location as the us-keyboard "-" (minus/dash), and our "-" key will output a "/" in the software. Beeing a developer myself, I must admit I'm more baffled over why the software needs it's own keycode/press management? could you maybe shed some light on the issue you faced when deciding on going this route?

Best regards, and thank you for an amazing software for a reasonably price.

Ludvig
Qruxel Productions,

DeftwareDeveloper9 days ago

Hi Ludvig,

Unfortunately at this time there isn't a way to interrupt the toolpath generation. One idea is to temporarily keep your canvas resolution somewhat lower while you are creating your operations, then increase the canvas resolution to where it's needed and re-generate your toolpaths after all of their parameters have been figured out. This way if you make a mistake with your toolpath parameters it will not take a long to generate the toolpath, being at a lower canvas resolution. The toolpath generation is spun off on a background thread and what we will need to do in order to allow aborting toolpath generation is to go through each toolpath generation function and sprinkled abort checks throughout to determine if the function needs to stop what it's doing and then cleanup everything that has been allocated up to that point before bailing out. It's not too much of an undertaking but there are other things that currently have higher priority that are being worked on. The todo list is ever-growing and very long!

It's a known issue that the keyboard input is hard-coded for American QWERTY keyboard layouts, this is something that will require a substantial rework of the entire user input system. The input system was largely borrowed from an old game engine project that was written 15+ years ago, and that only needed minimal user interface functionality. The way PixelCNC stands right now it's more likely that the entire program will just be re-written from scratch to fix that issue, and a few other issues that are "deep" in the code. PixelCNC was originally a personal project intended for personal use that wasn't meant to see the light of day, so some of the early decisions made in its development did not take things into account like the possibility of someone else with a different keyboard layout using it, or any kind of localization capability.

Thank you for your questions and words of praise! Let me know if you have any other questions or need help with anything else :]

- Charlie

QRUXEL8 days ago(+1)

Ah, I see.

Could you perhaps explain the relationship between DPI of canvas, quality setting and supersampling setting? I mostly import stl files and trace them to paths - but I've noticed that quite often I need to increase the DPI higher than it allows me (and I've learnt the hard way not to auto-press "yes" on that pesky popup that reverts back to factory settings whenever I hit the ceiling) - in order for the outline toolpath to realize that the tool diameter does indeed fit inbetween two objects. I assume this has to do with edges not lining up exactly on edges? So basically - with a monster computer (running on a 48 cores, Nvidia 5090 GPU, 128gb ram) - what are the important settings to keep in mind? keep in mind I'm mostly using 2500x1200mm sheets (~8x4feet).

I also have had my fair share of projects "made for me - by me" that got traction and had me rewamp the whole project instead of trying to maintain an unmaintanable code-base, so I know it sucks - but you have the most difficult part already worked out: the scope of the software. When the scope is set, it's much easier to build a sustainable codebase around it, especially with the tools that are available today. Not saying you should "vibe-code" it, but using ai tools to build montonius tasks from your own clear requirements is like having a team of lighning fast junior developers - you still need to check the code it produces, but you can focus on the overall structure and quality aspects. My two cents if you decide to go that route is that having the ui seperated from the core functions is usually the best way to making it maintable in the long run. I understand that it might not be that easy since I assume that a lot of the tracing is actually taking place in the game engine itself.

DeftwareDeveloper7 days ago

Hi QRUXEL,

The honest truth is that PixelCNC's heightmap based setup is just not ideal for large projects, because it entails processing huge heightmaps for anything that needs high resolution.

The canvas resolution is going to be the absolute resolution that canvas compositing and any kind of shape generation happens at. It is also the resolution that cutpaths are generated from the canvas at. That's not to say that cutpath coordinates are limited to that resolution, but instead that the shape/dimension of things contoured will be limited to that resolution.

The model supersampling factor is how many effective pixels that a 3D model is rendered at, relative to the canvas resolution, when PixelCNC is internally generating a heightmap from a model-layer. So if your canvas resolution is 200ppi and your model supersampling is set to 9x, then model-layers will be rendered at 600ppi (i.e. 3x3 model rasterization pixels per canvas pixel). The model supersampling is there for antialiasing purposes, so that model geometry doesn't result in jagged aliased edges when compositing with the canvas (for toolpathing or any other contouring-related functions). If accuracy and dimension of features is important then I would crank up the model super sampling as high as it will go.

So PixelCNC is currently 100k lines of code, not counting whitespace lines or comments. It was originally much simpler and my ideas for a v2.0 that was meant to be written from scratch ended up just getting somewhat shoehorned into the original v1.0 codebase. It's a lot of bespoke code that there is not going to be anything any LLM would've gleaned from the web about, as opposed to a project that more so just glues a bunch of libraries together through their various APIs. I don't have the time to sit down and start trying to hold an LLM's hand trying to see if it will ever understand PixelCNC's code base enough to be able to do anything worthwhile with it. For boilerplate I'm hearing the LLMs are great, but I am highly doubtful that they'll be able to do much with a 100k line codebase written in C that facilitates extricating all of the issues that are basically a part of its DNA, only because those decisions were made very early on at the outset.

I appreciate the suggestion but at the end of the day PixelCNC just needs a complete and total re-write from scratch that actually accounts for things like localization, keyboard layouts, etc. It is the way that it is for the foreseeable future, unless someone wants to come along and start paying me a livable income to develop it into a more solid product. Nowadays I am earning most of my income from making custom signs for clients and just don't spend much time at all sitting at the computer like I could back in the heyday of PixelCNC's development. I'd love to get back into coding again but it just doesn't pay the bills. :P

Thanks again, and let me know if you have any other questions or need help with anything. Have a good rest of your weekend! :]

- Charlie

QRUXEL7 days ago (1 edit) (+1)

Yeah, I kinda figured - and I said in the first post - I'm well aware that I'm probably far from the usual use-case that this softare was intended for =)

Anyway, I bit the bullet and spent the day learning the CAM inside FreeCAD. Struggled a lot, but finally managed to write a macro that makes it possible for me to do what I want (basically; pocketing that is able to use the gap between parts, something I did in pocketCNC by merging an offset path of the part with the pocket outline).

So, I'll continue to use PixelCNC for any 3d reliefs in the future, but for now I have a more suited workflow for this specific usecase.

And to clarify, I also agree that trying to load an existing codebase into an LLM isn't (at least not yet) a feasonable idea as it will clog the context space. I meant to use it more for boilerplating and to help you get going with a new codebase - but I totally understand that it's not what pays the bills. It's a shame though, considering the price that Vectric charges for their software - it's clear that the market is in dire need of some competition =)

Anyway, good luck and again - thank you for you work.

itch.io

PixelCNC Has Moved: deftware.org

Abort ongoing toolpath generation?