HIVE Optimisation

Even though the game runs very well on my laptop after the first round of optimization, it was still running badly in the HIVE. I went back to the GPU profiling tools I had been using before to find out the issues. My biggest problems were lighting, HZB, translucent lighting, and particle injection.

Lighting was brought down by taking away the light attached to the player. Since I have some more static lightmaps in the night scene now this wasn’t really needed and took some stress off of the GPU.

HZB is a type of occlusion rendering that ue4 does in the background that I really don’t need, so I just popped a line into the defaultconsole.ini that set it to 0.

Translucent lighting was a big deal, so the directional light that is pre-baked was set to not light transluncey and I went back though some of my materials and unlit them. I was worried about the rain and grass, as I had unlit materials on them before and they looked quite bad, but spending a bit of time getting a balance between colour and light in the emissive slot gave me a couple more milliseconds on the GPU per frame.

Particle injection was a tough one – this is only an issue when particles first spawn, but things like the rain can’t be pre warmed as they switch on and off. Turing off problematic emitters within fx didn’t seem to change this – its not the effect but the fact that its being spawned that’s the issue, so I had to leave this one.

These changes brought the game to 90-100fps on my pc, so I thought the HIVE build would be fine. I was wrong – it didn’t even run at 15. I was getting 14fps at maximum. I noticed when I ran the game in windowed mode that I got about 20fps, so I tried setting the screen percentage to 50. What this did was stay fullscreen, but render at half the size of the screen and scale up. This gave me 30fps! Whilst it might not be “true” 30, it works, and that’s what’s important. At that res I don’t notice any pixelisation on the HIVE screen, which is fantastic. Had this occurred I think I’d have had a very difficult decision between performance and artistic fidelity!

I then capped the frame rate at 30, as it jumps around a lot and I wanted it to match the pc build, which is capped to make sure the fx run optimally. 60 was just odd and too fast feeling.

Prepping Posters for Print

I designed a main poster for my exhibition which has the branding assets talked about previously but has images of each of the lighting states. I tried a portrait version and a landscape one, and the landscape one was much stronger, so I went about getting it ready for print. This was very difficult, as there was high contract and some very dark blacks in my images which both convert very badly to CMYK.

This was my first print after setting the image mode to CMYK using the default profile and making no changes. It was far too dark and the only bits of the image that come out ok is the greens.

20150428_134043 - Copy

I upped the brightness and contrast in the image and did another print test. This was better, but still very dark.

20150428_135957

Brightening the whole image and upping the saturation made it more ready for print, but the greens jumped out far too much and made the colours completely unbalanced.

20150428_140610

I then went for the same level of brightness with lowered saturation and made some edits to the curves. Whilst a bit washed out looking, the level of contrast in this image was much more suitable for print.

20150428_141302 - Copy

20150428_142520

I then took saturation down only for the greens, to bring them in line with the rest of the image.

20150428_142520

It looks no where near as good as the RBG image, but its the best I can do for now – print media is a mystery to me!
I’ll return to this once I’ve got my HIVE optimized build running well and I can focus on the showcase.

Final Thoughts, Next Plans, General Personal Ramble

That’s it finished! Or as finished as it can be anyway. I don’t think a game can ever actually be finished, and I have loads of ideas for how this could be continued, but nothing that can be implemented in less than a week, so I’m calling it. I decided a couple of months ago that I’d just develop up to the deadline and whatever was in there was in there, as I am horrible at scope and I knew I’d never get everything I wanted in.

Regardless, I guess I’m happy with it. I’m proud of what I’ve achieved this year – I made 3 games all by myself, built up an fx reel, improved two extracurricular games, released one (make that two next week) and won an award or four….

Unfortunately I haven’t hit my BIG goal yet, which is to get a job in the games industry, but I’m going to keep working on my folio and fingers crossed something will come my way soon. I’ve put in about 20 applications so far and have heard back from about half of them, but there’s some clear gaps in my folio that I need to address. I need to really focus in on my specialization as I’m not strong enough in 2D to ever be a generalist. My summers going to be filled with explosions, magic and muzzle flashes!

Specialization was probably my biggest regret with the honours project. I made this thing that’s like the indie/experimental games that I love and explored some ideas that have been floating around in my head for a while, but I think if I’d concentrated purely on fx all year I might have a job by now.

I don’t have any regrets about this as a research project however – I combined a lot of different ideas here and explored an area that doesn’t seem to have much pre-existing research, which is pretty exciting! The game seemed to be generally successful in testing, and those that have played it recently have given me really positive feedback.

