Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+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.

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

(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.