Hi,

I downloaded the newest version and am unable to load an image (nothing loads in the UI). I thought I'd try to delete the log file for the old version but can no longer find it under appdata. Any ideas?

Found the pixelcnc folder in appdata and deleted the log file but the program will not load any images. Below is the error and log file output.

0.041 0.042  [ PixelCNC v1.11a - Feb  5 2018 ]
0.042  [ Charles Van Noland - deftware.itch.io/pixelcnc ]
0.042 0.042 --- initializing ---
0.042 configuration...
0.042 ...loaded configuration
0.042 system...
0.110 8 logical cpus detected
0.110 >> starting thread00...
0.111 >> starting thread01...
0.111 >> starting thread02...
0.111 >> starting thread03...
0.111 >> starting thread04...
0.111 >> starting thread05...
0.111 >> starting thread06...
0.112 >> starting thread07...
0.112 >> starting thread08...
0.112 >> starting thread09...
0.112 >> starting thread10...
0.112 >> starting thread11...
0.112 >> created mutex #0
0.112 >> created mutex #1
0.112 image...
0.112 >> created mutex #2
0.113 input...
0.113 render...
0.114 >> render_init: allocated 416.00mb vertex buffer
0.115 GL_VENDOR: Intel
0.115 GL_VERSION: 3.0.0 - Build 20.19.15.4549
0.115 font drawing...
0.116 loaded ".\fonts\system.png" (256x128@4)
0.117 ...loaded font "system"
0.118 loaded ".\fonts\fixedsys.png" (256x128@4)
0.118 ...loaded font "fixedsys"
0.119 loaded ".\fonts\source_code.png" (256x128@4)
0.119 ...loaded font "source_code"
0.120 loaded ".\fonts\latha.png" (256x128@4)
0.120 ...loaded font "latha"
0.122 loaded ".\fonts\latha_big.png" (512x256@4)
0.124 ...loaded font "latha_big"
0.125 loaded ".\fonts\tahoma.png" (256x128@4)
0.125 ...loaded font "tahoma"
0.127 loaded ".\fonts\tahoma_big.png" (512x256@4)
0.128 ...loaded font "tahoma_big"
0.129 loaded ".\fonts\verdana.png" (256x128@4)
0.129 ...loaded font "verdana"
0.131 loaded ".\fonts\verdana_big.png" (512x256@4)
0.133 ...loaded font "verdana_big"
0.133 loaded ".\fonts\ocr_a.png" (256x128@4)
0.134 ...loaded font "ocr_a"
0.135 loaded ".\fonts\ocr_a_big.png" (512x256@4)
0.136 ...loaded font "ocr_a_big"
0.137 loaded ".\fonts\icons.png" (256x128@4)
0.137 ...loaded font "icons"
0.139 loaded ".\fonts\icons_big.png" (512x256@4)
0.141 ...loaded font "icons_big"
0.141 view...
0.141 mesh...
0.141 >> mesh_init: allocated 1.38KB meshes array
0.141 >> mesh_init: allocated 36.00mb polyline verts array
0.141 toolpath...
0.146 cam...
0.146 >> created mutex #3
0.146 project...
0.146 tools to metric defaults
0.146 gui...
0.147 0.0mb allocated
0.147 --- entering main loop ---
0.228 >> unts:2 scale:0.039370,2.000000 subdiv:0.100000
0.229 >> r_modelnew 0
0.231 created model: 1 draws, 1260 verts
0.231 >> axis regen 25.400000
0.232 >> r_modelnew 1
0.233 created model: 1 draws, 6 verts
17.731 loaded "...Downloads\Tarrot 1.jpg" (570x713@3)
17.735 >> setting project input...
17.788 >> laplace
17.998 >> img_scalarblend: 570x713, 570x713, 1.000000x1.000000
18.037 >> project_updatetexture done
18.037 >> simulation depthmap size: 901x1127
18.041 >> img_scalarblend: 570x713, 570x713, 1.000000x1.000000
18.058 >> halving 570x713 (1608.7 ppi)
18.059 >> halving 570x713 (804.3 ppi)
18.059 >> halving 570x713 (402.2 ppi)
18.059 >> halving 570x713 (201.1 ppi)
18.059 project pixels/inch = 100.5
18.060 >> r_modelnew 2
18.062 created model: 6 draws, 24 verts
18.062 >> project_setinput done
18.064 >> generating input image mesh...
18.065 >> getting corner verts...
18.065 >> downscaling input image... 142x178
18.244 >> blending downscaled image...
18.245 >> img_scalarblend: 570x713, 570x713, 1.000000x1.000000
18.267 >> dividing up mesh...
20.084 >> setting triangle apex verts...
20.294 mesh_fromimage: created bitree mesh, 2186470 nodes (2.230001 elapsed)
20.304 [ ERROR ] malloc: failed to allocated 67108864 bytes
73.079 [ ERROR ] r_modelnew: failed to allocate vertex position buffer

