Thank you for your time.

Anyway, the fact that you have to maintain only one renderer is a huge advantage to the approach you chose. It is much easier to get help in computation than in writing algos!

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter38.html

Their performance numbers look better than ours, so maybe it was a mistake not to go that route after all.

Multiple layers and depth-peeling? I don’t see why…I suppose that depends on where you put your slabs. Anyway, it really does sound like it will be difficult/impossible to achieve the level of simplicity that you’ve achieved, especially when you factor in all the corner cases.

I’m not sure I understand the issue about layers or depth peeling, though. All I’m suggesting is that you can group the accumulation of multiple light texels simultaneously; they would still essentially occur on the surfaces. There’s really a continuum here. You can take a 32×32 patch of lightmap and render that in N directions. The slabs don’t have to be huge, but I suppose this is only really a win if you can sample directions sparsely.

I suppose you are referring to “Hemispherical Rasterization for Self-Shadowing of Dynamic Objects”, they do use software rasterization indeed. I tried using several projections, but the hemicube worked best, all the non-linear projections required heavy tessellation in order to look reasonably good. There are some tricks you can do in the hardware to make hemicube rendering pretty fast, which I’ll write in a future post.

I believe there’s at least one game that used the approach you suggest, there was a presentation about it at Gamefest 3 or 4 years ago, but I cannot find it anymore. The main problem is that you need to capture multiple layers and in order to do that you have to render the scene using depth peeling multiple times. I guess that approach could end up being faster, but it seemed quite more complicated to implement.

This rendering style reminded me of a couple of things. First, this reminds me that there is a hemispherical rasterization using triage masks paper out here, but it is software oriented. IIRC, one of the things it did was make sure each sample of the hemicube was equally weighted, so that integration was just summation.

This also reminded me of my autostereo display/rendering days, and a variant on your algorithm that I would guess can be much faster.

Right now, you are doing:

For each light texel
For each direction
Cast ray

Where that inner loop is hardware accelerated. I suggest inverting:

For each direction:
For each light texel:
Cast ray

You have to decompose things into rectangular slabs (I.e. there is a constraints on the lightmap UV mapping) but then things get easy. You render from the slabs as near clipping plane and shear the eyepoint to sample direction. You can use perspective or orthodox, and you can jitter the lightmap per direction.

We definitely had issue #1 in our implementation (for low-res hemicubes, even those windows in the house are narrow enough to create a problem). The problem manifests itself as a dithering-like look in the image, as the light is hit or missed. We do at least two things to address this. One is to rotate each hemicube randomly around the normal. This does not eliminate the problem, but it prevents it from creating orderly-looking artifacts. (Which is why we get dithering instead of weird bands). The second is just to crank up the hemicube resolution and/or just run multiple samples per lightmap texel and blend. You can also render the hemicubes using MSAA, but that just pushes the problem size down a little further. I believe we have found that multiple samples per texel is much more effective.

I don’t think we have seen problem 2, but this may be because our dynamic range isn’t super-wide at this time (or maybe we are seeing it but haven’t noticed yet!)

1. Geometric aliasing: If one has very small intense lights the resolution of the hemicubes becomes a problem. Between two nearby hemicubes the light may wink in and out of existence when it goes from covering a single pixel in the hemicube at the first location to covering zero pixels at the second. There are of course other subtle sample artifacts as well but this is the most problematic. My “solution” was to crank up the resolution of the hemicube which of course absolutely kills the performance :(

2. Integration errors caused by floating point representation: After the rendering is finished you end up with a hemicube with (probably) a *very* wide range of values. Just looping over the values and simply adding them up is not a good idea. I’m not sure which is the best method of doing the summation, one idea I had was to first sort the numbers and then recursively add them pairwise, i.e. you create a new array half the size of the original array with the sum of the neighboring pairs in i and repeat this until there’s only one value left. I don’t know how feasible this solution is to implement on the GPU however.

( forgive me if this has already been discussed, I didn’t read all of the comments )

http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm

It seems like he came up with pretty much the same solution you did, though he had to deal with the total lack of HDR support in hardware a decade ago.

We are currently doing the integration in the CPU, mainly because it’s my first GI renderer and it’s much easier to experiment in the CPU. That said, the code would map very easily to CUDA now and by doing the integration in the GPU we would save the expensive memory transfers. So, that’s something I might look at, but only when it becomes clear the code won’t undergo any significant change.

I would check your timing to see what the biggest bottleneck is in the operation. I wouldn’t be surprised to find it was geometry, which doesn’t permit many (obvious) optimizations. But I suspect another one might be the CPU integration of the rendered hemicubes. There are many, many ways to obliterate this by means of using the same GPU that the scene was rendered on, but I’ll leave that as an exercise for the reader.

One difference between Quake-style lighting and this is that we are only doing the indirect lighting this way, while direct lighting and shadows are done per-pixel every frame during gameplay.

Out of interest: This reminds me of the id Tech 4 vs Source engine debate, I always preferred Source because it offers this softer lighting for world architecture. If I read it correctly, you are storing the static lighting information in pre-rendered patches that are projected over the textures? Like world lighting in the Source engine?

Also — we haven’t done any speed comparisons, but it is not clear to me intuitively whether this method is faster or slower than anything else, for equivalent quality levels.

David: Right now there are no plans for directional information. The game just doesn’t seem to need it. If we do want to do that as an extension in the future, it can be added to the same basic structure; you just have to analyze your rendered hemicube to classify the incoming light into whatever directional scheme you are using.

One thing I didn’t go into in the post above is that there are a lot of ways that quality levels can be adjusted to make a fast computation or a slow one. Ignacio has an irradiance caching mode in there, and the results come out a little more-inaccurately, but much faster. I think at some point he’s going to go back and try to make the irradiance-cached version be shipping quality. He’ll probably write about that in his upcoming post.

It’s called “final gathering” in the literature, and it’s typically done by casting a bunch of rays into the scene and gathering the “radioisity”-ish-computed lighting from there, but HDR rendering works just as well. This is famously true of e.g. photon mapping solutions, which are too blotchy if rendered directly.

Of course typically that lighting solution they’re sampling is computed by other means, but this approach probably gets good results for N bounces in return for little programmer time.

Radiosity is one way of computing global illumination; there are a lot of different ways, and they all have their own performance and quality characteristics.

Between the screens and the concept art, I’m getting the sense that this will be riffing on Myst in the way that Braid riffed on Mario. Looking forward to it. :)