There were only two changes to Voxtric that can be seen in the video above, but they were both major changes that make Voxtric so much easier to work with.
By the time I had got to the stage that I was at with the previous video, I had hardly implemented any debugging tools. I very, very quickly learned how important debugging tools were when trying to get the Bullet physics engine working in the way that I wanted it to, and so I dedicated a large amount of time to implementing several. In doing so I ended up implementing a way of rendering text to the screen which I had not intended to do at that point originally, though it has made my life much easier now that it has been done.
The second major change was, as the title suggests, the changes to the way that mesh generation is handled. Much like in the original prototype, I wanted to be able to have any mesh generation handled in a different thread so that lots of editing of voxels would not impact the performance of Voxtric. Unlike in the prototype, I wanted to make sure it was done properly.
Watching the original video will show that the changing of voxel data was done in the main thread with thread pools being used to both generate a mesh and test to see if bodies of voxels had disconnected from each other. Of course this meant it was riddled with race conditions and would mean often disconnected areas would not be recognised as such. I set out to make sure that literally everything to do with editing voxels in Voxtric was done in a single thread to avoid any race conditions, but outside of the main thread to avoid any performance impacts.
At this point disconnecting bodies of voxels was not implemented, but by ensuring when I did come to implement it there
wouldn’t shouldn’t be any multi-threading issues it meant that when I did come to implement the feature, it would be far more hassle free.