27 Apr 2010 - One Step Forward, Two Steps Back

Texturing the vehicle is becoming almost as much of a nightmare as the track construction which, incidentally, is still not complete. Yet another stage of the project that's dragged it's heels, the UV unwrapping of the steamcar was simple enough in the earlier stages of the project but to organise its textures into seperate 'UV layers' took the whole of today and i'm VERY annoyed about that.

Turns out I misjudged how to tackle this, which added to the time it took - seperate UV Layers don't seem to work on a single mesh object (unless i'm missing something really fundamental but I haven't been taught about it in Maya). After a lot of anguish and readjusting the UV layers, I ended up combining sections of the model together, exporting those sections as seperate UV texture maps, and importing the steamcar's model into UDK again. Every time I export, I have to re-rig the model and i'm glad I found a relatively quick way to do this otherwise right now i'd be looking at a project without a car.

A quick test in the UDK (I say quick, but it keeps crashing and I seem to spend more time these days fighting against it than using it as a helpful tool, so it's more like an agonisingly frustrating process that I have to repeat several times before any shred of success) shows that, mercifully, the new imported file handles as it used to in the game level and that the textures are mapped to the relevant sections.

The Maxton uses four textures - seen here colour coded in the UDK

Tomorrow, hopefully i'll actually be able to start on the texture of the vehicle. I can only pray that this won't take as long as everything else has over the last four weeks or i'll be in SERIOUS trouble with the project progress.

20 April 2010 - Fixed the plumbing

Another productive day!

The Water tower model is now complete and in-game. I played around with specular maps on the drain section to make it look like water had been spilled, to moderate success. It's not that noticable in game but I feel better for putting it there. It's also a good test of specular mapping because I know the car will need it in places.

One of the finished Water towers in-game

I also quickly put together two more posters to break up the bare walls on the course. These don't take a long time to do but I know I won't have time to make things like this later on so i'm getting a few done now in the evenings, when I don't want to be engaging in full-on headwork.

Bill stickers will be prosecuted - but it doesn't stop them. What next? Graffiti?

This week I think i'll finally tackle the Maxton 88's texture maps. That'll be a HUGE job and will probably take a good few days, especially as i'm back in Uni now.

18 Apr 2010 - Why have one when two will do?

Things are finally moving along now after almost a fortnight of agonizing over the in-game terrain. It's still not complete but it's 85% there - no point in doing any more polishing until props and models are in place, so i'm working on that now.

So, a big one today... the water towers in-game, a fundamental part of the game and essential to gameplay. This is something I meant to do almost a month ago and i've finally got around to modelling them today. It didn't take that long to build - with a decent reference image nothing really does.

The water tower is complete! No Texture at time of writing though

Anyway, I thought I should try using multiple UV sets* on this model - partially as a test before texturing the steam car, partially because I need to see how the UDK handles more than one texture on a single model. It worked after a little trial and error, and means that I can use two materials to make a higher resolution texture for the water tower. Doing this with every single model in the game would be a huge memory drain and massively inefficient, but as the towers are almost as much a focal point for the player as the car itself I thought the should take priority.

Applying multiple textures didn't work for me until I re-exported the water tower as two grouped objects - a group for the wooden stand, and one for the tank + pipes. In order to texture the Maxton 88 steamcar using this method, I will have to group parts of the model together that share the same UV set. This will mean nothing to most people reading this but I'm writing it down as a note to myself - I will need to use this again before the project is finished.

The water tower with multiple (basic!) textures in UDK - the Pink and Yellow are two completely seperate texture files

Now i'm going to work on the actual water tower texture, which is uncomplicated Photoshop work. Something light-ish to take me through to the early hours of the morning on another weekend of solid work.

*Note: for anyone reading who hasn't got a clue about what a UV set is - it's a texture map similar to 'nets' that kids sometimes do in Maths lessons in schools. I could blog and explain in detail but time is of the essence and I have a water tower to finish, so it'll have to be done another time!

17 Apr 2010 - Views of the Upper Igford Valley

This was more a post to show members of the family how the level is shaping up - just a quick photo-update with very little in the way of tech-talk. At long last, I know!

Here are some of the most recent shots of the level, and how it's looking as of today:

Billboard on the road to Auchterlony - and the finish line

Streets of Auchterlony - This section still needs a lot more work

The damaged Viaduct - visible from the Lumsden Aeronauts rugby field at Cairncross St.

The Lumber yard in Lumsden, on Drake Hill.

Inside the Crestwell's Cannery section of the course

Additionally, i've also done some more billboard adverts, walls (purple brickwork to match the viaduct), some wrought-iron arches for the factory entrances and a floor for the 'tunnel' warehouse in the level. I've managed to get through a few 'small' modelling jobs like these in the last day or so. This is good for my enthusiasm and motivation, but there's still a LOT to do before this level is even remotely finished.

Back to work - no rest until hand-in!

15 Apr 2010 - Environmentally Unfriendly

As time is really against me at this point, I decided to investigate the UDK's Speedtree tree model generator to make trees for the in-game environment. Whether these will be kept in will depend on the time I have left and the opinion of the Tutors when I go back to university next week.

Anyway, Speedtree is a little complicated but a few handy tutorials online such as this allowed me to get to grips with it without a lot of hassle. I've made a few custom trees to go in-game in an attempt to boost my enthusiasm with the project - creating the terrain has become a laborious task and i'm sick of it at the moment.

Some of my Speedtree trees in the game environment

Some of my trees didn't work initially - the ones without leaves. The Level of Detail (LOD) was drawing them as flat coloured squares from a distance, and this was noticable in game. I thought it might be that Speedtree requires every tree to have leaves, but upon further investigation that was not the case.

I did solve the issue quite quickly (thankfully) - to stop this happening, all I had to do was to uncheck the 'Use Billboards' tickbox in each 'bare' tree's properties. Problem solved!

Problems with the tree LOD / billboards in-game - this is visible when playing

Problem solved!

Now back to the terrain editing...

10 Apr 2010 - That Cursed Viaduct

I'm currently re-working the viaduct for the level - building it at the start of the project was possibly a bit premature. Without something to scale it to, the bridge has been riddled with problems in-game. The latest problem causes the camera to 'shudder' as the player passes through the arches... something that has never happened before now, and is one of many little annoyances that are starting to surface as time is getting short.

So instead of hoping the problem will go away, i've decided to modify the viaduct sections. They're not really wide enough for more than one car anyweay so here's a good opportunity to address something that's been on my mind. Even if it is taking precious time out of my already overworked and hurried schedule.

In other news, the first of the terrain sections for the level is shaping up nicely - and the track is complete. There are lighting issues all over the place with it though, so I hope to find the answer/explaination/solution to that soon. Unfortunately as of late the UDK forums have not been quite so helpful.

7 Apr 2010 - Delays expected until May 2010

I've been working on the roads in-game for the past three days straight.

It's been a hellish, tedious process if I have to be honest - building and placing bland models with precision and repeatedly testing it is not quick work. Additionally, some glaring issues in the track design have become apparent - ones that should have been identified much earlier in the project (which probably would have happened if so much time wasn't used up by trying to get vehicles working in the UDK engine).

