I'm not sure I'll ever stop being surprised by how things that appear to be really simple and have not so simple intricacies within.
I made a game for the LowRezJam where you are restricted to only ever displaying 64 x 64 pixels. I settled on making a game where those pixels are for a sensor on a space telescope and the player acts as the onboard computer, searching for exoplanets. There's no doubt that I was geeking out on my space game. I made an intro scene which goes through the basic stages of a rocket launch. I have the first stage simply fall into the ocean, but during this jam, SpaceX landed their first stage on a barge in the ocean. Figures, my rocket was immediately outdated.
The first pass of my game was that the player would need to stabilise the spacecraft before it could start analysing the stars that it could see. It would then find exoplanets based on how far away the stars were. It was my first time using Unity's Lens Flare. They don't look amazing usually, but with the pixelated script I had running on the camera, they looked surprisingly stylised. They could have their fade speed adjusted which worked nicely for an "exposure" effect, where the stars further away would take longer to appear.
I created it so that there were different types of stares, dwarfs, ordinary (like our sun), giants, pulsars and black holes. Each had a different probability of having a planet orbiting it. Each star also had a different likelihood to spawn. And then there are 3 different types of planets that can spawn, rock, ice and gas; and each of those have different properties (size and distance from star). The orbits of the planets are randomised so that the normal to their plane of rotation was random, as you'd expect. This create the real problem of the fact that some stars have planets orbiting them but they don't eclipse their sun so are harder to spot. I was happy with all of this, but feedback I got was rightly that there was almost nothing for the player to do. They could just move the camera to a new spot and then leave it to find planets itself. Not much gameplay. While I was happy for it to not be very filled with gameplay - just something to geek out with - I did want the players to try to hunt for the eclipses.
Initially too, there was no visible indication of the found planets. So I created a simple target image that I'd use in Unity's UI to show up when a planet was found by the automatic analyser. A simple task that was absolutely not as simple as I had expected. Unity's UI doesn't simply move around using it's position... it has a confusing maze of transforms. Great for using the GUI in the editor to set up UI. Not so great when you want to do things in code. I tried lots of attributes that didn't behave as expected. The most obvious one was the "position" but... wow... no. Maybe local position? Negative. Perhaps the offset min/max? Nope. Eventually I got it: anchor min/max. Setting both of those to the same position essentially allowed me to move them where I wanted in viewport space. Later in development, I also came across an issue with scaling. The game has a screen at the start that lets you change the scale of the screen (either 64x64, 128x128, 512x512 and even 32x32). I'd been testing in the largest scale because that's naturally the easiest to work with. However when I tried the smaller screen, the targets were still the same size - and so relatively huge! While in playmode, I tried changing a setting and viola, it was the correct size relative to the screen! So I exited playmode and made the same change. Then I started the game again and... nothing, the targets were being scaled too small to be seen. I reverted to the original setting and pressed play. Huge again. Once more while in play I changed the setting and they scaled exactly as I wanted them to... So my fix? I keep the setting that makes them too big in smaller screen sizes, and then in script I change the setting. And that works. Fuck if I know how or why.
So now I could have the target pop up when a planet was found. Unfortunately, I thought the stars looked really good, and very quickly loads of targets filled the screen, and looked shit. My quick fix was to add a button to toggle whether the UI showed the found planets.
There was still the issue however of lack of playability. I decided that instead of just showing the player all the planets, it could throw in some fake ones and the player must determine which were real. This helped slightly but there were still issues. For example, a player might see a star very obviously get blocked, but will have to wait until the computer highlights it before they can claim it. Additionally the randomisation of the planets made it really difficult to find lots of planets. I needed a further overhaul.
Eventually I made it so that there was no automation. In retrospect, this is an obvious thing to do, but I guess I was just wanting to make a cool gadget instead of a game. But as I went along I definitely wanted more input from the player. So instead, the player highlights a star by putting the mouse pointer over it and they can then select it if they think that there is a exoplanet there. Find 10 and they win, mess up 5 times and they lose (so that they don't just go on a clicking spree). I also overhauled the planets. To my upset, I removed all the orbiting crap. I originally tried to increase the likelihood of an eclipse by increasing the sizes of the planets and slowing them down and putting them closer to their stars and... it was just getting absurd. So instead, they now move backwards and forwards along a straight line that points towards the camera. This way I could guarantee eclipses while still controlling their length (by adjusting the midpoint of their movement). This worked perfectly and made it much more playable, as now I could be sure players would be able to hunt for the planets without the risk of too many being out of view.
I did however have a weird bug where a target would appear over apparently nothing. Sometimes a star is really far away and so it's light takes a while, but sometimes nothing would ever appear. There are black holes in the game but they're incredibly rare and I aligned my scene view camera with the game camera and there was nothing there (I have Gizmos to help show me stars and planets).
What the fuck was my camera locking onto? And then I realised. I turned the scene camera around 180° and sure enough, there was a planet that lined up from the target through the camera. The way I do my targets is to make an array of them (enough for every star) and then make them transparent. They then are locked to their equivalent star and move was the camera rotates. They then appear when the mouse hovers over them. As I should have expected, things behind me when converted into view space will fall back on screen. I fixed this by simply disabling the target so that it's hit-box wasn't being picked up if the star's behind the camera. I later refined this to only enable if the star comes into view.
After tracking down a few bugs, I was able to finish up the game. It's not a huge game - it's a game jam game - but I'm really pleased with how it's turned out. And while I was originally a little sad to drop authenticity for playability, I can see it was the right move.

One such convention was the A MAZE festival in Berlin which I went to in April 2015. That was fucking awesome. Or I guess amazing would be more appropriate. I realised when I attended it's actually the first "festival" that I've attended. I was amazed at the quality of the band we were given, having been used to the cheap paper ones you typically find on a night out in Dundee. Actually I'm still wearing the band, it's a nice reminder to myself to be more proactive, because I went to A MAZE hoping to get something out of it beyond simply a change of scenery. But as it happens, a change of scenery was exactly what I needed. I was actually able to show off a game that I had worked on from a game jam (this game). I had been relatively pleased with the game in Dundee, I'd shown it at a number of events and people unanimously enjoyed playing it. That confidence was seriously knocked in Berlin. I was amongst incredible games which put mine to shame. Fortunately, this didn't effect me negatively. Instead, it helped show me a target for where I wanted my games to be. In addition to getting to experience a number of fantastically creative games, there were also a number of speakers. I had not expected them to be as inspiring and provoking as they were. One speaker, Devine Lu Linvega, blew me away with his approach to life. He seems to take on so much and yet what he creates still appears to be consistently impressive. He also is constantly trying to learn new languages, having already mastered many. Language was something I became very aware of in Berlin. Not only because of the clear discontent that the locals had for me when I wasn't able to communicate effectively in German, but from seeing so many people from all around the world speak English. And not just some base line "Hello, where is the train station" English, but using vocabulary that it's easy for me to otherwise take for granted. I'm aware that in other countries English is taught more thoroughly as it's a good bridging language for people. But it made me feel so ashamed of my ignorant approach to language. I'd always struggled with learning foreign languages. In school we were taught French and Spanish, but I just couldn't pick it up. After Devine's talk, I realised why. As obvious as it may appear, I never thought of other languages the correct way. Instead trying to learn how their words swapped out 1:1 with English words, when instead I should have been learning how their culture looks at and interacts with the world. This different world view allows the world to be described in a different manner than English allows and indeed Devine had felt like his expression was limited by English which is why he set out to learn new ones. I want to learn new languages and I hope that this different approach helps.
Another speaker who brought me to the brink of tears was Christos Reid. Christos suffers quite severely from OCD. His talk offered an interesting perspective on games and helped answer some questions about games that I hadn't even realised that I needed answering. As someone who suffered with depression almost none stop, it felt like a very personal talk and it was really inspirational how he hasn't let his disorder prevent him from doing what he wants to do.
I suppose I should note what actually happened with my Postgraduate degree...
Well second semester continued presenting me with an overbearing amount of work. However I was happy with what I ended up making by the end of it. My Podracing game was... well as good as I could manage when it wasn't my primary focus. I would've liked to have had it more like a game and less like a tech-demo, as the other racers simply bomb it full speed to the end of the try without trying to do anything particularly impressive. The second semester game actually ended up being a lot better than I had imagined that it would end up. I also created a wee platformer game which reminded me for the 1000th time that platformers are not as straight forward as I keep thinking that they are.
Did I talk about Microsoft imagine cup? I think that was April 2014. Alongside my numerous Uni projects and my part time job writing software for nanosatellites (because that clearly wasn't enough to take onboard) I continued working on projects with the Pixel Blimp guys. As I probably mentioned in previous blogs, I'd continued doing various jams with them and on top of that we managed to get into the Microsoft Imagine Cup where we were competing for a single national spot to compete in the world competition. As a quick run down of the Imagine Cup, there are 3 sections: Games, Innovation and World Citizenship... Games are fucking awesome, but it's really difficult to compete for the top spot through justifying good of our game, Wee Paper Planes, against the likes of software which can detect possible cancerous moles or platforms to help connect developing countries. Naturally we were instead shooting to win the Games section of the nationals. And we did it. Although being brutally honest as I always am, the games side didn't present much competition. I was genuinely shocked and appalled at the level of quality that we were competing against. There was only one exception, I forget the name of the game (sorry!) but it was really fun and really well polished, against those guys I was nervous. Fortunately, we had a pretty solid (for inexperienced students) pitch. As it happens, Abertay managed to send a few teams down the following year and they all looked much more up to standard. We had a huge helping hand getting organised and the likes for Imagine Cup from both Abertay's Iain Donald and also Microsoft's Lee Scott, I've no doubt they similarly helped guide the teams from the following year. While we weren't the overall winners of the Imagine Cup, we did end up being the team that went along and got drunk with the Microsoft execs. I believe we were the only team from Scotland, and so perhaps it was important for us to uphold the stereotype.
Have I blogged about Search for a Star? I don't think so, but basically I got in to the second stage this year. Sadly it was sponsored by Marmalade so naturally the coding test required working through what was broken in a build using Marmalade and to then add features. Ugh. Actually I was pretty happy with what I ended up with. You could apparently export to Android but wow fuck that. After using Unity for so long, it would be like shaving with broken glass.
I didn't hear anything further so I figured I didn't manage to get through to the final stage. Like I heard nothing back. From anyone. It was actually quite a waste of my time, plus unnecessary stress of having to use bloody Marmalade again.
Third semester came as more of a blessing, instead of however many different things I was trying to balance in the previous two, I only mainly had to focus on our third game which ended up being a "port" of a semester two game from PC to PS4. That'd be fine except for the fact we had to use that damned PhyreEngine. The game was functionally simple, so there was very little porting and more recreating in a different engine. Foolishly I'd highlighted my love for graphics programming and so that was the work load sectioned off for me. While we were working in the PhyreEngine, we did at least have the most capable programmers of the masters so fortunately we managed. What we pulled off was actually way better than I expected. I hadn't expected to end up with something that I could be happy to show to people. Look at it. Also shit. Looks like I still need to write up what I did for that. Probably partially good as there might be less heated angry rants about the team now there's been like a year to calm down. Although I'll be damned if I remember everything, my memory is pretty poor.
During the final semester, I got an email sent to a load of people from the lecturer who is basically Abertay's Sony contact. It detailed a pretty awesome internship and at this point I didn't know what I wanted to do. Unfortunately it said that it would start at a time when I would still be doing my Masters, I checked with the lecturer and he said I should not go for it. Originally I went with this, but then I thought "wait what, fuck that". I got a job working on fucking satellites because my thought process was "I won't be in any worse of a position for applying for it". So I went for it. I got an interview and popped down to their London Studio. I did a code test which apparently they do for any Sony programming interview. "Oh shit" I thought. Actually I didn't do too bad, getting most of it correct with only a few wrong answers including for a question asking what the contents of a memory dump represented. It was apparently an intentional curve ball and did it's job of looking scary as shit to me. However when I was told it represented an identity matrix, it was suddenly clear to see. Another thing I tripped up on that I should have known better was writing to a pointer which hadn't had any memory allocated to it, I'd been distracted by another part of the code.
As well as a code test, they did an interview asking about the various things I'd gotten up to and the there was a third part where they asked me to talk through designing a game.
I didn't hear back from Sony so assumed that I hadn't gotten through, until I got a call which said I was "third in line". They said that I did very well but there were two people who were really good. The internship was to take on two people, so the cynical side of me felt like this was just something they were saying to "be nice". Although it would be a peculiar thing to do when they didn't need to say anything at all, bare perhaps a polite email - ignoring is pretty damn rude people. However, a couple of weeks later, I got a call from Sony asking whether I was still interested in doing the internship. God fucking damn it. The internship sounded so fucking cool, it was broken into three different sections which would have given me a good overview of working within the Sony London team, and I was particularly interested in getting a chance to work with PlayStationVR. Unfortunately, this call came at a point where I had just been sure of what I wanted to do with myself. I didn't know whether I wanted to go into AAA, where there's job security (OK well actually that's no longer such a strong case) but almost certainly no creative freedom, or whether to go into a smaller, indie company where I have input, but at the same time it would be really risky. My boss at Bright Ascension pointed out that they were happy for me to stay on and when I worked out with them a way that I could both work in space and on games, I was sold on that path. And then that Sony call came in. Fuck me was it painful to turn it down. It would have been a fun 3 months for sure, but with no intention of continuing working at Sony, I felt like I would have just taken away a really good opportunity for someone who did want to go into AAA game development.
After they finished their undergraduate, the almighty Iain managed to swing some space near the MProfs for the Pixel Blimp guys to do more work. They'd made a game in another game jam which they were working on to try to release because they were trying to get into the Microsoft Ventures program. They got in and invited me along but fuck that. The risk was so high and after those terrible first few months of my Master with no money, I could not risk that again. We'd also worked further on a game we made during a game jam (as ever) and managed to get a stand at that year's Dare Indiefest. Each year the MProf students also have a stand, but as I learnt it's not a given, the producers are supposed to organise that. Fortunately we did end up getting a stand. We also had two PS4s to show our game off. Having two stands was pretty awesome, although crazy tiring. That Dare Indiefest was the best one to date, it was so busy and there were people worth speaking to from the industry.
Dare for this year changed. Instead of being 9 weeks of (paid) development from scratch for teams, you're able to "continue" working on a game that's been in development and showcase it at Dare Protoplay. I'd written off Dare the second time I failed to get in, as I new I'd never have the time during my masters. You can however enter a year after you finished your studies and with this new model, I could work on my game jam game and also do it while still being at work. So I applied, not really thinking I'd get in - it would only be myself and another artist.
Around this time, I'd also applied for a "Space Studies Program" run by the International Space University. The program is ~9 weeks long and covers a broad overview of the space sector, from Orbital dynamics and Space Life Sciences to Space Law and Policy. I was and continue to be very conscious of my lack of background in engineering, especially for space. It means I'm constantly fascinated with new things that I come across at work that appear trivial to my colleagues, but it also leaves me feeling very inadequate. So I applied hoping to get a better understanding of space. I didn't expect to get into either SSP or Dare. And got into both. SSP ran from 6th June - 8th August (and was in Athens, OH) and Dare was 13th - 16th August... "Oh fuck" I thought. SSP was intense, with days usually being non-stop from 8am til 11pm. Finding time to organise our Dare entry along with the time difference was... an interesting experience. Somehow we managed it and I was really happy with how it ended up, although I was working on the assumption that I somehow had an entire week and a bit after getting back from Ohio. Instead, I had to do alot of work while travelling back home and when I got back home. From waking at 6am EST on Saturday to 4pm GMT on Sunday, I didn't sleep and was mostly working on the game. At 4pm I decided I should maybe at least nap. I had a 4 hour kip and when I got up and turned on my Windows 8 laptop, it blue screened. Fuck. I had no back up of the Dare game. I had no backup of another game from a game jam that I hosted in Ohio. I had no backup of the pictures that I'd taken during my 9 weeks in fucking Athens. Also, holy shit is the Windows 8 blue screen the worst. Fucking smiley faces and vague as fuck messages only served to enrage me further. By some miracle I managed to get my files off my laptop before I had to reformat it. I forget every time how tedious setting up all your damn programs is.
So we managed to have something decent for Dare, although as I predicted, we tweaked it each night based on feedback. Also as predicted, through knowing people from teams every year for about 4 years, Dare was atrociously organised. It was only during the competition I realised what a missed opportunity it was being able to work besides the different teams for 9 weeks. There were a few nights organised to try to network with each other, but it still wasn't as tight nit as I would have liked. When we were set up, it was immediately apparent, we weren't going to get a BAFTA, almost all of the games were amazing. Being conservative, there were 6 other games worthy of a BAFTA nomination besides our own. Not one to build unrealistic hopes, I turned my hopes to the audience award. People loved our game. I quickly through together a highscore board application which allowed us to add an additional competitive incentive. Although I discovered that our game was so strongly cooperative, that this only influenced a handful of people, all male. The majority of people just loved playing the game, the experience. Which is actually pretty fucking awesome.
Sadly, we lost out on the audience award, and as expected, we didn't get into the top 3 for the BAFTA nomination.
Oh, I'm just going to leave this here for future reference if ever I want to get the damn song stuck in my head again.
Space. This site is heavily focused on my games development, but this is a catch up blog on what I've been up to so how can I not talk about Space.
The SSP actually didn't end up being what I wanted it to be. I didn't learn really anything about engineering as I had hoped. What I did learn though was that I already had a pretty good breadth of knowledge on space. All my hobbyist read ups apparently put me above basic knowledge of space. I also got to do some really really fucking cool shit.
The SSP takes place in different parts of the world each year. At first I was upset about it being in Ohio, compared to more exotic locations in the past. However it ended up working to my advantage, because Ohio has spawned a lot of astronauts and so I got to meet a lot of astronauts. Actually so many that I stopped being nearly as buzzed and was able to instead focus on getting their personal experience beyond simply "Oh my God tell me what the Earth looks like". It also meant that we got to build bigger rockets that go much higher than you're allowed to in other parts of the world. And when they gave us a requirement to build a big rocket, my team delivered, making the biggest rocket at over 1.5 metres. We used F rated engines, but I regret not pushed to order G rated ones as our rocket ended up going only half the required height (still over 500ft). We had to try to get an egg safely back to Earth. We would've succeeded had there not also been a requirement that the egg touched a brick. Our egg came back untouched bar that single contact point. Fortunately it didn't end up being as upsetting as I had feared, because fuck me it was cool. My team's rocket was the black and white P-2 rocket, after the V-2 rocket, and thankfully was one of the ones with a softer landing.
We also got to get together into teams and control a rover that was over in Canada. We drove it around a mockup of Mars to try to visit various sites of interests, and were the only team that managed to make it to all of the sites. I was on the sensors, keeping an eye on the IR camera and controlling the LIDAR sensor. Holy fuck it was awesome. We were simulating our control group being in orbit around Mars causing a few second delay on controlling the rover. We then had an 8 minute delay to ground back on "Earth".
Feeling like I had to prove my background in games wasn't so bad compared to all the astrophysicists and rocket scientists surrounding me, I decided it would be a good idea to host a game jam during the program. I made a game in 10 minutes during a 15 minute talk to try to convince people, who likely had no idea about game development, how easy it could be. SSP was really busy and so there were only a handful who actually showed up and only two managed to make it to the jam. This bummed me out slightly, until I got to see what the two had made. These two had no prior experience making games and what they made was amazing, one made a rover game while another made a two player shooter game. Even more humbling was the fact they were so inspired that they went on to spend a week making a game to simulate the possibilities for using VR for training astronauts. I was genuinely touched and it felt amazing to have inspired people like that.
What else did I do...
Oh I got to go to Belgium and buy 3kg of chocolate, that was pretty fucking sweet. My boss approached me asking anxiously whether I'd like to go to Belgium for work, like he was asking whether I'd like to go scribe for Donald Trump for a month; how was there every any question?
I also got to do some client work. The company that I'd worked with during second semester approached me in the following semester for extra work as they liked working with me - which was pretty awesome.
I know that I gave them a pretty sweet and cheap deal, but asking for the money that I did still made me uncomfortable. I had to keep reminding myself of what I was worth after 5 years of university and the experience I've gained alongside that, compared to say, some spotty kid at McDonalds. But even with that logic, I'd calculate the cost and be like "woah shit, I can't ask for that much.. can I?"
Still, I got my taste of working with a client, although they were a lot more welcome to altering their vision based on feedback than I had expected, and a lot more I suspect most clients would budge. Still, working on a game for a client alongside working on satellites was just too exhausting. The client work allowed me to easily fund things like A MAZE, but I'm just going to have to look at other options if I want to continue doing those sorts of things.

I thought I understood the pipeline for setting up multiple render targets in DirectX 11. However, when it came to implementing the functionality into my framework, it was bitterly met with a black screen. I looked more thoroughly over the documentation but still wasn't able to find what the issue was. I still don't fully know, but as a guess, it's because I need to make sure the back buffer view associated with the swap chain is the final buffer rendered to. It's not a large inconvenience but I have now at least been able to make some head way, I've got to a similar stage in the post processing that I was at in 3rd year, where I render my scene to a texture and then render a quad with that texture. I've uploaded a video that shows me first texturing a quad and then showing me using my sprite object to render the scene on the screen and rendering the quad with a simple greyscale shader. I've also included screen grabs of such below.
The next step is to tidy up the render function of my application so that it sets up the different stages for the post process. I'm hoping to either do an effect that applies some form of motion blur or I'll make a second attempt at tackling high dynamic range lighting.

The podracer looks really abstract at the moment, but that should hopefully change once I've started putting in more meaningful models. Watching one of the part spinning around game me an idea. I could create subclasses of the model instances specifically for the podracers that related to engine parts. One type could be static, just as I have at the moment, not doing anything but sitting in place, but then I could also have a rotary instance, one that constantly rotates along an axis, or even better, one that could be altered by a user. As in create moving parts from within the engine itself, and have those parts rotates depending on the current state of the engine. How cool would that be? Will it bring much more to my project? Probably not. But I'm all about the details and I would love for it to have moving parts that did that. So fuck it, they're going in. After I've done more important parts of course, but its now on the agenda.
Once I'd gotten the matrices to work together, I was able to start putting together the podracer controls. If I had a lot more time, I would probably focus on creating a more robust physics system that would manage the physics that will be in this project a lot better and clearer, but alas I've not got the time so it's all hard coded into their individual elements. Right now, I've got it so that I can drive... fly..? move across the landscape. It's not quite 100%
My latest video shows these updates in action. 

For my previous project, I just needed to get some shit rendered without giving a second's thought to whether there was a more useful method of doing it. It was only towards the end that I realised if I needed the same model more than once (which for that project I didn't) then I'd need to recreate the entire model, which is pretty dumb.
This however hadn't cropped up again until now. Now I needed to change the model object so that I could render instances of it and dammit it was a ball ache restructuring the code, compared to how exciting it is when things are going right, tedious coding like this can be a drag. Fortunately I managed to get it to render again and then tested that I could render many instances of it. The next step was to rewrite my half finished podracer generation code so that it could take advantage of the instancing. The result was really simple but it demonstrated what I wanted to see: the engines could be moved around local to the pod (which would be vital later on) while their individual parts could be moved around local to the engine and then the whole thing could be moved. Below are the images from my initial tests. The first was to check they rendered and then the second checked the method for adding engine parts. The grey items are the engines with the sand one being the pod.

