Thursday, 28 March 2013

Trees pt 4

I've had a quick test now for performance with low alpha coverage (high overdraw) and been pretty happy with the performance impact. I've also had a go at seasonal variation for growing and shedding leaves and changing colour. All of that seems to be working fairly nicely though it has become clear that if I want my trees to blossom I will need another texture.

I've moved on to the trunk model. I expect I'll need a few size variations, but I don't really want to add too many branches to them, since I can have more variation with relatively little work by having branch models which I  can intersect with the main trunk geometry.

My first stab at the trunk came out okay, but a little bland.

I took a look at some more reference, and really liked this tree's style.

I decided to work in mudbox to speedily try some more confident shapes.  Since this is a fantasy environment I don't really mind exagerrating some of teh features of trees to look a bit more interesting.

I then retopologised in Max. This process is still pretty tedious - I expect I could do a faster job but I'm a real perfectionist when it comes to topology so it takes a long while.

Clearly there are a few quite distinctive features, but I'm hoping that by rotating and scaling the trunks and by intersecting them through the floor at different heights, I expect the player won't notice every large tree has the same trunk... particularly given their branches will be in different positions.

Monday, 25 March 2013

Trees pt 3

If there's one thing I'm getting used to on this project, it's being very disappointed with my assets when I first drop them in-engine.

The above is my tree from before with a simple shader setup, using the "improved" vertex normals. After applying a custom lighting model and disabling mipmapping, the volume of the tree was a bit clearer and the opacity outline much sharper, but still wasn't looking good.

I doubled up the number of branches and scaled them down and stopped using the vertex normals, to see if that improved things. Whilst it helped, I still didnt have what felt like bunches of leaves, with the outer leaves lit and the inner leaves shadowed. I tried frankensteining several of these trees together to form a much larger tree. This actually did a much better job of feeling like bunches of leaves:

On the tree on the right, even in the small thumbnail it's clear to see a few bunches of leaves. This is a promising development, and I'll be striving to maximise this effect and compliment it with a nice lighting model. I was curious to see what the framerate hit would be, considering this tree is now standing at some 40,000 triangles and casting realtime shadows, but thanks to the fairly full planes, theres not *as* much overdraw as one might expect, and spamming the level with a bunch of them had an acceptable hit to framerate.

It is worth noting that the framerate will become considerable worse during winter when the planes have fewer leaves and the overdraw rises exponentially. It's something I'll be sure to check before committing to such expensive trees. I may also consider some method of card shrinking to make the planes literally smaller during winter, to remove wasted blank space. That may be tricky to do unnoticably and without stretching though...

Anyway, look how much atmosphere is added by having fullsize trees! I should really have done this in my blockout, but I'm very pleased with the vibe the big trees add...

Sunday, 24 March 2013

Trees pt 2

I added more leaves to the texture and rebaked. While the result was improved, it was still a bit spindly. Pruning some of the more adventurous parts helped give it a bit more bushiness, and clustering the branches into shapes gave it a more interesting form. I was also able to reduce the triangle count to 8500 as hoped. Here's my development of the tree:

I then corrected the leaves' vertex normals to help with lighting. The shader will hopefully do a better job of lighting the tree, using a couple of tricks here and there. I'll be interested to see the performance implications of the tree receiving and casting shadows.

Given that the tree actually looks pretty good using default normals (and a bit weird in the picture above), I'm considering calculating the vertex normals shown immediately above at runtime (unless I find a way to use a UVW channel to store them) so that the default normals and these normals can be used in conjunction with one another. I don't *think* averaging the two will work, but I may try that too.

I'm hoping to make a couple more trees using these branches. This one was intended to be a largish tree, but has come out pretty small/medium-sized, so I'm looking to make a larger one, a young sapling and a shrub-like version (may not look believable but worth a shot and might save me making an entirely new shrub). I may try using speedtree to make the variations to save me time.

Saturday, 23 March 2013

Trees pt 1

