There are several key changes in the latest update to Voxtric to be discussed starting with the new way the rendering blocks is handled. Instead of using a texture atlas as I had been before and storing the texture position of each block in an array to be accessed by block index, I now use texture arrays. This means I still only need to to one texture binding and only use one texture per mesh, but the way it is accessed is now completely different. It is literally like having an array of textures that can be used. I don’t have to store a texture position at all, and instead just use the block ID of a voxel to access the right index of the texture array which the fragment shader can then sample.
There are several benefits to handling my rendering of meshes this way compared against using a texture atlas. The first major one is that it now means I can have individual images for each texture that can be named specifically for the block that they represent. The second major in game benefit is that texel bleeding as can be seen in my previous videos of Voxtric is no longer an issue. The pixels in the texture surrounding the block the fragment shader needs to sample will not be taken into account at different mipmap levels.
Another key change that I have made to rendering is to implement frustum culling. There is no doubt that this is an absolutely essential part of any game engine, but initially I had not done it as my test scenes didn’t need it to run. Now that I have a better grasp of the Bullet physics engine and the key underlying structure of what I am trying to accomplish with Voxtric is in, I decided now was the time to go back and re-do the rendering pipe-line.
The final important point that has changed is that the centre of mass and total mass of the
RegionCollections are no longer broken. Each block is defined in a .csv file containing its ID, name, if it’s visible, if it’s solid, and of course its mass. When each block is checked in the voxel data for building a mesh, it’s position compared to the middle position the data is multiplied by it’s mass which is then added to a total position.
At the end of the mesh generation the total is divided by the number of voxels stored. This position is then considered to be the centre of mass. The average of all the different mesh position centres is then used to decide the
RegionCollection centre of mass. As can be seen in the video above, it is a massive improvement when compared to my previous videos.