Fortunately, working with procedural terrain build from a plane makes collision detection that bit more straight forward. All I need to do to find the height at a given position is pass in the 2D coordinates to my wrapper function which returns the height. Although I need to take into account the extra adjustments to the terrain, as the mesh is moved about so that when rendered, it defaults to the centre of the entire terrain being at the origin. The wrapper function takes this into account, as well as accounting for any adjustments to the position of the terrain.
When I got this working, and had the camera (and placeholder character) skating over the hills generated by Perlin noise as can be seen in my dev video, I was excited. It was is so awesome seeing it work exactly as I want it to. The next step is to start implementing my racer. Right now it is locked to the terrain, however I will make it so that it only does that if the position is below the terrain, otherwise it'll leave it be. From there I should be able to make the racer move across the terrain properly.
To make sure my collision is working as I want, I've implemented fractional Brownian motion and it does indeed work. I've also changed the texture to make it look more like sandy rock. The images below show the result as well as highlighting the LOD and how they appear, although you barely notice when actually on the ground. It's all going really well so far.

I didn't pay attention to the values I was passing into the manager to tell it what to create. I learnt that I'd told it to make 100 by 100 patches. All with 512 quads by 512. This amounts to 5,242,880,000 triangles, with each vertex evaluating it's 8 neighbouring vertices to calculate their normals. Needless to say, my computer needed to be rebooted.
After altering the values and fixing a few accompanying bugs, I managed to render some patches. These were broken and rendered the same displacement. Which is fine: it's what I expected. My next step was passing in an offset for the terrain. After a bit of playing about, I managed to get the terrain to join up seamlessly.

