Post Categories


We respect your email privacy

UDK Strategies in Rendering Shadows

I want to start off this blog today by saying I’m hoping to work with Render Rocket with the goal of opening up it’s render farm to game companies big and small, using the UDK swarm renderer. I’m wondering if there are others out there who think that would be a good idea, to have a farm to render those big ugly game scenes across hundreds of processors.


Here’s why this is on my mind today; Anyone developing video games using UDK software is probably used to seeing the error during gameplay stamped in red in the upper left corner of their screen. “Lighting needs to be rebuilt”. It’s a painful reminder that your ever changing scene has impacted the shadows and as it grows, that render time keeps escalating.

The reason this comes up, is that in order to keep your game from bogging down, you don’t want to simply flick the switch on for all your objects to use dynamic realtime shadows (although it sometimes is cool). Instead, we bake out shadow information, based on a second set of UVs for each game object. It’s complex, and World of Level Design has the best tutorial on setting up those secondary UVs for objects that I’ve seen.

As I get into refining my game and trying to lock down lighting and remove any errors, I’m a the point now where I need to clean up errors like the “Lighting needs to be Rebuilt”. My goal now, to see if I could circumvent my long render times by baking out lighting in packets of information rather than trying to ram the entire game level down my quad-core’s throat at once. I’ve done this, but once my render times shot past five hours, I didn’t want to leave my little laptop heating up that long without breaks.

This lighting error I’ve mentioned will pop up (irritatingly) whenever you move a mesh in your game, move an existing light or add a new one. It demands that your lighting be perfect, if you want to do a final bake out of your game. For many people this may not be an issue. The tactic is to create contained game levels that are typically interiors. On paper the game level design often looks like a map taken right out of a Dungeon’s and Dragon’s playbook. There are a series of rooms illogically connected together in terms of architecture, but that are constructed in order to minimize engine overhead in gameplay, and just because, hey, it’s cool.


As games get more sophisticated this becomes a problem. By sophisticated I mean that games actually have exteriors and interiors. So a game like Dear Esther for instance, if it was baked out on the UDK game engine would have required baking out the island, and all the foliage on the island would be potential light breaking errors. For us indie developers this can be a problem.

In the games I’ve always gravitated to creating, the environments are a mix of exteriors and interiors. To make this more complicated often the interiors are integrated with the exteriors, in that, part of the game play is that you can see outside (that’s part of the suspense). If you want to avoid super long render times, you could start by not doing this altogether. Your game would be closer to something like Silent Hill: Homecoming, where there is a pause as new game levels are loaded, and unused ones are unloaded. In that scenario seeing outside is often masked either by fake scenery out a window, or by the old foggy window trick.

Increasingly games are not doing this, a game level will be a mix of interiors and exteriors all loaded up together, a good example being Resident Evil 5, where the exteriors help give the flavor of the environment, and the environments (sometimes a small row of shanty houses) are perforated to the exterior and too small to make a separate game level by themselves.


To get around loading up the game all at once I like to Stream Levels in game based on distance (and visibility). So a building will not be held by the engine when you are a certain distance. The strategy I came up with is to build most of my lighting and kismet programming in my “landscape” level, which in UDK is known as the “Persistent Game level” and is the automatic level you get when you start building in UDK. This also solves the problem of holding game information between levels in your game. So if you need to know you picked up the “gold key”, the persistent level holds that information, and the persistent level is always loaded.

For lighting I then break everything out. For instance I have an area of my game called, “the Village” and in order to keep things organized on my computer, I name things like this : Stream_Village_A. I always use a letter at the end, in case I add more parts to the village, numbers are confusing because they mean iterations, letters identify this as being part of the village but just a separate level to stream in.


My strategy for rendering shadows is this at the moment : I unload all my streaming levels in the game. I turn off dynamic objects that I don’t want to cast shadows (those are in streaming levels that are prefixed, DYN_Village_A for instance). I have a separate breakout of game parts for doors which I want to turn off when baking out my Navigation paths for AI. The doors will be prefixed, DOOR_village_A.

Once everything is off or unloaded, I start loading in things I need one at a time. I do this for the reason that I want to identify errors and because I want to render parts of my game as quickly as possible. This strategy works really well for baking the architectural elements in my game. I turn on the village, with the persistent level and five to ten minutes later my lighting is up to date. Then I bring in the mysterious building level, and turn off the village (I can unload it from game if I saved out and reload it later if I like). I basically bake only what I need to keep this moving.

Later on, if I update STREAM_VILLAGE level, and want to rebake the lighting, I need to reload it into my main game, and render with the Persistent level on. The baseline thing to know, Persistent level is always on when I render a streaming level and whatever lights are in game are present.


When it comes to trees, my game is ambitiously filled with hundreds of trees. In order to keep the rendering lower, I have broken them up into areas, I try to max out at 50 trees. When streaming by distance I try to locate the tree central to that mass, and use that as my fixed point. Then with Persistent level and trees on, I bake lighting again.

While this strategy becomes more difficult in regards to rendering with trees it is still doable. I keep my processor from overheating and rendering for nineteen straight hours by rendering in chunks like this.


Admittedly, Foliage is still a problem for me. I am using the newer Landscape feature with UDK, and as such I so far have not been able to separate my foliage by LEVELs. This is problematic, because I see the foliage as providing much of the character of my game. To date I have in my persistent level 86,000 meshes for the grass that I cannot bake out separately, and i’m contemplating what is next in problem solving this issue. Note : I don’t even need my foliage to cast shadows, but the goal is to also have the game engine okay with that strategy and not stamp me with the dreaded, “Lighting needs to be rebuilt” error. Even if I can repress that error (Not sure I can) to have it there makes me suspicious that something I want rendered correctly is wrong, if something I don’t care about (grass) is misbehaving.

Note though : In order to work, any lights that are in other LEVELS of your game, need to stay in the game. This is because in their absence lighting gets rebaked and that changes the lighting if you remove them. This is a little more complicated than it sounds. So if my STREAM_MYSTERIOUS_BLDG has several lights, once I bake it, I need to keep that lighting in the game. My tactic right now is to NOT have separate lights in my streaming areas, but to keep them in the persistent level only.


Back to render farms. UDK has something called swarm rendering, (Not smarmy rendering although there is something smarmy about it). Swarm rendering will send out your game to multiple machines on your network. My network of computers is two, remember, Indie game developer. It’s hardly worth the time to setup, and not likely to cut much off my render times. Instead, when rendering I typically switch machines and do something else on my other computer that I need to do.

So I’m stuck with the limitations of the game engine, and my computer power.

While writing this, this morning I have heard back from Render Rocket that they are interested and would like to work with me to see if we can UDK to work on their render farm. No promises, but we’ll see where this leads.