Ideas For Realtime Radiosity

[Gildoran]

I just saw the realtime radiosity video for the new Crysis engine, and I was wondering if anybody had any ideas for how they might have implemented it, or how you might implement your own realtime radiosity.

 

My current best guess is as follows, though it has severe problems:

 

There's some kind of extremely low-poly radiosity world. When the map is compiled, the low-poly radiosity world is also compiled too, into a BSP containing convex areas, ala Quake1-style compilation. Then much like how Quake engines calculate radiosity, a lighting interaction matrix would be created for this low-poly geometry. However, instead the light sample points being a grid on each surface, they'd only be on the vertices of the radiosity world, making the matrix much smaller and easier to compute. Then, instead of applying the matrix right away, it'd be saved for later.

 

To calculate lighting, you'd do the following: First render the direct lighting pass similarly to how you'd render in D3. Then you render the radiosity as follows: on the CPU, calculate how the lights hit each of the vertices of the radiosity world, only allowing for direct hits. (you'd probably do a trace from the light to each of the vertices in PVS for that light, and if it's not obscured by a face in the radiosity world, light that vertex; this probably wouldn't be prohibitively expensive, since the radiosity world is EXTREMELY low-poly.) Then after you have the vertices directly lit by all the lights, apply the interaction matrix to obtain the radiosity. Then to light the rendered world on the GPU, for each pixel you find out what area it's in, and interpolate the lighting from that of the vertices of the area the pixel is in.

 

Advantages: Doors and moving objects could influence the radiosity by blocking traces that occur when the radiosity world is directly lit.

 

Disadvantages: There may be sudden changes in radiosity as a moving light hits new vertices. Also, I don't know how feasible it would be to run a BSP search and interpolate lighting for each pixel on screen. (I'm guessing it might not be possible for pixel shaders to do, but I imagine such a thing would need to be done on the graphics card, which makes me think this method wouldn't work)

[PinkDot]

I have no idea how this can be done but I've heard that recently Geomerics announced his new realtime radiosity technique. You can take a look at this site for more info, screenshots and some video.

They plan to licence this technique to game engine developers. We might see some games using their realtime radiosity by the end of next year.

 

BTW: Realtime Radiosity in Thief-like games would make them nearly unplayable... (unless levels would be dark dungeons and caves with candles as the only lights... or veeeeery blind AI.)

[OrbWeaver]

You would definitely have to precompute some kind of interaction matrix -- it could be that the "patches" are computed ahead of time, so when you compile the level it automatically divides surfaces up into patches and stores them in a matrix that represents how light might bleed from one patch to another.

 

The game could then sample the lit colour of each patch (after regular lighting), and then "bleed" this colour to its adjacent (in the matrix) patches with some filtering/blurring in place. I cannot imagine there would be any more than one-step radiosity for performance reasons.

[Domarius]

BTW: Realtime Radiosity in Thief-like games would make them nearly unplayable... (unless levels would be dark dungeons and caves with candles as the only lights... or veeeeery blind AI.)

Well that's why it takes place in the medieval sort of period, where lighting wasn't that great.

 

The thief levels have a ridiculous amount of lights compared to how many torches and candles were actually burning during the night back in those days. Mappers will just have to start placing realistic amounts of lights.

 

I wouldn't be worried.

[Gildoran]

Are you sure the affect of multiple bounces would be so bad on performance? I mean you wouldn't have to apply the matrix multiple times: you could precompute (interaction matrix)^n, and use that exactly as if it were (interaction matrix)^1.

 

How does one handle portable objects if you do patches? The reason I was thinking concave spaces was because I figured something like that would make it possible to handle portable stuff, and light them the same way as level geometry.

[OrbWeaver]

Moveables would seem to be a challenge. Maybe you can get around this by using volumes instead of patches for your interaction matrix, so moveable objects could pick up the colour of the volume they were in.

[obscurus]

The realtime radiosity used in the Crysis engine and others is actually very simple and not all that performance intensive. It simply uses at most only a few bounces, which, as it turns out, produces sufficient quality for realtime lighting in games - you can barely tell the difference between it and a high quality render from Maya. It sacrifices accuracy in favour of the overall effect. All nVidia cards form the 7800 up allow for full hardware acceleration of real-time radiosity, so the performance hit is actually not that bad at all, which is why the CryEngine 2 can handle fairly complex lighting situations at playable framerates.

 

The Half-Life 2 engine is also capable of doing real-time radiosity (of sorts). It uses pre-computed radiance-transfer maps to allow a shitload of lightsources to produce the same effect in real time.

 

The reason most people assume radiosity is very performance intensive has to do with the type of radiosity used in software 3d renderers, eg Mental Ray, which 1. uses massively higher quality (probably uneccesarily so) techniques, 2. many more bounces (iterations) and 3. is done in software, not hardware.

 

Hardware accelerated radiosity and photon mapping is now possible (and usable) with the latest graphics cards, and works really well from what I have seen.

[Komag]

Well, that's good news then! Too bad I "only" have a 6800 GT, might have to upgrade at Christmas or maybe my birthday in March