I'm basing my trees off maple trees because of the seasonal colour variation present in maple trees. I started by making a leaf model using a photo texture. I then placed this around a branch which was also based from a photo. This was baked down to create a new texture for my typical branch. Note that the leaf colour will be controlled through the shader.

Baking offers me a few benefits, chiefly I have been able to apply random colour to the leaves as well as create a suitable texture for their growth. This will help me with my seasonal falling off and regrowing.

I then applied this texture to a plane. I had arranged for gaps in the texture which allowed me to cut the plane up into sections to break the shape of the branch into something which looked good from a variety of angles.

I then used a combination of hand-arranged groups and object painting to populate the following tree.

It is only at this stage that I became aware that I would need more leaves on the texture. Sitting at 11,000 triangles, I cannot reasonably afford to populate the tree with more leaves by placing more planes. So I hope to add more leaves to make the tree seem fuller and reduce the triangle count to around 8,000.

This will make the planes a little more obvious but should improve render time (by having more full cards, there will be less overdraw and fewer triangles so less alpha sorting and less overdraw)

Wednesday, 20 March 2013

Grass Planes

I went about making the grass by modelling some blades of grass and baking them onto planes.

From there I assembled some patches to be placed in the level. The texture would be coloured in-engine.

I brought it in engine and after a bunch of tweaking I ended up with the result below.

I'm not at all pleased with the grass at this stage. After talking to some other students and looking at more reference, I realise I have made my texture too bunched and the grass too tufty. I'm going to give the grass a break for a bit to work on trees and terrain textures, but I hope to come back to the grass to improve it later.

Thursday, 14 March 2013


I started on some grass today. I'm not entirely sure how well it'll work out, but I'm trying a technique whereby I bake the grass to generate both my grass alphas and also my grass terrain texture.

The benefits of baking this from geometry rather than using a photo are mainly to ensure correct normals and height. This will be particularly important when I start to build up snow and leaves using the height, but will also help with the blend between grass and rocks and grass and dirt.

I started by creating some grass pieces and a couple of small weeds:

I then assembled these on top of a square using the scatter compound object:

I had a few problems with the bakes, but they were resolved in Photoshop.

Here's the result:

I'll be placing grass planes on top of this, and breaking it up with dirt patches and loose rocks etc.

Tomorrow I'll be baking for the grass planes.

Wednesday, 13 March 2013

Horizontal unwrapping

"Horizontal unwrapping" is something I've been wanting to do in UDK for a while now. The idea is that if you can perform simple unwraps in-engine based on world position, you can use that information to apply things like grunge really easily and ensure its the correct way up, even if your asset has been rotated.

Theoretically, one could even apply that same grunge to all objects in the scene, and it would harmonize them by applying the same dollop of grunge to all objects in close proximity, a bit like a decal might.

The problem I've always hit is that unwrapping based on world position is essentially planar mapping, and suffers all the same problems (stretching at oblique angles).

I tried again to solve the problem by incorporating the user-unwrapped UVs, with no great success, and also by examining the direction of any given face to choose which direction to "project from". Also unsuccessful, resulting in weird stretching and squashing. This was the best result I could come up with, and it wasn't good enough to use:

However, when i settled with the following restrictions:
  • unwrap must be user-unwrapped to be horizontal to begin with
  • objects no longer world-space unwrapped (no benefit of world-space harmony)
I was able to take on the problem from a different angle. Essentially, rotate the user's existing unwrap when the object is rotated, rather than generate a new one.

You may notice I'm using a new rock I made today. This time instead of using 3D Coat I used max to combine the objects. It would have been easier if ProBoolean hadn't been messing me around. grrr.

Tuesday, 12 March 2013

Rocks in-engine

Having been happy with the rocks in 3DS Max, I brought them into UDK and was very disappointed with the result. The textures seemed blurrier than I expected (despite the 1024 resolution) and the lighting felt flat and false:

I decided to switch to an approach which treated only the large details of each rock asset as unique. the smaller details of the rock (the grain, lichen, cracks etc) would be added with a tiling texture (whilst hoping nobody notices the seams!)

