Multisample Soft Shadows

Recently, I was thinking which way should further develop the implementation of soft shadows. I can see clearly now that the approximation of extended light source to a single point is unacceptable. Of course, we can restrict light source area to a smaller size: in this case errors caused by approximation are negligible. However, this is one of the main advantages of the algorithm, and I don't want to drop it. To get a better understanding of errors caused by approximation, I added to the implementation the possibility to work with multiple samples on light source: silhouette, shadow volume and penumbra are considered for each sample. Here are some images:

1x

4x

1x

4x

Penumbra area (debug view)

It's clearly seen that if extended light source is approximated by single sample, penumbra become incorrect. Several samples instead of one slow down the algorithm, but one can notice that umbra and penumbra now separated from each other to some extent: the shadow becomes more plausible.

The authors of the original penumbra wedges algorithm do not set themselves to solve the problem of approximation. To solve it, it's needed to change the approach. For example, the algorithm was originally based on the construction of the shadow volume from the center of the light source, followed by lighting compensation in penumbra around the edges of hard shadow. I think it would be better to go this way: consider coverage in penumbra without the sign (it depends on whether we're inside the hard shadow or outside it), and instead of extrusion of classic shadow volume, determine the umbra region and shade it to black - there's no any lighting contribution. Thus here are two logical parts: umbra, where there's no illumination and penumbra, where the pixel shader computes it analytically.

It's unclear now how to calculate umbra for an extended light source, but definitely nothing impossible.

GL_EXTENSIONS

A few days ago I tried to play Quake II (do not laugh - it's the game of all time) on my laptop with Windows 7 and couldn't - the game didn't work. Compatibility mode doesn't give any results.

I found q2source-3.21 archive, builded debug configuration, reassign the paths and ran it. Crash. I started debugging, came to ref_gl initialization and saw that the engine stumbles upon common error - buffer overflow, when trying to output GL_EXTENSIONS string.

The fact is that the constant MAXPRINTMSG (function VID_Printf) equals to 4096, which is not enough for such string in our time - it has grown too much over the years. If you increase the constant by two - the problem goes away. C - unsafe language :)

This problem was solved in OpenGL 3.x, where you don't get the entire list of extensions in one string, but the name of each extension by its index (glGetStringi). SGI had to do that in the initial design of the API, but no one then thought that the extension mechanism will turn into a loony bin, eh?