Don't get me wrong; UDK is awesome. Having looked at the other game engines out there, UDK is head and shoulders above the rest. Sure, graphically, the CryEngine 3 SDK just ekes out the win, in terms of flexibility, ease of use, stability and available middleware (and before you all shout at me that CryEngine is specifically designed to
avoid middleware, I know that, but UDK's middleware is just great, so there!) Unreal Engine is simply the best, period.
So, why should I keep on harping on about realtime GI on the UDK forums? Well, simply put, this project needs it.
Most of the scenes will do fine with the baked Lightmass lighting; outdoor, daylit environments will be fine with that. But I have several indoor scenes with dynamic lighting that just needs that extra pop with realtime dynamic global illumination, and that's all there is to it. Now, I could cheat and rewrite the scenes to avoid that necessity, but that's not how I roll, baby. So I'm just going to have to suck it up and figure it out.
Options, Options...
When it comes to realtime dynamic indirect illumination, there are several options to choose from, all of which are achievable to some degree in UDK. Starting with the simplest, they are;
- Screen space effects
- Precomputed Radiance Transfer (PRT)
- Virtual Point Lights (VPLs)
- Reflective Shadow Maps (RSMs)
- Full-on realtime traced GI
Screen-space effects are, to my mind, the least satisfactory. I've meesed with screen-space indirect illumination (SSII), screen-space colour bleeding (SSCB) and screen-space-directional-occlusion (SSDO) individually and in combination, but the results always left me flat. Apart from simply looking like a poor-quality paint-over, the noise and difficulty of use meant that I would end up spending half my time tweaking them when I should be simply animating. They also have an annoying issue in that if a surface is hidden, it will not contribute any more. Imagine you have a red wall that reflects red light onto an object in scene. It might look great until the camera angle changes to hide the wall, and when that happens, BINGO! No reflected colour. Not terrible in the majority of cases, but in a movie, which has to look good all the time, totally unacceptable. Bleah.
PRT, on the other hand, is relatively simple to implement, requires no actual tweaking (beyond that which normal light-based methods require) and is a true 3-D effect that works in the scene. In other words, where screen-space effects will pop in and out as the view changes, PRT will not. Basically, PRT calculates what and how much light is reflected off a surface beforehand (the precomputed part of the name), but unlike Lightmass, doesn't actually bake a shadow map. Instead, PRT keeps the information stored elsewhere and modulates it based on the light levels and what is surrounding the object at any moment, then projects that light into the surroundings on the fly. At this point, the only real issues with it are it only works on diffuse surfaces, which isn't a huge problem, but tends to detract from the realism of the scene, and the fact that it doesn't work on dynamic surface, which is pretty much a dealbreaker...
VPLs are even more interesting; the idea is that each real dynamic light spawns a random collection of point lights around it that are tailored to the environment in such a way as to simulate bounced light from the original source. They provide both diffuse and glossy reflection and generally look pretty good. However, one can end up with hundreds of the buggers in even a simple scene, and to be perfectly honest, they don't look
great. Don't get me wrong, they look okay, but I need more than okay. PRT gives better overall quality, but VPLs work with dynamic ad static objects. I'll mark this as "maybe".
RSMs are another possibility. The idea here is basically to generate a form of shadow map that contains information about the light itself that can be projected back onto a mesh (the technical term is "injected") to simulate bounced light. Again, it's an elegant idea. CryTek's "Light Propagation Volumes" in the CryEngine uses a variant of this technique to improve the quality of their solution. The problems with this are twofold: First it's not
that good. CryEngine's realtime GI is, frankly, not great (what people think is good in a game is not necessarily good in a movie) and the bounces are actually
wrong in many cases. Additionally, it will be hard (but not impossible) to implement. UDK doesn't give you access to shadow code, so I'd have to kluge something involving materials and UnrealScript and it probably won't look terribly convincing. I'll mark this as "no".
Finally, full-on realtime traced GI. This may seem like the most implausible, but actually in may ways, it's the simplest idea, oddly. The only hindrance to its implementation so far has been speed. Now, thanks to GPU processing power, we are starting to get to the point where this is a real, feasible possibility.
So; I'm going to start turning my attention to achieving traced GI in UDK. I have gathered my materials and I will start experimenting. Along the way, I shall post updates, images and code and show you my progress. If this doesn't work, I will go elsewhere for answers, but I want to try.
Hope you'll stick around; things are about to get interesting. And code-y.
