It's so difficult, especially in graphics programming, to not get distracted by something shiny.
I've now moved onto properly testing the 3 tiered matrix system in place for the podracer engines. First they're moved along with the pod. I chose the pod to be the parent because it's easier to have that as the fixed position and move the parts about to make it look cooler. The second tier is the positioning and rotation of the engines relative to the pod. I've got it so that the podracer can take input for how to turn the engines which rotates them around their forward (local z axis). The final tier is the individual podracer parts which are moved when the engine/pod is generated and should stay in place. To test these, I have the pod flying forward (slowly so I can properly observe it) and then have one of the engines rotate, I then make one of the individual pieces rotate. Seeing this work is what made me notice something shiney

So with my terrain being in a good place, namely it's procedurally displaced and I can collide with it (albeit simply), I wanted to move onto my racer. 
And I'm glad I did.
I hadn't realised quite what a task the podracer is going to be. I obviously knew the project as a whole is a large undertaking, but I didn't think about how much I wanted to put into the racer itself.
The first issue I came across was how exactly I was going to create these podracing engines from multiple model modules. The answer of course, was instancing.

Another first for me: procedural terrain collision.
As awesome as my procedural planet was last year, collision with it was limited to spherical collision based on it's radius. To actually collide with the planet, I would need to cast a ray to the centre of the planet, then evaluate the generation function at the point along that ray the radius units from the centre. Totally doable, but I just didn't have the time and there's an endless list of features I wanted to add to that application: There's literally the entire universe worth of things I could add and then some.

So the last blog update has barely dipped it's toe into the ocean that is the internet and I've got more to talk about.
After getting my noise to render correctly, I was ready for the big task of creating the terrain manager to make the patches.
I am currently really poor at estimating how long something will take me. Those tasks that I'm convinced shouldn't take long seem to take much longer and task that I fear will take too long barely take any time at all... Fortunately that's working in my favour at the current moment in time.
Implementation of my terrain manager wasn't plain sailing however.

So I've got normals added to the vertices. As I went to write this, I was preparing the following pictures:

What the show is the apparent discrepancy between the detail of the terrain and the normals generated. The first patch consisted of 64 x 64 quads and the normals are close to what I want, although it is obvious it's low quality. The following two images show a 512 x 512 patch and a 1024 x 1024 patch respectively and the lighting that those patches generate. While they are much smoother, the normals appear to be fading as it gains more detail. This was really confusing me, I could intensify the lighting in the shader, as I have done in the fourth and final image, but as the image shows, this can effect the parts that should be lighter too.

While working on another project I had a epiphany regarding my graphics terrain.
The terrain model correctly maps out the diamond pattern to the specified density of quads (split into triangles). As I was rendering using an index buffer, I could actually render lower levels of detail. It would require having multiple index buffers and so come at a more considerable memory cost, but would require negligible additional computation at run time but instead would make the quadtree based LOD system run even more smoothly as I could simply set the level of detail to render a terrain patch much easier and still use static terrain vertices.
I had an idea in my head about how I could do it, it would be maybe a ten minute job to add in the functionality for multiple index buffers.

It's a little disheartening to be spending my time trying to recreate something I did in 3rd year.
I need to create a terrain class for my framework and so went about creating it. However, as with rewriting my framework, I wanted to make improvements to the terrain.
In 3rd year I made the diamond layout (as can be seen in my blog post relating to my 3rd year graphics programming development). I do enjoy being able to avoid if statements where possible, but given time is, as ever, constrained I decided to just go for the more readable if statement to generate the diamond pattern. This time around however, not only do you specify the width and height of the terrain, but you can specify the triangle density of both the width and height. Additionally, the terrain calculate the correct UV coordinates.

So this semester is to be the next step in the masters graphics module. There was a clash between tutorial sessions and as one of them was for creative writing and the other was inevitably things I'm familiar with, I asked the graphics lecturer if I could attend the writing tutorials. He told me to come to a different tutorial as he would be showing techniques that I won't have seen. I was sceptical, and wondering whether he was aware of what my honours project entailed. However I went along to them and found myself amongst third year students. I soon learnt that the "masters" module was simply a rehash of the 3rd year graphics module. Not only that, but it seemed to have been dumbed down from when it was taught by another lecturer. When I did the third year module, we were tasked with creating our own terrain model and thus had to conceive of the best way to go about that.