Alright, it appears that the original problem is actually worse than I had originally suspected, and my attempt at correcting it with v1.11a was an attempt made in vain. It appears that in both your guys' cases Windows is limiting the amount of memory it's willing to let PixelCNC allocate for its buffers per the nuances and unique configuration of your respective systems. Admittedly, the buffers being allocated are oversized specifically to cover just about every usage case that it may encounter - without having to deal in constantly reallocating memory which can lead to memory fragmentation that can dramatically restrict the available memory (known as a 'fragmented heap'). This must be avoided at just about every cost, except that of simply being able to function at all! In the case of PixelCNC with the meshes requiring the fidelity they do, at least for toolpath generation, the number of toolpath coordinates and mesh vertices can be huge, in the majority of use cases. Even though the allocations are only on the order of hundreds of megabytes Windows is only willing to give up 1-2 gigabytes total, and depending on system configuration, existing memory fragmentation, and the alignment of the planets, this usually is closer to 1 gigabyte and is usually less. I haven't seen PixelCNC able to allocate a full gigabyte, in total, so the current buffer sizes are really pushing the limit and obviously have blown past it in the case of running on your guys' systems.
There is a bit of room for some optimization of the data structures being used but that won't solve the root problem. Only if the optimizations that could be made could drastically reduce the amount of needed memory would that allow the viable buffer allocations to just be smaller and then the problem would be solved. It is clear now that the fragmentation-avoidance strategy of allocating largest allowed buffer sizes has a flipside which entails that Windows will not function consistently across every machine, and so a more nuanced approach must be employed. Lesson learned.
The original plan was to implement a more concise and exacting memory management system down the road after seeing what kind of response PixelCNC generates but I'm just going to bite the bullet and hammer out a proper dynamic allocation system tonight, and have it uploaded by morning. At the very least I will bring the sub-systems responsible for the largest allocations to heel and only use exactly what they need as they need it. This requires that various tree and list data structures no longer point to exact absolute locations in memory, as the structures they point to can be moved to entirely new memory addresses once a reallocation occurs.
Properly solving the problem is a far cry from impossible, and isn't actually very difficult with a little planning and foresight. Nonetheless I am certainly caught off guard, but these are exactly the sorts of real-world problems that an early-access can tease out which otherwise go undetected by small time developers with limited testing capabilities, such as myself. As such, your patience is greatly appreciated. I'm excited for you guys to discover and explore what PixelCNC can do for you, and will see to it that you get the opportunity to put it to use.
Thanks!