I was really happy with what I had. Even more so when I adapted it so that it's really easy to move around the entire terrain.
I felt like I still had some work left in my so considered what I should do next.
I already had a pointer to the player position as well as the position of every patch. So I implemented a quick distance based LOD hack. It's a hack because I simply check the squared distance and strip the value so that as the distance increase, there's less detail. Because of the manner in which I calculate the LOD, the next level of detail down is a shorter radius that the previous one. I may end up improving it but only if it really requires it, as it currently is, it does a good enough job:

It's weird to see this all working and getting it all up and running so quickly. I don't feel any smarter than I was a year ago, but the progress and the speed at which I'm progressing does seem to suggest that I have indeed improved, or certainly learnt from my mistakes last year.
As expected, the LOD results in cracks, but I won't concern myself with that for the moment, if It's a large issue, I will just increase the radius as the LOD doesn't crack that back for the first couple.

Still not content on just leaving the project where it is for the time being, I pushed on and implemented CPU based improved Perlin noise. I was pleased to see it implemented as easily as I had hoped. I plan to create a GPU version, as I did for my Honours project, but I'll leave that until I actually need it. I'm really pleased with my progress as I had put a big task on myself, I'm just hoping to reap the rewards.

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.

However, as I went to put up this post I realised what I had done. As ever, it was a silly error on my part. Before calculating the normals, I put in the function that I knew I would call and filled it with a placeholder which was to set all the vertices to point up. I then rendered the terrain with the basic light shader to make sure that it was rendering correctly. I then sat down tonight to implement the normal calculations (which actually only took an hour). However, I left in the original normal and then added the other calculated normals on top of this. This isn't much of a problem at lower detail as the length of the normals calculated are about equal. The issue though is when I'm creating normals from much smaller triangles, as their normals are much smaller, therefore when I add them all up, including the one that is (0,1,0), it's going to get more and more biased towards pointing up.
Putting this into practice confirmed what I had thought. Goodness I can be an idiot at times. Below is an image of it rendering properly (with the texture added back in).

