As well as procedural generation, I need to implement some form of post processing effect. This is of course the same case as the coursework requirements from my third year. Post processing however was definitely the weaker of the skills that I picked up from that project. I'd had high hopes of implementing high dynamic range lighting but I struggled to get my head around the pipeline which meant I was left with barely any time to implement a decent effect and thus settled on a hacked bloom effect. It was OK but not managing to implement it has snagged at me ever since.
Now I'm required to do the same task, as with the procedural generation, it will be a good measure of how my knowledge has improved over the course of 2 years.

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

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.

As I mentioned in my earlier post, it was great getting back into proper coding. Unfortunately, I had to put working on the project on hold while I made sure the rest of my studies were up to scratch. I started back up when I broke off from University for the Xmas break. I was confident that I would be able to create an application within the 3 weeks I had before the hand in and while I did indeed manage it, it was a lot more difficult than I had anticipated.

Writing graphics code is no straight forward task. While the methods are always the same, trying to write a nice graphics framework can leave you thinking about the best approach. I've been in this situation at least 4 times now, writing a DirectX framework from scratch. Usually in an earlier framework I'll realise a better way to go about something but the framework would be so big that it wouldn't be worth the time to make the change. 
I love writing all this code. After many months throwing shit together really quickly in Unity, it's nice to get into code at a lower level, making the functionality how you want it designed. The problem is the size and lack of time available. I'm trying to make a model class that will be really flexible which requires a flexible shader class which requires useful methods and so on. I keep getting lead off into a new branch of development and sometimes lose track of the initial goal.
Still, I seem to be on track for my subject though. I've left it quite late to get back into it, but other modules required more immediate attention. It's only been about 2 full days worth of development and I've already got a nice input system, timer and window. I'm now working on trying to get the ol' triangle rendering with a basic vertex colour shader.