Voxtric – Update 0: Initial Showcase

This first post for the development of Voxtric is made quite some time after the initial posting of the video shown above, so the detail may be lighter than in later posts which will be made upon completion of the features talked about in them.

As Unity3D is an exceptional game engine when it comes to speedy development, so I decided it would be a safe bet to prototype my initial ideas in it. At one stage I was going to go ahead and try to make a game using Unity3D in conjunction with the early prototype seen above, but unfortunately being fairly good at everything meant that Unity3D excels in nothing. Subsequently I decided to discontinue development of this prototype just weeks after initially posting this video. An example of where it failed to meet potential project needs is in the handling of rigid bodies where meshes without closed edges would cause the engine to throw errors regardless of the context that they were used in.

Language Choices

Another reason I had intended to try and make this prototype into something more than just a prototype is that I had used Unity3D for about a year before, and had become fairly comfortable with C# as a programming language. However two changes occurred to make me disregard that fact. The first is that the course I wanted to take at the time if I went to university (Northumbria which I shall be attending September 2015) would have me programming in C++.

I came to the conclusion that getting ahead and learning C++ before the course began was probably a good idea anyway. Secondly, research suggested that the games industry relied heavily on C++ for its underlying technology due to its high performance capabilities when in the right hands. Again to get ahead of the curve, I decided that learning C++ was worth the temporary reduction in productivity whilst I acclimatised to the language considering the potential future benefit.

Improved Voxel Storage

In the video above it can be seen that Voxtric had many of the features that it has at the time of writing now, but just less well implemented. For example, voxel data used to be stored in an jagged array of 16*16*16 blocks per voxel, which of course lead to memory fragmentation. Now voxel data is stored in a single array with a size of 4096, and a voxel is accessed through a simple equation to find the right index in the array from 3 co-ordinates as seen in the code snippet below.

There are lots of small optimisations like this that make a big overall difference to both the speed and memory consumption of Voxtric that weren’t in the prototype such as storing all block data in a single 2 byte number and using bit shifting to get different elements of information from the block.

Leave a Reply

Your email address will not be published. Required fields are marked *