My next step is to implement improved noise. If I continue with a static mesh for my terrain, I am going to have to pass in an offset vector so that the noise is calculated correctly. Otherwise, when I create my patches and then align them up, they'll just be repeated and more than likely won't connect up. I think this is the approach I want to take as it will save on CPU time because static vertex buffers are optimised to run better than dynamic ones. However, it may be further down the line I'm limited too much by these static terrains. As it is, I could only create a new one if I closed the application and reopened it. However, I might create a terrain manager that creates the patches using heap memory and which can regenerate by releasing those resources and creating a new set. This would have a spike in performance but help it run faster for the majority of the time.

It actually ended up being about an 10 hour job.
It wasn't quite as simple as I had anticipated to implement it. I knew roughly the method but the implementation was a little more difficult to get my head around.
To simplify the problem, I changed the terrain so that the density of quads was now always set to a power of two (and adjusts the specified values if this is not the case). This meant that I did not have to worry about an odd number of columns needing to be split.
I eventually managed to implement the method and was relieved to see it performing as I had hoped. The method is a simple one, it simply quarters the amount of indices for each level. This means that I can keep the vertices static and the lower detail will simply be a result of this as opposed to any further calculation being required.
I could spend more time and delve into more complex terrain compression, by generating the height-mapped vertices and then from that, calculate what indices and triangles I need. However, it's not necessary for this project and will take up way too much time. In fact, once I've added in quadtrees, I'll already be well on my way to a similar level of difficulty that I encountered with my entire honours project.
I'm pleased that I managed to get the LOD in and should no focus on making sure the normals are generated correctly.
I uploaded a video that demonstrates my terrain in action, showing how the level of details render as well as how the mesh looks under different set ups.

