v1.13a - Meshing tweaks, numpad entry, operation name fix, etc.

There's been a lot of tweaking going on in lieu of properly redesigning certain systems to better optimize memory usage. Specifically the meshing algorithm, which has a tendency to try to allocate more memory than (at least my system) wants to give up to it. These allocations are in the form of large contiguous blocks, depending on the complexity of the project image and/or simulation depthmap being meshed.

There is a better strategy that I will be mapping out over the coming days while juggling some other work and projects which involves decoupling certain aspects of the data that is being stored in these blocks of memory into separate smaller blocks. Some systems simply cannot give up multi-hundred megabyte blocks of memory, at least not after the existing ones have either been taken or used up by smaller ones made during program initialization. These smaller ones made during initialization can also be mitigated somewhat by replacing them with a dynamic reallocation system similar to the ones added to the meshing and geometry rendering systems.

There's a bit of a balance going on here because it could be argued that making tiny allocations for individual subdivision mesh triangle nodes and geometry vertices as they are needed - one at a time - would result in optimal memory usage, because any little open spots in memory could be filled up. Making larger allocations requires that there are larger contiguous areas of memory that can be allocated from. The problem with making many smaller allocations arises when they are freed individually, which can lead to fragmentation. In PixelCNC's case, however, there's currently no reason to expect that making individual small allocations would actually threaten to fragment the heap, as they'd all be allocated and freed at the same time. This means that there's no potential for the memory heap to ever wind up resembling swiss cheese - with many 'holes' where the individual allocations are freed among many remaining allocations. This would better adapt to whatever memory layout the OS provides to PixelCNC.

At any rate, there are also optimizations that can be made to further reduce the memory footprint of PixelCNC. Changes to the data format of the data structures that are being allocated could reduce the needed size of the allocations. PixelCNC will always need to work with relatively high numbers of data structures. This simply cannot be avoid, and PixelCNC is really the first project I've worked on that deals in such big amounts of data, so it has been a bit of a learning experience. One way or another we will get there!

Another thing I wanted to mention was that I have been thinking about setting up a sort of development 'roadmap' that will be publicly displayed. This would essentially give me a place to better prioritize my efforts, and plan what exactly I will be doing to progress PixelCNC further. There are many small and less inconsequential ideas that have wound up dispersed among more important things on the todo list. There are also large feature additions on said list. All of these things need to be properly sorted and organized, and their priority needs to be determined. If I could set it up so that public feedback, either a simple voting system, or means for recording comments, this may be useful as well. In the meantime the little messageboard community is sufficient, at least for immediate feedback concerning bugs and ideas for features.

From v1.13a's changes.txt:

 - fixed project invert setting not being written to project file properly
 - fixed messageboxes added for v1.12a not showing
 - improved mesh subdivision threshold functions to better capture image details
 - changed project invert to also invert mesh texture to maintain visual consistency
 - numeric input via numpad (note: if numlock is off the numeric keys will still work)
 - changed behavior of tool name editing to not require 'apply' be pressed
 - changed behavior of operation name editing to not forget operation name if 'apply' is not pressed
 - changed operation/simulation mode switching to require user to select operation
 - shaved off two bytes per render mesh vertex to improve memory conservation