In addition to allowing me to downscale my asset's texture to 512 (although I now needed a couple more textures, but these would be shared across all my rock assets), it allowed much sharper detail, and I could make each rock unique using the object's position and even scale the detail with the scale of the rock.

I also threw in vertex painting of moss to allow me to make the rocks near the waterfall a bit mossy.

This was looking much sharper and more interesting now, and worked well in modularity, however I still felt the lighting was extremely flat and wasn't showing off the normals very well (note: the picture above already has the lighting fix below). Essentially, the rock was either lit or not lit. The lit section did not appear better-lit if directly facing the light, and the unlit portion (most of the rock) was lit evenly from the top and sides. Since my environment is in a valley, light from the sides is incorrect, and is boring anyway. I wanted a stronger bias to give a sense of topdown light.

I used custom lighting to allow me to give more light variation in the lit area, and a topdown light bias in the indirectly-lit areas.

I threw a few of them together to see what I could get with just this one rock asset. A good result, though I expect I'll need one or two more rock pieces for cliffs at least. And the moss is a bit nuts at the minute. Easily tweaked later!

Monday, 11 March 2013

Rocks revisited

Having felt somewhat defeated last time I tried rocks, I gave them another go.

Again, I tried making small parts of rocks in mudbox:

I made quite a few rock pieces, then loaded up 3D Coat. The plan here was to use their voxel-based sculpting to merge the several pieces together into one rock, so that they could then be sculpted together seamlessly.

However, when i started to sculpt them together they ended up looking strange and I was not able to get what I thought might work nicely. However, with them apart worked nice enough so I fiddled some then brought them into max for the retopology and baking.

I started off retopologising by hand, but this was taking a long time so I tried using ProOptimizer, which did a decent (ish) job and after some cleanup and unwrapping, I was ready to bake.

I used my Autobakerrr script and slapped the same rock material texture as the stone wall underneath the rocks. I'm really pleased with how well Autobakerrr is working, its really saving me time and gets such a nice result. Up until I baked the textures and applied them to the model, I was unhappy with the work so far, but once they had texture on them, they looked a million times better, and now I'm fairly happy with the look of these rocks.

I was a little concerned I had used too many tris, so as an experiment, I thought I'd make the low LODs to see how they came out. Surprisingly well is the answer! Also, bashing the same model together yielded a pretty nice result without obvious seams.

My only concern at this time is that its using a 1024 texture. I may have to make a detail texture and scale it down to 512 for efficiency's sake, but we'll see.

Stone Wall

I've been tinkering with a stone wall texturing process. Although I may redo the texture, I'm very happy with the process and end result.

I started with several boxes in 3ds Max, positioned so that they would tile horizontally and vertically:

I then sculpted these in Mudbox, then brought them back into 3ds Max and repeated them for the bake:

Using my Autobakerrr script and a little fiddling gave me this in about fifteen minutes:

Slapping a tiling rock texture behind it, and making a few fairly quick adjustments gave me a pretty nice result using diffuse, specular and normal. In engine, I will also be able to use the height map to tesselate/pixel offset if I desire.

Thursday, 7 March 2013

WIP Runthrough

quick playthrough of the level so far.