The picture shows a 50 x 50 unit grid with 100 triangles along one edge and 50 along the other. It's also clear, due to the high density, that there is a texture (the terrain texture used for my last semester coursework) mapped across the terrain. As with my models last semester, I can assign any number of textures to the terrain class. At the moment it just renders using the basic texture shader but my next task is to correctly calculate the normals, binormals and tangents for each vertex. I had planned on just using one big patch for the terrain, running perlin noise through it and being done. However I'm now considering using a cheeky bit of quadtrees and using those to create a basic LOD terrain system so that I can have a more detailed environment. The framework handles a million vertices at the moment fine, however once I start layering on the next lot of effects the amount of verts I'm rendering will become quite valuable. A quadtree system will also allow me to cull terrain patches that don't need to be rendered. I could also obviously dabble in tessellating the terrain. However if I do, it will more likely be just to break up the geometric look of the terrain.
Once I've got normals calculated for the terrain, I'll run a noise algorithm through it and work out whether I want to pursue the quadtree stuff because it will eat up more of my time. While it would be nice, I need to make sure I can meet the requirements for the actual coursework so it may be I'll want to instead focus on creating the racer that will be a key part of the game. I really hope that I'll be able to make something that resembles a next level version of my PS2 podracing game. Even cooler would be if I can get the track to be procedurally generated which it's likely to be, unless I have to compromise and it's instead a race to a random point on the map. Such a compromise certainly wouldn't be the end of the world, it could still be a cool game, but I'll be disappointed in myself.