Real-time Simulation System Stuff

I'm knee-deep in the core algorithmic code of the updated simulation system, which will feature full operation simulation - allowing real-time observation of how an operation will actually cut as a function of time. Users will be able to control the simulation speed as a time scaling factor, or in terms of tool move commands per update, and updates will occur up to a fixed number per second (i.e. 5-10Hz) unless the system cannot keep up (machines with fewer CPU cores) at which point it will simply update as often as it possibly can. The goal of all the work I've been doing today, and planning over the previous week is meant to enable slower hardware to provide a usable simulation experience, albeit with a toned-down simulation resolution/quality.  At the end of the day it should provide a valuable simulation on a low-to-mid range computer, and hardware beyond that will simply allow for higher resolution and simulation fidelity.

I'm in the middle of writing a new subsystem for PixelCNC which will allow heightmap meshes that have dynamically changing depthmaps. These specialized heightmaps are called 'quilts' and comprise a grid of patches (as described in my previous devlog post). Each patch consists of both an internal binary tree of triangle nodes for its sub-section of the depthmap as well as the most recently generated renderable mesh, or rather a handle/ID to a vertex buffer that's already loaded onto the GPU for rendering. Each time the simulation system produces a new depthmap per the cut motions applied to the previous depthmap state it sends this depthmap to the quilt system which determines which areas are different from the previous depthmap to ascertain which patches need updating. By only updating small areas of the entire quilt in the form of these patches the CPU/GPU will not be overburdened with updating entire swaths of the simulation's geometry (millions of triangles/vertices) that haven't even been affected by the cut motions.

PixelCNC already features a threaded job system for breaking up tasks across all available CPU cores, so each quilt patch that it has been determined needs updating can spool up a threaded job which updates its binary tree subdivision mesh with its corresponding sub-section of the simulation depthmap. This actually functions somewhat more like a state-machine, because a patch updating its mesh can affect a neighboring patch due to the need to mirror subdivisions along edges across neighboring patches to prevent broken seams from appearing, which means a neighbor might need to just update its renderable model (i.e. vertex buffer that's uploaded to the GPU for rendering each frame). Each time a job finishes it flags the patch so as to signal to the main program thread to begin displaying the newest patches. The trick here is synchronizing all the patches to update simultaneously so that no seams appear.