So, the level is going to have to be stripped down and built almost from scratch. I'd have no problem with this but time is a real factor now and i've lost so much of it already to trying to solve functionality issues - something I made quite clear at the initial project proposal in October that I would not focus on. This means no days off for the forseeable future.

I had devised a way of building the track in the level, using static meshes created in 3D. The track would be constructed in sections, and assembled in the game engine, much like a Scalextric track or toy train set. This proved to be relatively simple, but came with its own set of issues.

Collision of complex mesh objects (in this case, the sections of track) is hit and miss in the UDK engine - every collision mesh that surrounds the visible mesh has very specific (and limiting) criteria that must be followed in order for the collision to be accurate. If not, this happens:

Collision errors in UDK - the vehicle falls through solid objects

This is not an issue with overly simple objects and props, but the track HAS to be perfect. This is the course that people will need to use to play the game and it will become glaringly obvious if any errors are present. So after hours of experimentation and trial and error I think i've cracked it, with a little help from the forums and constant game testing.

'Breaking up' the collision meshes for UDK into multiple simpler meshes

Collision meshes need to be as simple as possible but can consist of more than one mesh. This means that instead of one complex collision mesh surrounding the model, many simpler ones can do the job. this does use more memory but it's a price i'm willing to pay for the game to be playable. Additionally, collision meshes need to be made of convex angles otherwise the collision information can be incorrect, resulting in the problem shown in the first image of this post. Thankfully, after a lot of backtracking and alternative methods (I was considering making the roads again from a really simple flat surface which looks and feels like an old PS1 game) I think i've managed to solve the problem.

What remains to be done is to test the more complex sections of track such as the banked corners and junctions, make note of any collision errors, and break down the collision meshes one by one until the car stays on top of the road instead of sinking through it.

This should hopefully be done by tomorrow because I still have a list of things as long as my arm to complete before the holidays are over.

3 Apr 2010 - You take the high road...

NOTE: Basic thoughts outlined here - more detailed post to follow. Apologies to any regular followers of the journal. I'm incredibly busy and trying to catch up on the project schedule.

Road proposals - small sections: Initially entire sections of the course, but still had collision issues. considered using UDK BSP brushes in the game engine that don't need collision boxes, but are far more simplistic in shape.

Decided to 'break down' each road section into individual pieces - this sorts collision issues but increases time to produce each section of track. No instancing may mean higher demand on memory

Problem: UV textures will take considerable amount of time to produce if each section is individual. also, scaling issues will add even more time to production.

Solution: UV unwrap one piece of track and crossroad, scale them so they match, and modify these to make extra sections. As the texture is already in place this should save time and allow them to tile/scale properly. Some deformation in the texture may occur when making curves/hills but this should not be too noticable - will test this.

*add pictures*