Sometimes, you bite off more than you can chew…

Well, sadly, time and complexity have dictated that I can’t continue on this project. I’ll attempt to elaborate on the technical difficulties I experienced with this project, which will hopefully underline the reasons I had to shelve it, at least for now.

1. Understanding of the uses of recursive trees in graphics. Whilst researching this project, I came across Octrees, with regards to speeding up rendering, and performing collision detection. I was even able to create a rudimentary data structure that matched this design. The problem’s I faced were: You can’t realistically store every voxel in an octree, as the additional information which needs to be stored in each tree node (volume size, node position) heavily increases memory footprint, which I was trying to avoid.

This meant that, in order for the tree to be useful, it must be generated, queried, and destroyed, for every voxel. As we are using C++, this means that we will be using new and delete  frequently, which carries a computational overhead. This on it’s own, is hardly a problem, but when we are dealing with up to 5 new‘s and delete‘s per voxel, which can, in turn be numbered in the millions, mean that a huge number of queries per update (1-5 depth first queries X number of voxels for frustum culling, 1-5 queries X number of voxels for occlusion testing, and 1-5 queries X number of voxels for collision testing). In a single update, the worst case scenario for a single 16³ chunk is 61,440 queries per update. Honestly, the chances of hitting that number are pretty low, but, when multiple chunks are involved, this number increases dramatically, up to potentially millions of queries per update, all accompanied by use of new and delete. 

All this though, is just theory, and I drastically underestimated how much work was involved in creating this structure, in addition to  the engine, rending code, controls, utilities, and all the other ancillary code required to even get the project to run and display a single chunk. I now appreciate why it took Notch four years to code Minecraft.

2. Use of noise functions to generate terrain. I am well aware that the glm library has a number of functions to create noise, given a 3d vector, however, I couldn’t figure out how to use these functions (any googling on the subject only took me to the glm website, or the reference card, which doesn’t explain the use of these functions, only explaining what they can do, not how they do it.). Whilst there are many online resources on creating noise “manually” (i.e. writing my own noise function), They are very heavy on math, which I don’t really get, and to be honest, I didn’t really want to spend my summer figuring it out.

3. Excessive requirements for shading and lighting. It was my ambition to do shadow and refraction mapping on this project, which I now realise, as third year subjects, was beyond my ability at present,so enough said about that really.

There were also personal reasons, which I won’t go into here, but suffice to say that when I weighed up all the pro’s and cons, I decided that I would take on a simpler and, to be honest, more fun, project, which would yield visible results in a shorter time.

I won’t talk about that in this post, however. so stay tuned for updates on my new project soon™


One thought on “Sometimes, you bite off more than you can chew…

  1. Pingback: July already! | UNversity

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s