I’d like to expand upon the game at some point. As I said earlier, I have a lot of ideas! I’ve been talking to a programmer about adding procedural generalization and a bigger, more open world to the game. This is going to be put aside whilst I work on my folio this summer, perhaps it will be something I return to after that. I’ve been thinking about putting the game forward for grants or business initiatives. If something comes up I’ll certainly send the prototype and my business plan their way (I priced it all out a while back when I had been determined to be an indie…been really indecisive about my next move this year) but its not my first plan, as after talking to several developers about indie life at expos this year I don’t fancy the financial situation.  William Hugh, one of the developers of The Stanley Parable – a VERY popular game – talked about living with his parents at Rezzed…not really what I had in mind. So we’ll see, I’ll have to go home after graduation anyway.

Looking at the environment art for the project, I’m pretty dissapointed. I had some mad notion that I’d be able to get great at environment art, fx art and make a whole game this year. As I mentioned before…I don’t do realistic scope. I don’t feel like my skills in that area really improved this year.

I am really happy with my effects art though! The difference that can be seen from the Seek effects to the final Presence effects is really big. I know my way around cascade very well now, and wouldn’t feel intimidated about being asked to create an effect I’ve never done before. I’d like to take this further, learn more about Maya’s particles, particularly fluids, and maybe do a wee bit of effects stuff in Unity.

Overall, the game is something to be proud of. It achieves its relaxation goals, the art direction is strong and overall the art looks good (according to other people…not sure I agree with this one, but then again, when has an artist ever liked their work?) Seeing the game played in the HIVE was amazing – Doug’s music playing though the speakers and the big dark room really bring out the best of it and it really does show it to its best. I feel I learned a lot about creating games, improved my logic and feel like I know a lot about Unreal! Though these skills may be a bit irrelevant in non UE jobs, I’ve always wanted to create a game as a solo developer so I’m happy to have been given the chance to do this.

Its not really all finished though – I still have to create a HIVE build and get ready for the showcase!

IMG_20150420_092616 Screenshot 10 Screenshot 9 Screenshot 8 Screenshot 7 Screenshot 6 Screenshot 5 Screenshot 4 Screenshot 3 Screenshot 2 Screenshot 1

Submission Materials

I’ve had to do a lot of videos and breakdowns for evidence as I can’t hand my files in (they’re 15GB!!!). The fx breakdown was the biggest thing to do here, as its important for my online portfolio too. I wanted to present this nicley, but I wasn’t really sure how, so I looked at some other’s portfolios for influence.




They’re all quite different, but the main takeaway is that they show the effects isolated from the environment and to an extent show how they were created.

With this in mind here’s my reel.

New Hub Assets

It was a bit late to be making assets, but on Wednesday I made my last changes to the game – adding a stone version of the hub pool and replacing the hub wall with the rock wall I made earlier. This change helped make the game look more complete, as the assets all tied in together and didn’t look like placeholder.

I used the same process for the walls here.

stones stones1 stones2 stones3 stones4

Lighting Fixes

I had some very strange lighting going on in my hub, my point light solution was not a good one, so I replaced it with a directional light and a script that turns on and off the directional lights depending on which area the player is in. Kicking myself for not making the hub and level separate now that I’m familiar with casting, but its too late now.

lighting lighting2

I added a set visibility function to each of the switch branches, turning on the main level light. I then turned this off when the player uses the exit trigger. The lighting is consistent in the hub now, and it really makes the coloured leaves on the tree stand out.

Wall Model

As there are some issues with my outer environment model, I was encouraged to create some wall models to cover this up in certain places.

