von Performance and Player-Input
This past week I spent my time on figuring how 3D textures work in Unity. Those textures will be used to create the sample-textures for the planets. Once I had those up and running, I started on thinking about a simple way for the player to interact with the planet.
3D textures
When I started playing around with 3D textures, one big problem with them wasn’t clear to me. 3D textures take up a lot of space! I started implementing a compute shader that would simply create a 3D texture where the pixels inside a sphere in the middle were represented by a 1, and the rest of the pixels outside of it with a 0.
I ran the compute shader, and while inspecting the texture, I noticed that it took up 4GB of space! A simple 512x512x512 texture! Searching for a possible fix to make it smaller, I firstly had to accept the fact that volumetric data simply takes up a lot of memory, and that’s just the nature of those 3D textures.
However, there is a way to optimise memory management of them. I started digging into different GraphicsFormats from Unity. After thinking a lot about what format would be most fitting for my project, I settled on a R16G16_Float format. This basically gives me 2 channels with each 16 bits of space for a float value.
The first channel represents whether or not the pixel-position is within the terrain / mesh during the mesh generation.
The second channel represents different biomes. Those values will be sampled in the material-shader. Depending on the value, it will look different.
But the first channel will later also be influenced by the second one. So if for example at a given position a mountain-biome is, then the mesh at that position will obviously have to look like mountains etc.
Performance
All the big calculations etc. are now running on compute shaders. This gives me a pretty good performance. Being able to fully generate a chunk within 5 milliseconds.
The problem now it tho, that since the chunks get created via a octree structure, there will always be 8 chance created at once. This of course is a huge problem in terms of performance leading into pretty horrible frame drops. I haven’t implemented a fix for that yet, but I found a possible solutions which I will try next week. The current bottleneck is reading the data back from the GPU to the CPU for the mesh-generation. This process can be implemented asynchronously. So I hope that this will bring the needed optimisations so the game becomes playable!
Player input
To take a break form the compute shaders, I decided to start implementing a very basic camera movement for the player. The idea now is that the camera is focused on the planed and can be panned around and zoomed in and out. This was fairly easy to make using the new Input-system. But interacting with the planet in real time just showed me how bad the performance really is at this moment. So while being happy with the current progress, I’m still not happy with the current state of the project.
I really hope to have a version by the end of next week, where you can interact with the planet in real time, with no performance issues what so ever!