(again, lots of UDK stuff which isn't mine)

Wednesday, 6 March 2013


I've found myself wanting Maxscripts I've written at home when I'm in the labs, and keeping a repository of the little script snippets I've done seemed like a good idea, so I thought I'd record them in a blog.

(Mike's Maxscripts... Mixescripts... geddit?)

currently I've written scripts for the following:
  • Flatten unwrap selected objects (for UDK lightmaps)
  • Make Planar per face (for fixing skewed polygons)
  • Bounding Box Dimensions (accurate even when object has been rotated)
  • Export Selection Individually (for exporting UDK tileset pieces)

Tuesday, 5 March 2013

Architectural Tileset

So I've been working out what pieces I need for the architecture. As I looked into what I wanted, I found more and more that I didn't really want heavily ruined architecture like I first imagined, and I leant more towards gothic architecture. In particular, flying buttresses and cathedrals. So I ended up with the following pieces:

I developed these as I was placing them in the level. These are currently just placeholder. They are the exact dimensions of the final models, but I expect to make the final models with a bit more geometry to make them look nice.

Here's what I put together so far (again, i have to stress, theres a lot of default UDK assets here still which arent mine):

Bridge/platform and Tower:

Saturday, 2 March 2013

Lighting Frustrations

The lighting in UDK has been somewhat frustrating for me. The fundamental problem is that UDK has been set up expecting to use precomputed lighting. This works fine for indoor areas, but I need realtime light to allow me to do a full day/night cycle and as a result, I'm working against the grain of what UDK knows how to do.

My various frustrations include:
  • Although UDK can perform deferred shading in directX 11 mode, I do not have access to the normal, diffuse or specular buffers to make any adjustments nor do I have the ability to modify the cascaded shadow map before it is compared with the scene.
  • The results of the cascaded shadowing are not blurred or dithered and because of the above, I cannot make these adjustments myself. So the shadows are either pixellated or blurry, never how you'd want.
  • When rotating the light, updates to the cascaded shadow map appear to happen only when the light has rotated by more than (complete guess here) 0.1 degrees. Although this sounds like very little, it results in the jittery movement of shadows
  • Due to the way cascaded shadow maps work, their results as the light is rotated vary quite considerably, leaving jerkily updating shadows
  • Due to the way cascaded shadow maps work, I have to comprimise between undesirable self-shadowing across oblique angles (causing shadow striping), or "floating shadows" caused by an offset.
  • I am unable to use custom lighting on terrain to hide the undesirable self-shadowing at oblique angles.
  • I have been unable to find a way to interface with the baked lighting in any way
  • In the dumbest bug to date, when a light is rotated very slowly, if you're looking horizontally, it doesn't move. look up ot down to get it to carry on moving. just... what?!
All of the above appear to be pretty much unavoidable, and have to be hidden away and mitigated as best as possible. A couple of features which I may be able to implement but are not currently implemented in UDK are:
  • The current post-processing chain built into UDK is very well-featured, and probably well-optimised, but is costing 5-10ms per frame... this is cutting frame rate by about 30%. I may have to live with that, but if I have time to implement my own post-processing solution I may be able to cut some of the features I don't need for a fairly substantial framerate boost.
  • UDK's out-of-the-box bloom does not feature bokeh (shaped) bloom (it does feature bokeh depth of field but that's not really what I want). This would be probably the hardest thing for me to implement, but I'd really like to give it a go if I have time at the end. It looks super-nice when water catches flecks of light and you get a bokeh effect on the highlights.
  • Post-processing parameters are not kismet or matinee-accessible, but can be adjusted in UnrealScript.
Don't get me wrong... I love UDK. With it, I can do all of the effects I want, and I'm hoping it'll pay dividends when I come to that part... But its frustrating when I see somebody create a new level in CryEngine and within minutes has a day/night cycle with none of the problems above. and it has bokeh bloom. and a better frame rate. And such pretty water...

Really wish I was using Unreal Engine 4 to do this stuff. :(

Friday, 1 March 2013

Blockout WIP

I've been working on my blockout for my environment to help me figure out what stuff I want in the scene.

I started in 3DS Max trying to figure out a good layout, but found it very hard to get a sense of scale or really imagine the environment from the player's perspective. As a result it came out pretty flat and boring.

I took the result into UDK and made use of the terrain tool and existing UDK assets to get a better sense of what I wanted. After showing the environment to half a dozen students and  getting feedback from them and watching them play through the environment, I made many revisions to the layout and flow of the level. The main areas I improved were:
  • Allow the player to explore a little more (less "on-rails")
  • One area needed better guiding to help the player go the right way
  • Improve the sense of depth in the background
  • enhance the scale a little more by making things taller
  • adjust the field of view to allow the player to see more content on screen
  • many other tweaks
... so now I'm pretty happy with this layout and the content of the scene. None of the assets in the pictures that follow are my own.

I dare say I will make further adjustments, but I don't expect them to be particularly huge changes any longer.