I started out by sculpting a couple of rocks in mudbox, and then arranging them together in the way that the artists on Legend of Grimrock did. (See their pipeline at http://www.grimrock.net/2011/09/08/building-the-dungeon/)

I tried doing a higher poly sculpt that included the whiplash motifs, but maya couldn’t handle the polycount, so I decided to do the whiplash normals in photoshop.

I then created a low poly model, using the high one as a guide.

walls4

This is where things started to go wrong…I used the transfer maps utility in maya, but got a very pixelated texture. I tried creating a 1024 map, but my pc refused and crashed.

walls3

I tried using xnormal instead, but ended up with very weird texture at first. That’s when I remembered that I’d lost my UV map last time it crashed…still don’t save often enough! So I went back in and redid the uvs. This created a much nicer result in xNormal, but it did not work on the model – I still have no idea what those grey areas are. A lot of 3D artists swear by xNormal, but its never been great for me.

T_Wall_N

walls6

Wall normals_normals walls7

With my new UVs in hand, I gave maya another go, knowing I’d get more out of the better map. It was certainly a lot nicer, but still taking ages. I decided to give the 1024 map another go, just in case, and this time adjusted the search envelope. Suprisingly, it took no time at all in comparison – turns out my search envelope had been way too big and was slowing down calculations!

walls8

I still had one issue though – the overlapping uvs were creating really dark areas, so I separated them and generated the map again.

walls9

I was happy with this normal map, so moved on to the diffuse and spec textures. I used the same texture style as I used on the rocks. I feel I cheated a bit here, as I painted a few rocks and then copy pasted them – but its 7 days until the deadline! I generated an AO map in maya (this time with working settings) and multiplied this on top of the diffuse to make sure I retained depth within the texture. I then created the specular by desaturating the diffuse, adding high contrast and making the grass layer white, to give it a damp quality.

T_Wall_D T_Wall_S walls10

I then used it in game to cover up some of the not so great looking parts of the environment.

walls2 wals3 walls11 walls1

HIVE Test

The game actually runs on a uni pc! Paul got me set up with the HIVE today so I could test the game. It took a while to get a proper fullscreen build, as I’d built it to force the appropriate resolution but it didn’t seem to want to. Once I had a fullscreen version working, I was able to see it on the big screen. It looked really great, and I’m exited to have people in here to play, but the frame rate wasn’t as good as it had been on the laptop, due to the large resolution.

The sound wasn’t working at first which worried me, but Paul fixed it and I was able to hear Doug’s music though the big speakers. It was actually amazing. The music is my favourite thing about the project (probably because I didn’t do it!!!) and it really aids the sense of presence.

Once I had it working, I created a debug version of the HIVE build so I could check the framerate on the big screen and possibly identify additional optimisation issues in order to fix this. This build runs at 15fps on the HIVE pc and 75fps on my laptop. That’s a big difference. I’ve asked Paul about the possibility of using a different machine but it sounds difficult to set up and pretty unlikely to happen. Going to see how much I can squeeze out of optimizing the game some more.

Optimisation

I have a meeting with Paul on Monday to test the game in the HIVE. Its running pretty slowly just now – about 15fps – and I’m worried its going to take a big hit to the frame rate as the HIVE’s resolution is 3200×1200.

As such, I’ve gone through and tried to identify areas that are causing the game to slow down and fix them. At first, the game was at 15fps and the draw and GPU threads were running at about 60ms per frame each.

I identified one of my problems as being overdraw, with a large amount of transparent textures in the scene. My first solution to this was to make sure all of my emissive and particle materials were set to unlit. This didn’t give me a huge performance boost – maybe 5ms on the draw thread – but its best practice anyway.

The next overdraw issue was the large amount of static mesh grass in the scene. I deleted this and replaced it with instanced foliage meshes. Again, maybe a 5ms boost at most but still a good thing for the game.

drawcalls

Not getting as much as I thought I would out of the stat unit information, I found on the documentation that there’s a GPU profiling tool. I ran this, and saw that one of the biggest issues on the GPU was a single point light. It was static and didn’t seem any different from the rest of them, but deleting it didn’t make too much of a difference to my lighting and reduced my draw by 40ms!!!! This was really surprising. I’m not sure, but I think it may have had something to do with overlapping lighting and dynamic shadows trying to generate on top of precomputed ones.

gpu

I then looked at the second biggest thing on the list, and felt really stupid for not remembering about it. I had real time reflections in the game. The entire scene was being rendered twice per frame, no wonder my GPU wasn’t happy! I was disappointed to have to do this, as the reflections look really lovely, but I changed my scene capture texture to take one snapshot, rather than updating every frame. Again, this reduced the thread significantly, getting my GPU from 69ms to 35ms, which is about 30fps. Not amazing, but many AAA games run at 30 due to the need for a “cinematic experience” (not sure if that’s true for every game…) so I’m happy to do the same.

reflections

Surprisingly, particle optimisation hasn’t been an issue. I presumed I’d have to do some serious LODing of my particles and was dreading it, but most of them run of the CPU and the game thread stays at about 20ms so that’s fine. The frame rate will only be as high as the slowest thread, and the GPU isn’t getting any higher, so I don’t see the need to reduce the time taken on the game just now.

PS4 Controller Set Up

As I want to use the HIVE set up for the exposition now, I looked into getting a PS4 controller set up for windows and adding the controls to my game. Turns out its not as simple on windows as it is on mac…

First off, I had to trick my pc into thinking I was using an xbox controller by downloading xbox drivers and a tool called DS4, which makes the ps4 controller come off as if it is using an XI set up. This wasn’t too hard, but was a bit of faff that just took up time.

Getting the controller working in engine was a lot more difficult. Movement worked automatically which was fantastic, but buttons were more difficult. I had to figure out which controls were mapped where, as unreal works in generic terms because its not built for a specific controller.

Nothing seemed to work, so I used print statements to work out in the editor what worked. None of the global start, global back style controls worked, so using options and share to exit and enter the game were out of the question.

I tried using triangle, as I knew it would work and didn’t think people would press this to see if they could jump or interact like they might with x or circle. This worked great in editor, and in the release mode could bring the player from the game to the menu, but for some reason won’t work from the  menu to the level. Its worrying, as this needs to be in the game, but I’ve been banging my head against it all day and getting nothing. Its being added to my bug list for now.