I am having the same issue as Bill.  The GUI will load but it locks up everytime I try to load an image, a very small image.

Donnie

Here is my log.txt

0.149 
0.174  [ PixelCNC v1.11a (Trial) - Feb  5 2018 ]
0.182  [ Charles Van Noland - deftware.itch.io/pixelcnc ]
0.188 
0.194 --- initializing ---
0.204 configuration...
0.230 ...loaded configuration
0.235 system...
0.382 4 logical cpus detected
0.387 >> starting thread00...
0.391 >> starting thread01...
0.396 >> starting thread02...
0.401 >> starting thread03...
0.406 >> starting thread04...
0.411 >> starting thread05...
0.416 >> created mutex #0
0.421 >> created mutex #1
0.425 image...
0.430 >> created mutex #2
0.434 input...
0.438 render...
0.450 >> render_init: allocated 416.00mb vertex buffer
0.459 GL_VENDOR: Intel
0.463 GL_VERSION: 3.0.0 - Build 20.19.15.4549
0.468 font drawing...
0.476 loaded ".\fonts\system.png" (256x128@4)
0.485 ...loaded font "system"
0.492 loaded ".\fonts\fixedsys.png" (256x128@4)
0.499 ...loaded font "fixedsys"
0.504 loaded ".\fonts\source_code.png" (256x128@4)
0.512 ...loaded font "source_code"
0.517 loaded ".\fonts\latha.png" (256x128@4)
0.524 ...loaded font "latha"
0.534 loaded ".\fonts\latha_big.png" (512x256@4)
0.543 ...loaded font "latha_big"
0.554 loaded ".\fonts\tahoma.png" (256x128@4)
0.563 ...loaded font "tahoma"
0.576 loaded ".\fonts\tahoma_big.png" (512x256@4)
0.583 ...loaded font "tahoma_big"
0.591 loaded ".\fonts\verdana.png" (256x128@4)
0.597 ...loaded font "verdana"
0.609 loaded ".\fonts\verdana_big.png" (512x256@4)
0.621 ...loaded font "verdana_big"
0.629 loaded ".\fonts\ocr_a.png" (256x128@4)
0.637 ...loaded font "ocr_a"
0.650 loaded ".\fonts\ocr_a_big.png" (512x256@4)
0.658 ...loaded font "ocr_a_big"
0.669 loaded ".\fonts\icons.png" (256x128@4)
0.677 ...loaded font "icons"
0.689 loaded ".\fonts\icons_big.png" (512x256@4)
0.697 ...loaded font "icons_big"
0.705 view...
0.711 mesh...
0.717 >> mesh_init: allocated 1.38KB meshes array
0.726 >> mesh_init: allocated 36.00mb polyline verts array
0.731 toolpath...
0.738 cam...
0.748 >> created mutex #3
0.754 project...
0.761 tools to inch defaults
0.768 gui...
0.773 0.0mb allocated
0.779 --- entering main loop ---
1.324 >> unts:1 scale:1.000000,0.250000 subdiv:1.000000
1.339 >> r_modelnew 0
1.364 created model: 1 draws, 400 verts
1.368 >> axis regen 1.000000
1.381 >> r_modelnew 1
1.406 created model: 1 draws, 6 verts
14.871 loaded "...images -\texas a&m.png" (248x196@3)
14.879 >> setting project input...
14.937 >> laplace
15.146 >> img_scalarblend: 248x196, 248x196, 1.000000x1.000000
15.166 >> project_updatetexture done
15.176 >> simulation depthmap size: 1151x909
15.183 >> img_scalarblend: 248x196, 248x196, 1.000000x1.000000
15.192 project pixels/inch = 41.3
15.206 >> generating input image mesh...
15.216 >> r_modelnew 2
15.223 [ ERROR ] malloc: failed to allocated 335544320 bytes
15.247 created model: 6 draws, 24 verts
15.254 >> project_setinput done

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!

v1.12a is up, with dynamic memory allocation for both the mesh generation and geometry rendering systems, which were making the largest memory allocations. There's still room for more subsystems to utilize a dynamic memory allocation strategy, but I want to make sure this works properly for the two of you.