Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

iveniveniven

2
Posts
1
Topics
A member registered 45 days ago

Recent community posts

Dear Charlie,

thanks for the explanation! I just bought a license, since it is a really great software (...and trying to find settings that avoid a crash without the ability to save projects is cumbersome ;-))


I understand your reasoning, since I'm a software developer myself. Still, I would challenge it a little bit. Some projects where just not possible with hardware and software from 20 years ago. PixelCNC is a great example, where the image-based approach allows new things.

Maybe a possible solution could be to increase some limits with a factor that can be set by the user in the UI. The default is just "1" and wouldn't change anything for existing users. I have enough RAM, hard drive space and patience to wait - I'm happy to buy more RAM (even these days...) instead of reducing the quality of the generated paths. 

If that is not possible, maybe another form of error handling could be realized. With a meaningful error message before the crash (or within the log), I would know which part caused the memory overflow. Also, checking the available memory before allocating it could abort the operation before crashing and would allow me to tweak settings. If it would help, I could provide you with my setup, I assume that you have more debug messages than I have.

Until then, I will try your suggested solutions. 

Some questions about these: does the "toolpath simplification" run after completing the calculation? If so, I think changing these values maybe does not help, since the application already crashed.

Would you suggest to play with your mentioned values instead of dividing an images into smaller overlapping images?


Thanks and all the best,

Iven 

Hi Charlie,

I'm testing out PixelCNC for large images (8000x8000), large canvas sizes (1000mmx1000mm) and high canvas resolutions (300dpi). When I hit apply on operations, the program crashes. My workaround is to reduce the canvas resolution until it does not crash anymore.

Here are the last 10 lines from a log after a crash:

196.7273 toolpath_addpath: realloc toolpath[0] buffer: sz_verts[2690416] num_verts[1792269] (2778 verts)

196.7380 toolpath_addpath: realloc toolpath[0] buffer: sz_verts[4035624] num_verts[2690212] (2352 verts)

196.7528 engagepaths toolpath[0] subpaths 0->2403

196.7530 ...engage cuts generated

196.7532 engage cutz = 21.016001

196.7559 contouring 2405 paths... @z 14.000000->9.000000

196.8461 [ STATUS ] calculating Parallel Carving... -

197.0265 ...3345 polylines, 574116 verts

Are there ways to increase some limits of these calculations? If they are hardcoded (or caused by technical constrains),  what would be a good approach for e.g. parallel carving with small stepover values? Maybe divide the image into sub-images and calculate the operations separately?

Also, do you have a planned sale in the near future? I missed the one in July ;-)

All in all, I tried several different programs for these kind of things and PixelCNC is the best so far! :-)

Thanks and all the best,

Iven