Simulation System Threading Nightmare and v1.20a Update

Long story short, after hammering out the 'quilt' system which would allow region-specific updating of the simulation 3D mesh I realized that I had completely overlooked how problematic (and slow) it would be to deal with situations where one patch being updated would affect the update of a neighboring patch - effectively eliminating any gains that are to be had by updating each patch in parallel via the job threading system. Instead I will be pursuing a non-threaded alternative that operates using the existing monolithic mesh system, and just allow region-specific updates to the mesh (where the tool has taken cuts for the current simulation step) as well as allowing only specific areas of a mesh to be uploaded to GPU by way of the vestiges of the original quilt system. Currently a heightmap/depthmap generated mesh can only be uploaded in its entirety to the GPU, all at once. This new approach that's about half-way complete incorporates new functionality which will allow a mesh to be divided up into a grid of quadrilateral regions for uploading to the GPU individually. A mesh will be anywhere from 8x8-16x16 of these vertex buffers.

Summer time is just about here, and many other projects around the home and with the family have detracted from my ability to work on PixelCNC as much as I'd like, so progress has been less than optimal. Once this simulation upgrade is complete the rest of the features shouldn't be too much work insofar as the requisite cognitive load that they entail. For the most part I've already planned out strategies for implementing the majority of them.

One thing in particular that I'm anxious to get out is modifying the rendering loop so that the UI can update every frame while the 3D view is only rendered when the camera or something in the view changes. The UI's responsiveness is greatly affected adversely simply because the 3D view is constantly rendering along with the UI. By rendering the 3D view to a separate render buffer or texture it will be easy to simply update the screen with that pre-rendered 3D view while constantly rendering the UI to keep buttons and mouse inputs snappy. On my low-end Windows 10 netbook the frame rate dives into the ~20s when a complex project is open and the UI becomes a drag. I'd like to keep things running smooth on all systems that PixelCNC supports, at least as far as the interface is concerned. Navigating with the 3D camera could be improved as well by drawing a low-poly proxy geometry while the view is being dragged around, to keep it feeling smooth and responsive as well.

Tomorrow I'll be on the CNC filling a wooden sign order (made using PixelCNC) I suppose I could take some photos and post them here :)